הכשל ש-Lovable סירבה להכיר בו הפך לבדיקה שהיא מציגה עכשיו בגאווה

בכל עסקה מול לקוח עסקי מגיע רגע שבו מישהו צריך להחליט אם האפליקציה שלכם בטוחה. מי שבנה את המוצר שלו על פלטפורמה שמייצרת אפליקציות מתוך שיחה יכול היה להציע עד היום בעיקר את ההבטחה שלו עצמו. לאבבל (Lovable) משיקה עכשיו עמוד אבטחה אוטומטי לכל אפליקציה שמתפרסמת אצלה, ומי שמכיר את ההיסטוריה של הפלטפורמה מבין מיד איזו טענה העמוד הזה בא להפריך.

מה זה Trust Center, ולמה עד עכשיו הוא היה מותרות

כשארגון שוקל לאמץ תוכנה חדשה, מישהו אצלו צריך לאשר שהיא בטוחה לפני החתימה. התהליך הזה נקרא סקירת אבטחה, והוא חלק כמעט מכל עסקה מול ארגון. מי שמבצע אותה רוצה לדעת אם המידע מוצפן בזמן ההעברה, מי הצדדים השלישיים שמעורבים במוצר, ואיך מטופלות חולשות ידועות.

לחברות תוכנה ותיקות נמאס לענות שוב ושוב על אותן שאלות במייל, ולכן הן התחילו לפרסם עמוד אחד שמרכז את התשובות מראש. העמוד הזה, ה-Trust Center, כולל בדרך כלל פרקים על הגנת מידע, ניהול הרשאות והזדהות, רשימת ספקי משנה, תקנים כמו SOC 2 או ISO 27001, ונוהל טיפול בדיווחי חולשות.

הבעיה היא שעד היום עמוד כזה דרש צוות אבטחה. הוא דרש אנשים שיאספו ראיות, תקציב לביקורת חיצונית, ומישהו שיתחזק את העמוד לאורך זמן. חברה בת שני עובדים שמשיקה מוצר לא באמת יכלה להוכיח שהיא מתייחסת לאבטחה ברצינות, גם כשזו הייתה האמת. מה שלאבבל עושה הוא להעביר את נטל ההוכחה מרמת החברה לרמת התשתית: המערכת קוראת את ההגדרות ישירות מהאפליקציה שפרסמתם, ומציגה מה שהיא מוצאת.

ההכרזה של Loveable מתוך רשת X

העיתוי הזה לא מקרי

כדי להבין למה ההודעה הזו יוצאת דווקא עכשיו, כדאי לחזור ל-29 במאי 2025. חוקר בשם מאט פאלמר (Matt Palmer) פרסם באותו יום חולשה שסומנה CVE-2025-48757. סריקה שהוא הריץ על 1,645 פרויקטים שנבנו בלאבבל איתרה 303 נקודות קצה חשופות ב-170 מהם, כאחד מכל עשרה. שורש הבעיה היה היעדר מדיניות אבטחה ברמת השורה, מנגנון שנקרא Row Level Security, בטבלאות שנוצרו אוטומטית בסופהבייס (Supabase). המפתח הציבורי שמוטמע בקוד שרץ בדפדפן אפשר לשלוף טבלאות שלמות בלי להתחבר בכלל, ובין הנתונים שנחשפו היו כתובות מייל, מספרי טלפון, סטטוס תשלומים ומפתחות גישה לשירותים חיצוניים.

תגובת החברה באותה תקופה הייתה לחלוק על ההגדרה. לאבבל טענה שמדובר באחריות הלקוח על הנתונים שלו ולא בפגם בפלטפורמה, והחוקר תיאר מצדו שהפנייה שלו אמנם התקבלה, אך לא הובילה לתיקון מספק לפני הפרסום. הטענה על חלוקת האחריות לא הייתה חסרת בסיס, אבל היא גם לא שינתה את התמונה שנוצרה בשוק: לאפליקציות שנבנו בדרך הזו הודבקה תווית של מוצרים שאי אפשר לתת בהם אמון בסביבה ארגונית. שווה לציין שהדפוס הזה מעולם לא היה ייחודי ללאבבל, והוא זוהה גם בכלים מקבילים שמייצרים אוטומטית תשתית נתונים.

כאן נכנס לתמונה הפרט המעניין. בין הבדיקות שמופיעות בעמוד האבטחה החדש נמצאת שורה שבודקת אם בכל טבלה בסכימה הציבורית של מסד הנתונים מופעלת אותה הגנה ברמת השורה. במילים אחרות, הכשל המדויק שהחברה סירבה להכיר בו כפגם פלטפורמה הפך לאחד הפרמטרים שהיא בוחרת להציג בפומבי לכל מי שנכנס לבדוק.

מה העמוד מודד, ומה הוא משאיר בחוץ

הצד שנמדד אוטומטית

רשימת הבדיקות ארוכה ומפורטת יותר ממה שמצופה ממהלך שיווקי. היא כוללת אכיפת חיבור מוצפן, תעודת אבטחה תקפה, מדיניות תוכן שמגדירה איזה קוד מותר לטעון, הגנות מפני הטמעה זדונית של האפליקציה באתר אחר, והגדרות עוגיות מאובטחות. לצד אלה נבדקות ספריות הקוד שהפרויקט נשען עליהן מול מסד הנתונים הציבורי של גוגל (Google) לחולשות בקוד פתוח, נוצר מסמך רכיבים מלא בתקן CycloneDX, ונשמר קישור בין הבדיקה לבין הגרסה המדויקת שפורסמה, כולל חתימת תוכן וזמן הפריסה.

הפרט הטכני שמסגיר את הכוונה נמצא בהערת שוליים: הקוד של האפליקציה עצמה לא יכול לכתוב, לערוך או לעצב מחדש שום דבר בעמוד הזה. הוא נוצר על ידי הפלטפורמה בלבד. זו בדיוק ההבחנה בין דף שיווקי לבין ראיה, ובלעדיה כל התרגיל היה חסר ערך.

הצד שנשאר באחריותכם

החברה עצמה מקדימה ומבהירה שהעמוד אינו תעודה ואינו הסמכה. הוא מציג בקרות שנצפו ותקנים שכבר קיימים, והוא לא קובע שהעסק שלכם מאובטח או עומד ברגולציה. ההבחנה הזו חשובה יותר משהיא נשמעת, כי היא מסמנת את גבול המדידה: מה שנבדק הוא רצפת התשתית, לא לוגיקת המוצר שבניתם עליה.

בפועל, בדיקה שמאשרת שהגנת השורה מופעלת בכל הטבלאות עדיין לא אומרת שהמדיניות שהוגדרה בהן נכונה. מדיניות רחבה מדי תעבור את הבדיקה ותשאיר את הנתונים חשופים. גם רשימת ספקי המשנה, מיקום אחסון הנתונים והבקרות על שער הגישה למודלי הבינה המלאכותית עדיין אינם מופיעים בעמוד, והחברה מציינת אותן כתוספות עתידיות. אלה בדיוק הסעיפים שאיש אבטחה בארגון גדול מחפש ראשון.

ההקשר העסקי מסביר את הדחיפות. לפי דיווחים מהחודשים האחרונים, לאבבל הגיעה לקצב הכנסות שנתי של כ-500 מיליון דולר ומשרתת מיליוני משתמשים, ובכל זאת חלקם של הלקוחות הארגוניים בהכנסות נאמד ב-20 מיליון דולר בלבד. הפער הזה הוא בדיוק מה שסקירת אבטחה יודעת לחסום, ועמוד שמספק תשובות מוכנות מראש הוא ניסיון להסיר חסם מכירתי, ולא רק מחווה של שקיפות.

יש כאן גם תופעת לוואי שכדאי לחשוב עליה. העמוד יושב בכתובת קבועה וצפויה מראש בכל אפליקציה שפורסמה בפומבי, מה שאומר שכל אחד יכול להיכנס ולבדוק כל מוצר, גם כשבעליו לא ביקש להיבדק. שקיפות אוטומטית עובדת לשני הכיוונים: היא מעניקה תג הצטיינות למי שהגדיר נכון, ומייצרת מסמך ציבורי ומתוארך למי שלא. הכלים שהבטיחו שכל אחד יוכל לבנות תוכנה בלי להבין תשתית מגיעים עכשיו לשלב שבו הם מבקשים מאותו אדם לעמוד לבדיקה פומבית על מה שבנה. השאלה היא לא אם העמוד הזה מספיק, אלא כמה מהאנשים שמסתמכים עליו יבינו מה בדיוק הוא מסמן ומה הוא משאיר להם.