המאמר עובר על שרשרת הנזק ועל קווי הביטוח שעשויים להגיב לכל חוליה בה, ומסביר מה חתמים בודקים היום לפני שהם מציעים כיסוי לחברת תוכנה.
איך מפתח אחד בקוד הופך לאירוע: שרשרת הנזק
מפתח API, טוקן גישה או סיסמה לבסיס נתונים שנכתבים בתוך הקוד הופכים לחלק מכל עותק של אותו קוד. מי שמגיע לעותק כזה מקבל את ההרשאות שהמפתח מעניק, בלי לפרוץ דבר.
הדליפה עצמה כמעט תמיד שגרתית. מפתח נכתב לצורך בדיקה מקומית ונשכח בקובץ הגדרות. קובץ משתני סביבה (env) נדחף למאגר בטעות. מאגר פנימי נפתח לציבור לכמה שעות. מפתח נרשם בלוג שנשלח לכלי ניטור של צד שלישי, או נארז בתוך קונטיינר שמפורסם במאגר תמונות פתוח. אף אחד מהמעורבים לא התכוון לחשוף דבר.
מרגע החשיפה, הזמן לתגובה קצר. בוטים סורקים את GitHub ומאגרים ציבוריים אחרים ברציפות, ומפתח שמופיע בקומיט ציבורי עשוי להיות מנוצל בתוך דקות. נתוני תעשייה מ-2026 מצביעים על כך שרוב הסודות שדלפו עדיין תקפים חודש אחרי החשיפה, וחלק גדול מהם נשאר פעיל שנים.
מה שקורה אחר כך תלוי בהרשאות של המפתח:
- גישה למידע: מפתח לבסיס נתונים או לאחסון בענן מאפשר העתקה של מידע אישי או עסקי, ומשם חובת דיווח ותביעות.
- שימוש במשאבים: מפתח של ספק ענן או של שירות AI מפעיל שרתים ומודלים על חשבון החברה.
- מעבר ללקוחות: בחברת SaaS, מפתח שפותח גישה לסביבות של לקוחות מעביר את האירוע אל הלקוחות עצמם. מכתב דרישה הוא בדרך כלל הצעד הבא.
- תשלומים: מפתח סודי של ספק סליקה עשוי לאפשר החזרים או העברות שלא אושרו.
הטעות קטנה, אבל ההרשאות שהיא מעבירה לתוקף הן ההרשאות של המערכת עצמה.
קוד שעובד וקוד שבטוח: למה הטעות נפוצה דווקא עכשיו
היקף הדליפות גדל מהר יותר מבעבר, בעיקר בגלל כלי פיתוח מבוססי AI ובגלל ריבוי שירותי AI שכל אחד מהם דורש מפתח משלו. מתכנתים מקבלים קוד שרץ מהר, וקוד שנכתב כדי לרוץ מהר נוטה להחזיק את המפתח בגוף הקובץ.
נתוני תעשייה שפורסמו ב-2026 מצביעים על כ-29 מיליון סודות חדשים שנחשפו בקומיטים ציבוריים ב-GitHub במהלך 2025, עלייה של כשליש לעומת השנה הקודמת. מספר המפתחות של שירותי AI שדלפו עלה באותה תקופה בכ-80%. קומיטים שנכתבו בסיוע עוזרי קוד מבוססי AI הכילו סודות בשיעור של בערך פי שניים מהממוצע, ומאגרים פנימיים הכילו סודות בשיעור גבוה בהרבה ממאגרים ציבוריים. עוזר קוד משלים את מה שהמתכנת ביקש, ואם יש בהקשר מפתח פעיל הוא עשוי להיכנס לקוד שנוצר. מדיניות שמחייבת משתני סביבה או כספת סודות כמו HashiCorp Vault, יחד עם סריקה אוטומטית בכלים כמו TruffleHog או GitLeaks לפני כל מיזוג, מצמצמת את הסיכון. היא עובדת רק כשהיא נאכפת בצינור ה-CI עצמו.
אירוע אחד, כמה קווי ביטוח
מפתח שדלף עשוי להפעיל יותר מפוליסה אחת. כל קו נועד להגיב לרכיב אחר של הנזק, והמחלוקות מתחילות בתפרים שביניהם.
| רכיב הנזק באירוע | הקו שנקרא להגיב | הטענה שמקצה את הנזק לקו אחר | מה קובע בנוסח |
| חקירה דיגיטלית (Forensics), ייעוץ משפטי ודיווח לרגולטור | ביטוח סייבר, רכיב ניהול האירוע | האירוע נבע מכשל במוצר ולכן שייך לאחריות המקצועית | הגדרת אירוע סייבר ותנאי הסכמה מראש לספקים |
| השבתת השירות ואובדן הכנסות | ביטוח סייבר, השבתה עסקית (Business Interruption) | השיבוש נבע מתקלה תפעולית ולא מתקיפה | תקופת ההמתנה והגדרת הפרעה למערכת |
| תביעת לקוח שהסביבה שלו נפרצה דרך המוצר | אחריות מקצועית טכנולוגית (Tech E&O) | הנזק נובע מהפרת חוזה ולא מרשלנות מקצועית | החרגת אחריות חוזית והיחס בין הפוליסות |
| חיוב חריג בחשבון הענן או בשירותי AI | הרחבת שימוש לרעה בשירותים, אם נרכשה | חיוב של ספק שירות הוא הוצאה תפעולית ולא נזק למערכות | קיום ההרחבה וגבול המשנה |
| העברה או החזר כספי שלא אושרו דרך API של תשלומים | נאמנות ומעילות (Crime) או הרחבת הונאה בפוליסת הסייבר | ההעברה בוצעה במערכת של צד שלישי | הגדרת הונאת מחשב (Computer Fraud) ותנאי אימות |
| תביעת בעלי מניות או חקירה נגד נושאי משרה | דירקטורים ונושאי משרה (D&O) | זו תביעת סייבר ולכן מוחרגת | החרגת סייבר בפוליסת ה-D&O ומנגנון ההקצאה (Allocation) |
ביטוח סייבר (Cyber)
נועד להגיב בעיקר לנזק העצמי של החברה, מניהול האירוע ועד ההשבתה העסקית, וכן לאחריות כלפי צד שלישי בגין פגיעה בפרטיות. מחוץ לתחומו נותרים בדרך כלל הכשל המקצועי של המוצר עצמו והעלות של שדרוג מערכות מעבר למצב שלפני האירוע (Betterment). פירוט הרכיבים: ביטוח סייבר לחברות טכנולוגיה.
אחריות מקצועית טכנולוגית (Tech E&O)
הליבה של הפוליסה היא תביעה של לקוח שטוען שהמוצר או השירות לא פעלו כמובטח וגרמו לו נזק כספי. כשמפתח שדלף מאפשר לתוקף להגיע לסביבה של לקוח, זו לרוב הפוליסה שהלקוח פוגש. הנזק העצמי של החברה נותר מחוץ לה, ולעיתים גם התחייבויות חוזיות שחורגות מהאחריות שהייתה חלה ממילא לפי הדין.
נאמנות ומעילות (Crime / Fidelity)
עשויה להגיב להעברת כספים שבוצעה באמצעות גישה לא מורשית למערכות, בכפוף להגדרת הונאת מחשב בפוליסה. אובדן שנגרם כשעובד מורשה הוטעה לבצע את ההעברה בעצמו נותר בדרך כלל מחוץ לה, אלא אם נרכשה הרחבה להונאת הנדסה חברתית (Social Engineering Fraud).
דירקטורים ונושאי משרה (D&O)
כאן נמצאות התביעות נגד נושאי המשרה עצמם, למשל טענה של בעלי מניות שהדירקטוריון לא פיקח על ניהול סיכוני הסייבר. הנזק הישיר של האירוע שייך לפוליסות אחרות. חלק מהנוסחים כוללים החרגת סייבר רחבה, ולכן צריך לקרוא אותה יחד עם פוליסת הסייבר של אותה חברה.
חשבון הענן שלא הזמנתם: שימוש לרעה במשאבים
מפתח גנוב של AWS או של ספק מודלים כמו OpenAI או Anthropic מאפשר לתוקף להפעיל משאבים על חשבון החברה. החיוב מגיע בחשבונית הרגילה, ולעיתים מתגלה רק בסוף החודש.
בעבר השימוש הנפוץ היה כריית מטבעות קריפטוגרפיים על שרתי הקורבן (Cryptojacking). היום מתווסף לכך שימוש במודלי שפה גדולים דרך חשבון גנוב, והתוקף מוכר את הגישה לאחרים. מחקרי אבטחה שפורסמו ב-2024 העריכו ששימוש כזה, כל עוד לא התגלה, עלול לעלות לבעל החשבון עשרות אלפי דולרים ביום.
מבחינת ביטוח, זו אחת החוליות החלשות בשרשרת.
חיוב של ספק ענן נראה לחתם כמו הוצאה תפעולית, ופחות כמו נזק שנגרם למערכות. חלק מפוליסות הסייבר מציעות הרחבה לשימוש לרעה בשירותים (Service Fraud) או לגניבת משאבי מחשוב, בדרך כלל בגבול משנה נמוך מגבול הפוליסה. פוליסות אחרות שותקות בנושא, ושתיקה בנוסח מקשה לבסס דרישה.
ספקי ענן מעניקים לעיתים זיכוי על שימוש לרעה, אבל לפי שיקול דעתם ובתנאי של תגובה מהירה.
התראות על חריגה בתקציב והגבלת מכסות לכל מפתח מצמצמות את התקרה של החשבון עוד לפני שמגיעים לפוליסה.
מה הרגולטור שואל אחרי שהמפתח דלף
השאלה הראשונה של הרגולטור עוסקת כמעט תמיד בזמנים: מתי החברה ידעה על האירוע ומתי דיווחה. השאלה השנייה היא אם אמצעי האבטחה היו סבירים, ומפתח שנשמר בקוד מחזק את הטענה שלא היו.
ישראל
תקנות הגנת הפרטיות (אבטחת מידע), התשע"ז-2017, מחייבות דיווח לרשות להגנת הפרטיות על אירוע אבטחה חמור במאגר מידע. תיקון 13 לחוק הגנת הפרטיות, שנכנס לתוקף ב-14 באוגוסט 2025, העניק לרשות סמכות להטיל עיצומים כספיים. ביולי 2026 הטילה הרשות את העיצום הראשון מכוח התיקון, בגין דיווח שנמסר כחודשיים אחרי שהארגון ידע על אירוע אבטחה חמור.
לפי עמדת הרשות, הדיווח צריך להימסר בסמוך לגילוי ועל בסיס המידע שקיים באותו רגע, ואפשר להשלים פרטים בהמשך. לצד הרגולציה, לקוחות גדולים ומכרזים דורשים לא פעם אישור קיום ביטוחים שכולל את קוד 339 (סיכוני סייבר), שנוסף לרשימה הסגורה של הנוסח האחיד ב-2023.
ארצות הברית
ה-FTC ניהלה הליך אכיפה נגד חברה ונגד המנכ"ל שלה באופן אישי, לאחר שפרטי גישה לסביבת הענן נשמרו במאגרי קוד בלי סריקה. הצו שניתן חייב את המנכ"ל ליישם תוכנית אבטחת מידע גם בחברות שינהל בעתיד. חברות ציבוריות כפופות לכללי ה-SEC מ-2023, שמחייבים דיווח על אירוע סייבר מהותי בטופס 8-K בתוך ארבעה ימי עסקים מקביעת המהותיות, וגילוי שנתי על אופן הפיקוח של הדירקטוריון על סיכוני סייבר. עתירות לביטול חובת הדיווח המיידי טרם הוכרעו.
האיחוד האירופי
ה-GDPR מחייב דיווח לרשות הפיקוח בתוך 72 שעות מרגע שהארגון נודע לפגיעה במידע אישי. מ-11 בספטמבר 2026, יצרנים של מוצרים עם רכיב דיגיטלי שנמכרים באיחוד כפופים לחובות הדיווח של חוק החוסן הקיברנטי (Cyber Resilience Act): התראה מוקדמת בתוך 24 שעות על חולשה שמנוצלת בפועל, והודעה מפורטת בתוך 72 שעות. דרישות התכנון המאובטח של אותו חוק יחולו מדצמבר 2027, ומפתח קבוע שמוטמע במוצר קשה ליישב איתן. חברה ישראלית עם חברה בת באיחוד צריכה לבדוק אם הפוליסה הקבוצתית חלה גם על הישות המקומית, מאחר שמבטח ממדינה שלישית מוגבל במתן שירותים ישירים בתוך האיחוד.
אסיה והפסיפיק
בסינגפור, חוק הגנת המידע האישי (PDPA) מחייב דיווח לרשות בתוך שלושה ימים מרגע שהוערך כי הפגיעה מחייבת דיווח. ביפן, חוק ה-APPI דורש דיווח מקדים מהיר ודוח סופי בתוך 30 יום, או 60 יום באירוע שנגרם בכוונה זדונית. בהודו, תקנות ה-DPDP מנובמבר 2025 קובעות דוח מפורט בתוך 72 שעות, עם אכיפה מלאה ממאי 2027. בהודו ובסין נדרש בדרך כלל מבטח מקומי, כך שפוליסה גלובלית עשויה להזדקק לפוליסות מקומיות משלימות.
מה בדיוק השתנה בשולחן החיתום
חתמים של ביטוח סייבר ואחריות מקצועית לחברות תוכנה שואלים ישירות איך החברה מנהלת סודות בקוד. התשובות נכנסות להצעת הביטוח, והצעת הביטוח היא הבסיס שעליו נבחנת כל תביעה בהמשך.
חוק חוזה הביטוח מטיל על המבוטח חובה להשיב תשובות מלאות וכנות לשאלות שנשאל בעניין מהותי. תשובה לא נכונה עשויה להביא להפחתה יחסית של תגמולי הביטוח, ובמקרים של כוונת מרמה אף לפטור את המבטח. בפוליסות שנכתבות בשוק הבינלאומי, כולל Lloyd's, חלק מהנוסחים כוללים גם התחייבות לשמור על רמת אבטחה מינימלית לאורך תקופת הביטוח. הברוקר (LAMDA Broking) עובר עם צוות הפיתוח ועם מנהל אבטחת המידע על שאלון החיתום לפני הגשתו, כדי שהתשובות ישקפו את מה שקורה בפועל בצינור ה-CI.
| בקרה | מה מיישמים בפועל | איך מוכיחים את זה בחיתום |
| ניהול סודות מרכזי | כספת סודות או שירות ניהול סודות של ספק הענן, בלי מפתחות בקבצי קוד | מדיניות כתובה ותיעוד של התצורה |
| סריקת סודות אוטומטית | סריקה בכל קומיט ובכל Pull Request, וחסימת מיזוג כשנמצא סוד | דוח סריקה אחרון ונתוני טיפול בממצאים |
| סבב מפתחות (Rotation) | תוקף מוגבל למפתחות ונוהל ביטול מיידי כשמפתח נחשף | נוהל תגובה והיסטוריית סבבים |
| הרשאות מינימליות | כל מפתח מקבל רק את ההרשאות שהוא צריך, עם מכסת שימוש | מדיניות הרשאות ודוח סקירה תקופתי |
| הגנה על מאגרי הקוד | אימות רב-שלבי (MFA) לכל המשתמשים והסרת גישה מיידית בעזיבה | הגדרות הארגון ב-GitHub או ב-GitLab |
| ביקורת חיצונית | דוח SOC 2 מרואה חשבון בלתי תלוי או הסמכת ISO 27001 שכוללים בקרות פיתוח | הדוח העדכני והטיפול בחריגים |
מפתח שדלף לפני שנים ונוצל רק עכשיו מעלה שאלה נוספת. פוליסות סייבר ואחריות מקצועית נכתבות בדרך כלל על בסיס תביעה שהוגשה (Claims Made), עם תאריך רטרואקטיבי. מעבר בין מבטחים בלי שמירה על התאריך הרטרואקטיבי עלול להשאיר דליפה ישנה בלי מענה, וזה נכון במיוחד לחברות SaaS שמחליפות מבטח לקראת גיוס או עסקת Enterprise.
טעויות נפוצות
הטעויות הנפוצות ביותר נובעות מהנחות על מה שכבר טופל ועל מה שהפוליסה כוללת. חלקן טכניות, וחלקן נוגעות לשאלון החיתום ולדיווח.
- "מחקנו את השורה, אז זה נסגר." ההיסטוריה של Git שומרת את המפתח, וכך גם כל עותק שכבר נמשך. בלי ביטול המפתח, הפתח נשאר.
- הנחה שמאגר פרטי הוא מקום בטוח. מאגרים פנימיים נגישים לעובדים, לקבלנים ולכלים משולבים, ומכילים סודות בשיעור גבוה יותר ממאגרים ציבוריים.
- תשובה אופטימית בשאלון החיתום. שאלון שמתאר סריקה אוטומטית שלא קיימת בפועל עלול לשמש נגד החברה ביום התביעה.
- התעלמות מחיובי הענן. רוב הפוליסות לא מכסות אותם כברירת מחדל.
- המתנה לתמונה מלאה לפני דיווח. ברוב מערכות הדין הדיווח הראשוני נמדד מרגע הידיעה, ובישראל הרשות כבר הטילה עיצום בגלל דיווח מאוחר.
שאלות נפוצות
מפתח API שלנו דלף ל-GitHub ומחקנו אותו תוך שעה. האם זה נחשב אירוע סייבר?
ייתכן מאוד. מפתח שהיה חשוף במאגר ציבורי עשוי להיות מנוצל בתוך דקות, והמחיקה משאירה אותו בהיסטוריית הגרסאות. יש לבטל את המפתח מיד, לבדוק ביומני הגישה אם נעשה בו שימוש ולתעד את הבדיקה. אם יש חשש לגישה למידע אישי, יש לבחון את חובת הדיווח ואת חובת ההודעה למבטח לפי תנאי הפוליסה.
האם ביטוח סייבר מכסה חיוב חריג בחשבון הענן אחרי שמפתח נגנב?
תלוי בנוסח. חלק מהפוליסות כוללות הרחבה לשימוש לרעה בשירותים או לגניבת משאבי מחשוב, בדרך כלל בגבול משנה. פוליסות אחרות שותקות בנושא, וחיוב של ספק ענן עלול להיחשב הוצאה תפעולית. מומלץ לבדוק את קיום ההרחבה ואת גבול המשנה כבר לפני החידוש.
רכשנו ביטוח סייבר. האם נדרש גם ביטוח אחריות מקצועית טכנולוגית?
לחברת תוכנה, לרוב כן. ביטוח הסייבר נועד בעיקר לנזק העצמי ולאחריות בגין פגיעה בפרטיות. תביעה של לקוח שהמערכת שלו נפגעה בגלל כשל במוצר או בשירות שייכת בדרך כלל לאחריות המקצועית הטכנולוגית. חברות רבות רוכשות את שני הכיסויים בפוליסה משולבת, ואז צריך לבדוק איך מחולק גבול האחריות ביניהם.
הקוד נכתב בעזרת עוזר AI. האם זה משנה משהו מבחינת הביטוח?
ברוב הפוליסות הקיימות מקור הקוד לא משנה את הגדרת האירוע, והאחריות נשארת של החברה. מה שמשתנה הוא החיתום: יותר חתמים שואלים איך החברה בודקת קוד שנוצר בסיוע AI לפני מיזוג, ואם קיימת סריקת סודות שחלה גם עליו. כדאי שהמדיניות תהיה כתובה ונאכפת בצינור ה-CI.
מתי צריך לדווח לרשות להגנת הפרטיות על מפתח שדלף?
חובת הדיווח קמה כשמתברר שמדובר באירוע אבטחה חמור במאגר מידע, בהתאם לרמת האבטחה של המאגר. לפי עמדת הרשות, הדיווח הראשוני צריך להימסר בסמוך לגילוי ועל בסיס המידע הקיים, ואפשר להשלים פרטים בהמשך. ההחלטה אם האירוע חמור מצריכה ייעוץ משפטי, ורכיב ניהול האירוע בפוליסת הסייבר עשוי לממן אותו.
האם הדירקטורים יכולים להיתבע אישית בגלל כשל כזה?
זה אפשרי, בעיקר בחברות ציבוריות או בחברות עם משקיעים חיצוניים. הטענה הנפוצה היא כשל בפיקוח על ניהול סיכוני סייבר. פוליסת D&O עשויה להגיב לתביעות כאלה, בכפוף להחרגת הסייבר שבה ולמנגנון ההקצאה. תיעוד מראש של דיוני הדירקטוריון בסיכוני סייבר עשוי לסייע בהגנה.
מפתח API שנשמר בקוד הוא הרשאה שהחברה נתנה לכל מי שיקרא את הקוד, והפוליסות נבחנות לפי מה שהחברה עשתה מהרגע שהמפתח נכתב ועד הרגע שבוטל.
האמור לעיל הוא מידע כללי בלבד ואין בו משום ייעוץ ביטוחי, משפטי או מקצועי אחר. תנאי הכיסוי, ההחרגות והחובות נקבעים בנוסח הפוליסה הספציפי ובכפוף לדין החל. יש לבחון כל מקרה לגופו מול נוסח הפוליסה ומול יועץ מוסמך.







































































