תשובה קצרה: כשמשקיע או לקוח ארגוני שואל אם האפליקציה מאובטחת, הוא לא מחכה למילה "כן". הוא מחכה לתיקייה: מפת נתונים, הוכחה שמשתמש אחד לא רואה נתונים של אחר, רשימת מפתחות ואיפה הם שמורים, מי הבעלים של הקוד והאם אפשר להוציא אותו מהפלטפורמה, איך קוד שה-AI כתב נבדק לפני שהוא עולה, מה עושים באירוע אבטחה, ודוח של מישהו שלא בנה את האפליקציה. לקוח ארגוני שואל גם כי התקנות מחייבות אותו לבדוק ספק שמקבל גישה למידע שלו. את רוב התיקייה אפשר להכין לבד.
מי שואל, ומה הוא באמת רוצה לדעת?
משקיע: שלוש שאלות
בדיקת נאותות טכנית לאפליקציה שנבנתה ב-Lovable, Bolt או Replit מסתכמת בשלוש שאלות (Wavect, יוני 2026): האם זה מאובטח, של מי זה, והאם מישהו חוץ ממי שבנה יכול לתחזק את זה ולשנות את זה. ברשימת הדגלים האדומים שם מופיעים ביחד: "הפלטפורמה בודקת את זה בשבילנו", מפתחות בקוד שרץ בדפדפן או בהיסטוריית git, ומערכת שרק אדם אחד מבין.
לקוח ארגוני: שאלון, ומאחוריו חובה בתקנות
השאלון לא נולד אצל איש הרכש. לפי תקנה 15 בתקנות הגנת הפרטיות (אבטחת מידע), התשע"ז-2017, ארגון שמתקשר עם ספק לשירות שכרוך בגישה למאגר המידע שלו חייב לבחון את סיכוני האבטחה לפני ההתקשרות, ולכתוב בהסכם, בין היתר:
- איזה מידע הספק רשאי לעבד ולאיזו מטרה
- לאילו מערכות של המאגר הספק ניגש, ואיזה סוג פעולה מותר לו
- משך ההתקשרות, איך המידע חוזר לבעלים בסוף, ואיך הוא נמחק אצל הספק
- התחייבות של הספק להחתים את העובדים שלו על סודיות
- התחייבות של הספק לדווח לפחות פעם בשנה על אופן ביצוע החובות, ולהודיע על אירוע אבטחה
אם האפליקציה שלכם תחזיק מידע אישי של הלקוח הארגוני, של העובדים שלו או של הלקוחות שלו, אתם הספק הזה. לכן תשובה כמו "הכול מוצפן ומאובטח" לא נכנסת לשום סעיף. תשובה כמו "המידע שלכם נשמר במסד הנתונים שלנו, רק משתמשים מהארגון שלכם יכולים לקרוא אותו, בדקנו את זה עם שני חשבונות, ובסוף ההתקשרות אנחנו מוחקים אותו ושולחים לכם אישור" נכנסת. רוב השאלונים שואלים על הנושאים האלה במילים אחרות, אז כדאי להכין את התשובות פעם אחת.
מה מכינים: שבעה מסמכים בתיקייה אחת
1. מפת נתונים בעמוד אחד
אילו פרטים אישיים האפליקציה שומרת (שם, טלפון, מספר זהות, מידע רפואי או פיננסי), באיזה שירות כל אחד מהם יושב (מסד הנתונים, אחסון קבצים, ספק המיילים, ספק התשלומים, ספק ה-AI), ומי ניגש אליו. באפליקציה שנבנתה ב-Lovable או ב-Base44 יש בדרך כלל יותר ספקים ממה שזוכרים, כי כל אינטגרציה שה-AI הוסיף היא עוד מקום שהמידע עובר בו. המפה הזו היא גם הבסיס לשני הסעיפים הראשונים בהסכם שהלקוח צריך לכתוב.
2. הוכחה שמשתמש לא רואה נתונים של אחר
לא "יש לנו RLS", אלא שני דברים: טבלה של כל טבלה במסד הנתונים ומה מותר בה לקרוא, ליצור, לעדכן ולמחוק, ותוצאה של ניסיון אמיתי: חשבון A ניסה לקרוא, לשנות ולמחוק רשומות של חשבון B, ונחסם. Wavect מונה את זה ברשימת המסמכים שמבקשים: תוצאות של גישה מותרת וחסומה, למשתמש אנונימי ולמשתמש מחובר. אם האפליקציה משרתת כמה לקוחות עסקיים, הוסיפו את אותה בדיקה בין שני ארגונים. איך מריצים את הבדיקה ב-Base44: בדיקה 5 במדריך האבטחה ל-Base44. ב-Supabase: המדריך ל-RLS.
3. רשימת מפתחות ואיפה כל אחד שמור
כל מפתח (Stripe, OpenAI, ספק המיילים, מפתח השירות של מסד הנתונים): איפה הוא שמור, מי יכול לראות אותו, ומתי הוחלף לאחרונה. לצד הרשימה, בדיקה שאף מפתח סודי לא נמצא בקוד שהדפדפן מקבל ולא בהיסטוריית git. בדיקת האבטחה לאתר קוראת את הקוד שהאתר החי מגיש ומדווחת על מפתחות שדלפו. מפתח שנמצא צריך להחליף אצל הספק, כי מחיקה מהקוד לא מבטלת אותו.
4. בעלות על הקוד, ויכולת לצאת מהפלטפורמה
שלושה דברים:
- עותק מתוארך של תנאי השימוש של הפלטפורמה. לפי ניתוח של משרד עו"ד אביב אילון (יולי 2026), בתנאים של Base44 הלקוח בעלים של הקוד שנוצר רק במידה שזכויות כאלה קיימות לפי הדין, והחברה שומרת לעצמה את סביבת ההרצה ורישיון רחב. התנאים משתנים, ולכן התאריך חשוב.
- הוכחה שהקוד יוצא ורץ. ייצוא ל-GitHub, בנייה, ומסמך קצר שמסביר איך מרימים את המערכת. ב-Base44 הקוד שיוצא ממשיך לעבוד מול ה-backend של הפלטפורמה. הפרטים במדריך הייצוא מ-Base44 ל-GitHub.
- הסכמים עם כל מי שכתב קוד. פרילנסר או שותף שבנה חלק מהמערכת בלי הסכם שמעביר את הזכויות לחברה הוא פער שמשקיע ימצא.
ושאלת זכויות היוצרים על קוד שה-AI כתב: בארה"ב קבע בית המשפט לערעורים במרץ 2025, בתיק Thaler v. Perlmutter, שיצירה מוגנת דורשת מחבר אנושי. בישראל השאלה לא הוכרעה, לפי אותו מאמר. זו שאלה לעורך דין. מה שאתם כן יכולים להכין הוא תיעוד של העבודה האנושית: מי תכנן, מי בדק ומי שינה.
5. עמוד אחד: איך קוד שה-AI כתב נבדק לפני שהוא עולה
Cybersecify (יוני 2026) מתארת את המסמך הזה כחלק ממה שמשקיעים בודקים: מי מאשר שינוי, האם יש ענף מוגן שדורש אישור לפני מיזוג, ואיפה רואים את ההיסטוריה של השינויים והפריסות. גם אם אתם מייסדים לבד, כתבו מה התהליך בפועל. אם אין תהליך, זה הממצא הראשון שלכם, והוא גם הסיבה שבעיה שתוקנה יכולה לחזור בעדכון הבא של ה-AI.
6. גיבוי, שחזור, ומה עושים באירוע אבטחה
מתי נלקח הגיבוי האחרון, האם ניסיתם פעם לשחזר ממנו, ומי מטפל כשיש חשד לדליפה: מי מודיע ללקוח ותוך כמה זמן. הודעה ללקוח על אירוע אבטחה היא סעיף שתקנה 15 מחייבת אותו לכתוב בהסכם, אז הוא ישאל עליה.
7. בדיקה של מישהו מבחוץ, עם סטטוס תיקון
דוח שכתב מישהו שלא בנה את האפליקציה, עם רשימת ממצאים ומה מהם כבר תוקן. ששת המסמכים הקודמים הם הצהרות שלכם. זה הסעיף היחיד שאינו הצהרה שלכם.
בדיקת קוד, בדיקת חדירות או SOC 2: מה מבקשים מכם?
| מה זה | על מה זה עונה | על מה זה לא עונה | |
|---|---|---|---|
| סורק של הפלטפורמה | בדיקה אוטומטית של הגדרות נפוצות, למשל הסורק של Lovable לפני פרסום | טבלה בלי RLS, מפתח שהודבק בקוד, תלות עם חולשה ידועה | כללי העסק שלכם: מי אמור לראות מה, איזה שדה קובע כסף |
| בדיקה ידנית של הקוד | מפתח עובר מבפנים על ההרשאות, המפתחות, מסד הנתונים והתשלומים | מה שבור, מה לתקן קודם ולמה, כולל מה שסורק לא מבין | זו לא תקיפה של המערכת החיה וזה לא אישור תאימות |
| בדיקת חדירות | גורם חיצוני מנסה לפרוץ למערכת החיה | מה תוקף מבחוץ מצליח לעשות, נכון לתאריך הבדיקה | האם התהליך שלכם ימנע את הבעיה הבאה |
| SOC 2 | ביקורת של רואה חשבון על הבקרות והתהליכים בחברה | שיש בקרות כתובות שפועלות. Type 2 בודק אותן לאורך תקופה | האם קוד מסוים מאובטח היום |
מתי מבקשים כל אחד:
- בדיקת חדירות כחובה בחוק: לפי תקנה 5(ד), רק במאגר שחלה עליו רמת האבטחה הגבוהה, אחת ל-18 חודשים לפחות. לפי התוספת השנייה לתקנות, זו רמה שחלה בין היתר על מאגרים מסוגים מסוימים עם מידע על 100,000 אנשים ומעלה, או עם יותר מ-100 בעלי הרשאה. ברוב האפליקציות בשלב סיד הדרישה באה מהמשקיע או מהלקוח.
- בדיקת חדירות כדרישה של משקיע: לפי Cybersecify, משקיעים מצפים לדוח מ-12 החודשים האחרונים, מגורם עצמאי, עם סטטוס תיקון ובדיקה חוזרת.
- SOC 2: לפי אותו מקור, Type 1 "גבולי" בסבב A, וב-B מצפים ל-Type 2. כדאי לשאול את המשקיע מה הוא מבקש, לפני שמתחילים תהליך של חודשים.
האישור של הפלטפורמה הוא לא האישור שלכם
Lovable כותבת על עצמה שהיא מחזיקה בתקן ISO 27001:2022 ו-"SOC 2 Type II aligned", ובאותו עמוד מפרטת מה נשאר באחריות המייסד: לתקן את הממצאים הקריטיים של הסורק לפני פרסום, לוודא שכללי ה-RLS מגבילים כל משתמש לנתונים שלו, ולוודא שמפתחות של שירותים חיצוניים לא מגיעים לדפדפן. בשאלון כותבים מה הפלטפורמה מכסה ומה אתם עשיתם, כל אחד בנפרד. לפי Cybersecify, לכתוב "יש לנו SOC 2" כשאין זה מה שמפיל עסקה.
מה הבדיקה לפני השקה של VibeScale נותנת כאן, ומה לא
מה כן: מפתח בכיר עובר ביד על הקוד, מסד הנתונים, ההרשאות, המפתחות, התשלומים ועלות האירוח. תוך 5 ימי עבודה מקבלת הגישה אתם מקבלים דוח בעברית: כל ממצא עם חומרה, הסבר, דרך תיקון והערכת עלות, ושיחת מעבר של 45 דקות. זה מסמך 7 ברשימה, והעבודה עליו מייצרת גם את רוב החומר למסמכים 2 ו-3. אם הבדיקה לא מוצאת בעיות רציניות, זה כתוב בדוח, עם מה שנבדק ולמה זה תקין.
מה לא: זו לא בדיקת חדירות פורמלית ולא ביקורת SOC 2. אנחנו לא מנפיקים אישור תאימות, ולא נותנים חוות דעת משפטית על בעלות בקוד. אם המשקיע דורש דוח בדיקת חדירות מגורם עצמאי, הבדיקה שלנו היא השלב שלפניו: מתקנים את מה שנמצא, ואז הבודק החיצוני מבלה את הימים שלו על מה שבאמת דורש תוקף, ולא על מפתח חשוף או טבלה פתוחה.
כך נראה דוח לדוגמה, והבדיקה עצמה רצה לפי ה-Audit Framework.
אחרי הבדיקה: איך מראים שזה תוקן?
משקיע לא מצפה לאפס ממצאים. הוא מצפה לראות שמה שנמצא טופל. הכינו טבלה אחת: כל ממצא, החומרה שלו, הסטטוס (תוקן, בטיפול, או סיכון שהחלטתם לקבל ולמה), ותאריך התיקון. על הממצאים הקריטיים עשו בדיקה חוזרת, ותעדו אותה. את אותה טבלה, מעודכנת, אפשר לשלוח ללקוח הארגוני בדיווח השנתי שתקנה 15 מחייבת אותו לבקש. ומסמך 5 הוא מה שמראה שהתיקונים לא ייפתחו מחדש בעדכון הבא.
מקורות
- תקנות הגנת הפרטיות (אבטחת מידע), התשע"ז-2017: תקנה 15 (מיקור חוץ), תקנה 5 (סקר סיכונים ובדיקות חדירות), התוספת השנייה (רמת האבטחה הגבוהה)
- Wavect - Lovable, Bolt, and Replit App Due Diligence: שלוש השאלות, המסמכים שמבקשים והדגלים האדומים
- Cybersecify - Vibe-Coded SaaS Investor Diligence: מה משקיעים בודקים, בדיקת חדירות ו-SOC 2 לפי שלב הגיוס
- Lovable - A founder's guide to Lovable security: מה הפלטפורמה מכסה ומה באחריות המייסד
- אביב אילון, משרד עורכי דין - של מי האפליקציה שבניתם: תנאי השימוש של הפלטפורמות וזכויות יוצרים בקוד שנוצר ב-AI
המדריך הזה אינו ייעוץ משפטי. שאלות על חוזים, בעלות בקוד וחובות לפי התקנות כדאי לבדוק עם עורך דין.
יש לכם פגישה עם משקיע או שאלון מלקוח? בעמוד הבדיקה לפני השקה אפשר לקבוע שיחת וואטסאפ חינמית של 20 דקות. ספרו מי שואל ומה הוא ביקש לראות, ונגיד לכם מה מתוך הרשימה הזו אפשר להכין לבד ומה דורש בדיקה.