עיקרי הדברים
- שכבת הזהות היא הראשונה שנבדקת. אימות רב-שלבי על כל חשבון, הרשאה מזערית לפי תפקיד, ביקורת גישה רבעונית ושלילת גישה מיידית בעזיבה הן הבקרות שפותחות כל שיחת חיתום, והן גם הזולות ביותר ליישום.
- סודות בקוד הם הביטוי המיידי של הבעיה. ב-2024 זוהו כ-39 מיליון סודות שדלפו לפלטפורמת ניהול קוד מובילה, ונתוני תעשייה מ-2026 מצביעים על כך שקומיטים שנכתבו בסיוע AI מדליפים סודות בשיעור כפול מהשיעור הבסיסי. מחקרי honeypot מצאו שאישורי גישה שנחשפים במאגר קוד ציבורי מנוצלים תוך דקות עד שעות.
- כלי AI לפיתוח דורשים ממשל משלהם: רשימת כלים מאושרים, בדיקת עמיתים לכל פלט לפני מיזוג, והרשאות מצומצמות לסוכנים אוטומטיים. התיעוד של השימוש הזה משמש היום גם בבדיקת נאותות וגם בשאלון החיתום.
- התיעוד הוא הראיה. בחיתום, בבדיקת נאותות ובחקירת תביעה נבחן מה אפשר להראות ולא מה תוכנן, ובישראל מצטרפות לכך תקנות הגנת הפרטיות (אבטחת מידע), חובת הדיווח לרשות להגנת הפרטיות ותיקון 13.
זהות וגישה: הבקרה שנבדקת ראשונה
שכבת הזהות היא הנקודה שבה מתחילים כמעט כל שאלוני החיתום. אימות רב-שלבי מחויב על GitHub או GitLab, על קונסולות הענן, על הדוא״ל, על ה-VPN ועל ממשקי הניהול, בלי חריגים לחשבונות שירות שמישהו שכח. הרשאה מזערית משלימה את התמונה: לכל משתמש רק מה שנדרש לתפקידו.
שתי בקרות נוספות משלימות את השכבה הזאת ונשכחות בדרך כלל. הראשונה היא ביקורת גישה תקופתית, אחת לרבעון לכל הפחות, שבודקת מי מחזיק בהרשאה והאם היא עדיין נדרשת. השנייה היא שלילת גישה מיידית בעזיבה, לעובדים ולקבלנים כאחד, לפי נוהל כתוב שמסתיים ברשימת מערכות מסומנת. חשבונות ניהוליים ראויים לניהול מרוכז נפרד. המטרה היא למנוע מצב שבו מפתח בודד מחזיק את המפתחות לכל הסביבה. שתי הבקרות האלה זולות ליישום ומופיעות כמעט בכל שאלון חיתום.
ניהול מאגרי הקוד
ברירת המחדל צריכה להיות מאגר פרטי, וחשיפה ציבורית צריכה להיות החלטה מודעת עם בעלים ותאריך. על הענף הראשי מופעלת הגנה שחוסמת דחיפה ישירה ומחייבת אישור של בודק אחד לפחות לפני מיזוג, עם רישום שנשמר.
סריקה תקופתית של נראות המאגרים משלימה את הבקרה, מפני שמאגר שנפתח לציבור לצורך הדגמה נשאר פתוח זמן רב אחרי שהסיבה נעלמה.
סודות: סריקה, חסימה ורוטציה
סוד שנכנס למאגר נשאר בהיסטוריה גם אחרי שהשורה נמחקה, ולכן הטיפול בו מחולק לשלושה שלבים נפרדים. השלב הראשון מונע כניסה. השניים שאחריו מזהים מה שכבר נכנס ומבטלים את הערך שנחשף. מחקרי honeypot מצאו שאישורי גישה שנחשפים במאגר קוד ציבורי מנוצלים תוך דקות עד שעות, כך שחלון התגובה קצר.
ההיקף גדול מכפי שנדמה. ב-2024 זוהו כ-39 מיליון סודות שדלפו לפלטפורמת ניהול קוד מובילה, ונתוני תעשייה מ-2026 מצביעים על כך שקומיטים שנכתבו בסיוע AI מדליפים סודות בשיעור כפול מהשיעור הבסיסי. הסיבה פשוטה: הדוגמה שהמודל ראה כללה מפתח מוטמע, והוא משחזר את מה שראה. ניהול סודות מרוכז בכספת ייעודית, לצד סריקה וחסימה, מוציא את הערכים מהקוד ומשאיר בו הפניה בלבד.
סריקת סודות, חסימת דחיפה ורוטציית אישורים:
| שלב | מה מפעילים | מה קורה כשמתגלה סוד |
| לפני הדחיפה | בדיקת pre-commit מקומית עם GitLeaks או TruffleHog, לצד הנחיה ברורה למפתחים | הדחיפה נעצרת אצל המפתח, והערך מוחלף במשתנה סביבה לפני שהקוד יוצא מהמחשב |
| בזמן הדחיפה | push protection פעיל ב-GitHub או ב-GitLab על כל המאגרים, כולל הפרטיים | הדחיפה נחסמת אוטומטית, ונפתחת התרעה לבעלי המאגר עם סוג הסוד שזוהה |
| סריקה שוטפת | סריקת סודות על כל הענפים ועל כל היסטוריית הקומיטים, ולא על השינוי האחרון בלבד | נפתח אירוע עם זמן יעד לרוטציה, ומפתח שנמצא בהיסטוריה מבוטל גם אם השורה נמחקה |
| רוטציה | כספת סודות כמו AWS Secrets Manager או HashiCorp Vault, עם תדירות רוטציה לפי רמת ההרשאה | הערך הישן מבוטל, החדש מונפק דרך הכספת, והקוד מקבל הפניה במקום מחרוזת |
| תחקיר | בדיקת יומני גישה לכל התקופה שבה הסוד היה חשוף | נקבע האם נעשה שימוש, הממצא מתועד, ומופעלות חובות הדיווח החלות על המקרה |
ממשל כלי AI לפיתוח
כלי כמו Copilot, Cursor או Claude Code נכנסו לצנרת הפיתוח מהר יותר מהמדיניות שאמורה לתחום אותם, והממשל הנדרש מסתכם בארבעה דברים: רשימת כלים מאושרים, כללים לגבי מה מותר להזין להם, בדיקת עמיתים אנושית לכל פלט לפני מיזוג, וסריקה סטטית שחלה על כל שורת קוד ללא קשר לזהות הכותב. סוכנים אוטומטיים מקבלים הרשאה מזערית ונשארים מחוץ לסביבת הייצור.
התיעוד של השימוש הזה הפך לפריט שנשאל עליו בבדיקת נאותות ובחיתום. תיוג קומיטים שנוצרו בסיוע כלי מאפשר למדוד היקף, לתעדף בדיקות ולענות על השאלה בלי לנחש. קבצי ההנחיה של הכלים ראויים לבקרת גרסאות ולבדיקת עמיתים כמו כל קוד אחר, מפני שהוראה שמוזרקת אליהם משנה את הפלט בלי שהמפתח מבחין בכך.
כלי שאין לו בעלים במסמך הוא כלי שאיש בארגון לא יכול להעיד עליו בשאלון החיתום.
צנרת, סביבות וגיבויים
הצנרת היא המקום שבו בקרה נהיית אוטומטית או נשארת המלצה. סריקה סטטית, ניתוח תלויות וסריקת סודות מוגדרים כבדיקות חובה שחוסמות מיזוג בממצא חמור, והרשאות הצנרת מצומצמות למינימום הדרוש. ההפרדה בין סביבת הפיתוח לבין סביבת הייצור נעשית עם אישורי גישה נפרדים לכל אחת.
בצד הגיבויים, שלוש נקודות קובעות את התוצאה באירוע כופרה. גיבוי יומי לנתונים החיוניים הוא הבסיס. מעליו נדרש עותק שמוגן מפני שינוי ואינו נגיש מהסביבה שעלולה להיות מוצפנת. בדיקת שחזור בפועל נעשית אחת לרבעון, עם מדידת הזמן שלקח. חברה שלא בדקה שחזור מגלה את בעיית הגיבוי ביום הגרוע ביותר.
ניטור, תגובה לאירוע וחובות הדיווח בישראל
נוהל תגובה לאירוע מוכיח את עצמו רק אחרי שתורגל. הנוהל מגדיר מי מוביל, מי מדבר עם לקוחות, מי מפעיל את הביטוח ומהם שלבי הטיפול, והוא נבדק אחת לשנה בתרגיל שולחני שמסתיים בפרוטוקול, לצד רישום מרוכז של גישות ושל שינויי תצורה עם התרעות על חריגות.
בישראל נוספת שכבת חובות משלה. תקנות הגנת הפרטיות (אבטחת מידע) מחייבות מיפוי מאגרים, ניהול הרשאות, תיעוד אירועי אבטחה וחובת דיווח לרשות להגנת הפרטיות על אירוע אבטחה חמור, לפי רמת האבטחה של המאגר. תיקון 13 לחוק הגנת הפרטיות הרחיב את סמכויות האכיפה של הרשות והוסיף עיצומים כספיים. מעבר לכך, חוזה עם לקוח ארגוני מייצר חובת עדכון משלו, ולעיתים גם דרישה להציג אישור קיום ביטוחים בנוסח שהלקוח קבע כתנאי להמשך ההתקשרות. שלושת מסלולי הדיווח האלה צריכים להופיע באותו נוהל, עם שמות ולוחות זמנים. מי שממתין לאירוע כדי לברר מי מדווח למי מאבד את השעות הראשונות, שהן היקרות ביותר. הנוהל צריך לכלול גם את פרטי הקשר של המבטח, כדי שההודעה תצא במקביל לטיפול הטכני.
מה מוכיחים בחיתום
חתם מבקש ראיה, ולא תיאור. ההבדל בין תשובה שמחזיקה לתשובה שמתומחרת נמצא במסמך שמצורף אליה. הטבלה הבאה מציגה את הבקרות המרכזיות, את מה שמיישמים בפועל, ואת הפריט שמוכיח את זה כשמישהו שואל.
בקרות ליבה, יישום והוכחה:
| בקרה | מה מיישמים בפועל | איך מוכיחים את זה בחיתום |
| אימות רב-שלבי | MFA מחויב על GitHub או GitLab, קונסולות ענן, דוא״ל, VPN וממשקי ניהול | צילום מדיניות ההרשאה ברמת הארגון ודוח משתמשים שמראה אכיפה מלאה |
| הרשאה מזערית | הרשאות לפי תפקיד, ביקורת גישה רבעונית, שלילת גישה מיידית בעזיבה | פרוטוקול ביקורת הגישה האחרונה ורשימת עזיבות עם מועד שלילת הגישה בפועל |
| הגנה על הענף הראשי | חסימת דחיפה ישירה, חובת בדיקת עמיתים ואישור בודק אחד לפחות | הגדרות ההגנה במאגר ורישום Pull Request עם שם המאשר ותאריך |
| סודות | סריקת סודות על כל המאגרים, push protection פעיל, כספת סודות מרוכזת | דוח ממצאים תקופתי ורישום חסימות שמנעו כניסת סוד למאגר |
| רוטציית אישורים | תדירות רוטציה לפי רמת ההרשאה ונוהל חשיפה עם זמני יעד | טבלת מפתחות עם מועד הרוטציה האחרון ותיעוד אירוע חשיפה שטופל |
| ממשל כלי AI | רשימת כלים מאושרים, בדיקת עמיתים לפלט, הרשאות מצומצמות לסוכנים | מסמך מדיניות עם בעלים ותאריך עדכון, ותיוג קומיטים שנוצרו בסיוע כלי |
| גיבוי ושחזור | גיבוי יומי, עותק מוגן מפני שינוי, בדיקת שחזור רבעונית | דוח בדיקת השחזור האחרון עם הזמן שנמדד ועם שם מי שביצע |
| תגובה לאירוע | נוהל כתוב, בעלי תפקידים מוגדרים ומסלולי דיווח מסומנים | פרוטוקול התרגיל השולחני האחרון ורשימת אנשי קשר מעודכנת |
מאיזה סיכון כל בקרה מגנה, ואיזה ענף עשוי להגיב
בקרה נבנית מול תרחיש, וכל תרחיש נופל בסופו של דבר על ענף ביטוח אחר. המיפוי הזה שימושי גם בתעדוף התקציב וגם בשיחה עם החתם, מפני שהוא מסביר למה נדרשת דווקא הבקרה הזאת. הברוקר (LAMDA Broking) מביא את שאלון החיתום לצוות הפיתוח לפני החידוש, כדי שהתשובות ייבנו על ראיות קיימות ולא ייכתבו בלחץ של יום אחרון.
סיכון, בקרה מפחיתה וענף הביטוח הרלוונטי:
| סיכון | הבקרה שמפחיתה אותו | קו הביטוח שעשוי להגיב |
| מפתח גישה שדלף שימש לחדירה לסביבת הענן | סריקת סודות, push protection ורוטציה מהירה | ביטוח סייבר, ולעיתים גם אחריות מקצועית אם נפגע שירות ללקוח |
| כופרה שהצפינה סביבות ייצור ואת הגיבוי המקוון | עותק גיבוי מוגן מפני שינוי, הפרדת סביבות ואימות רב-שלבי | ביטוח סייבר, בכפוף להחרגות, לתת-גבולות ולתנאי הנוסח |
| חולשה במוצר שגרמה נזק ללקוח עסקי | בדיקת עמיתים, סריקה סטטית בצנרת ובדיקות חדירה תקופתיות | אחריות מקצועית לחברות טכנולוגיה |
| השבתת שירות ממושכת בגלל תקלה בצנרת או אצל ספק | ניטור והתרעות, יעדי RTO ו-RPO מוגדרים ומיפוי תלות בספקים | ביטוח סייבר לרוב, לצד סעיפי רמת השירות בחוזה הלקוח |
| דליפת מידע אישי של לקוחות ישראליים | מיפוי מאגרים, בקרות לפי תקנות אבטחת המידע ונוהל דיווח לרשות | ביטוח סייבר, לרבות הוצאות טיפול ודיווח בכפוף לנוסח הפוליסה |
| מצג למשקיעים או ללקוח על בקרות שלא התקיימו | סנכרון שנתי בין ההצהרות לבין התיעוד התפעולי | ביטוח דירקטורים ונושאי משרה |
התיעוד הוא הראיה
רשימת בקרות בלי תיעוד היא רשימת כוונות. בחיתום ובחקירת תביעה נבחן מה שאפשר להראות: מי ביצע, מתי, ובאיזה כלי. עבור כל בקרה משמעותית ראוי שיישמר תיעוד קצר, בין אם מדובר בביקורת גישה, בבדיקת שחזור או בתרגיל תגובה לאירוע.
דוח SOC 2 הוא דוח ביקורת שמנפיקה פירמת רואי חשבון עצמאית מול קריטריוני AICPA לתקופה מוגדרת, ולא תעודת הסמכה שמישהו מחזיק. גם כללי הגילוי של ה-SEC משנת 2023 מדברים על תיאור אופן הפיקוח של הדירקטוריון על סיכוני סייבר, לאחר שדרישת הגילוי בנוגע למומחיות סייבר בקרב חברי הדירקטוריון הוסרה מהנוסח הסופי. שני הדברים מצביעים לאותו כיוון: מה שנמדד הוא התהליך המתועד.
טעויות נפוצות
- מפעילים MFA על מאגר הקוד ומשאירים חשבון ניהולי אחד בענן בלי אימות, בדרך כלל חשבון ישן של מייסד.
- מוחקים שורה שהכילה מפתח גישה ומניחים שהסוד נעלם, בעוד שהוא נשאר בהיסטוריית הקומיטים וזמין לכל מי שמושך את המאגר.
- מגדירים גיבויים ולא בודקים שחזור, ואז מגלים באירוע כופרה שהעותק פגום או נגיש מאותה סביבה שהוצפנה.
- מאשרים כלי AI לפיתוח בעל פה, בלי רשימה כתובה ובלי בעלים לעדכון.
- נותנים לסוכן אוטומטי הרשאות רחבות בענן כדי לחסוך זמן הגדרות.
- כותבים נוהל תגובה לאירוע ולא מתרגלים אותו, ואז מגלים בזמן אמת שאין רשימת אנשי קשר מעודכנת.
- ממלאים את שאלון החיתום לפי מה שהיה אמור להיות מיושם ולא לפי מה שרץ בסביבת הייצור.
שאלות נפוצות
כמה זמן לוקח ליישם את הרשימה הזאת בסטארטאפ קטן?
הבקרות הבסיסיות מתבצעות בימים. אכיפת אימות רב-שלבי והפיכת מאגרים לפרטיים הן הגדרות שקיימות בפלטפורמה ומופעלות מיד, וכך גם סריקת סודות עם push protection. הרכיבים שדורשים תכנון של שבועות עד חודשים הם כספת סודות מרוכזת, נוהל תגובה לאירוע שנבדק בתרגיל, ומוכנות לדוח SOC 2. הסדר הנכון הוא להתחיל במה שמופעל היום.
האם דוח SOC 2 מייתר את הצ׳ק־ליסט?
הדוח מכסה חלק ניכר מהנושאים, אך הוא דוח ביקורת שמנפיקה פירמת רואי חשבון עצמאית מול קריטריוני AICPA לתקופה מוגדרת ועל בקרות שהארגון עצמו הגדיר. חתם ולקוח ארגוני עדיין שואלים שאלות תפעוליות על אכיפת MFA, על בדיקת שחזור ועל תרגיל תגובה לאירוע. ההיקף שנבדק בדוח הוא שקובע כמה משקל הוא מקבל.
על מה חתמים מתעכבים הכי הרבה?
על חמישה נושאים שחוזרים כמעט בכל שאלון: אכיפת אימות רב-שלבי, שלמות הגיבויים ובדיקת השחזור, נוהל תגובה לאירוע, ניהול הרשאות, ותדירות סריקת החולשות. תשובה מעורפלת באחד מהם מתומחרת, ולעיתים מובילה להחרגה או לדרישת תיקון כתנאי לחידוש. תשובה מגובה במסמך מקצרת את התהליך.
מה עושים כשמתגלה שמפתח גישה דלף למאגר ציבורי?
מבטלים את המפתח לפני כל פעולה אחרת, ורק אחר כך בודקים את היקף השימוש. מחקרי honeypot מצאו שאישורי גישה שנחשפים במאגר קוד ציבורי מנוצלים תוך דקות עד שעות, ולכן מחיקת השורה בלבד משאירה את החשיפה פתוחה. לאחר הביטול בודקים יומני גישה לתקופת החשיפה, מתעדים את הממצא ומפעילים את חובות הדיווח החלות.
האם אפשר להשתמש בכלי AI לפיתוח כשללקוח יש דרישות אבטחה מחמירות?
ברוב המקרים כן, בתנאי שהשימוש מתועד ומבוקר. מה שהלקוח בודק הוא רשימת כלים מאושרים, הכללים לגבי מידע שמוזן לכלי, בדיקת עמיתים לפלט לפני מיזוג, וסריקה סטטית שחלה על כל הקוד. איסור גורף מייצר שימוש לא מדווח, שקשה יותר להסביר בבדיקת נאותות מאשר שימוש מבוקר.
האם יישום הרשימה מבטיח כיסוי ביטוחי?
הוא משפר את העמידה מול חתמים ואת סיכויי קבלת תנאים טובים יותר, בלי להוות הבטחה. תנאי הכיסוי, ההחרגות והגבולות נקבעים בנוסח הפוליסה ותלויים במחזור, בפרופיל הלקוחות, בסוגי המידע ובבקרות בפועל. הדרך הנכונה היא לבחון את הנוסח מול תרחישי הסיכון של החברה לפני החתימה, ולא אחרי אירוע.
סטארטאפ שמנהל בקרות בסיסיות ומתעד אותן באופן שוטף מגיע לחיתום, לרכש ולחקירת תביעה עם אותה תשובה, וזו הסיבה שהצ׳ק־ליסט הזה שווה יותר מכל השקעה נקודתית בכלי אבטחה נוסף.
האמור לעיל הוא מידע כללי בלבד ואין בו משום ייעוץ ביטוחי, משפטי או מקצועי אחר. תנאי הכיסוי, ההחרגות והחובות נקבעים בנוסח הפוליסה הספציפי ובכפוף לדין החל. יש לבחון כל מקרה לגופו מול נוסח הפוליסה ומול יועץ מוסמך.


































































