רפורמת הפגיעויות כאן: כיצד מפתחות אפליקציות מגדירות מחדש אבטחה בעידן ה-AI

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

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

התנגשות חזיתית: כשקוד מהיר פוגש חוב ישן

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

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

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

קידוד וייב: האשליה של מהירות ללא הבנה

קפיצת המדרגה הטכנולוגית העבירה אותנו מהשלמה אוטומטית של שורות קוד בודדות למצב של "קידוד וייב" (Vibe Coding). זוהי תצורת עבודה שבה מפתח הוגה רעיון, כותב הנחיה (Prompt) למנוע ה-AI, ופשוט מקבל את הקוד שנוצר כפי שהוא, לעיתים קרובות ללא קריאה ביקורתית או הבנה מעמיקה של השפה שבה נכתב.

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

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

מעבר ל-CVSS: למה המודל הישן מת

מעבר ל-CVSS: למה המודל הישן מת

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

ההנחה הזו פשוט מתה.

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

הפתרון: סדר ארגוני לפני מהירות מלאכותית

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

דניאל מיסלר, המנהל את חברת האבטחה Unsupervised Learning, הציג זאת בבוטות: אם שיטות ההנדסה שלכם הן בלאגן מוחלט (או כפי שכינה זאת "כריך מרק"), ה-AI לא יתקן את זה. אתם פשוט תייצרו את הבלאגן הרבה יותר מהר.

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

התובנה שפותחת את הראש: תוכנה כמערכת סוציו-טכנית

יש נקודה אחת שחייבים להתעכב עליה. קלי שורטרידג' מחברת Fastly העלתה תובנה קריטית: תוכנה לא מתקיימת בואקום. היא מערכת סוציו-טכנית.

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

שלושה תרחישים מהשטח: איך זה נראה בפועל

שלושה תרחישים מהשטח: איך זה נראה בפועל

כדי להבין את ההשלכות המעשיות, נבחן שלושה מקרי בוחן שכיחים:

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

2. ספרינטים מהירים בסטארטאפ ממומן\
סטארטאפ שגייס הון נדרש להציג פיצ'רים חדשים למשקיעים בכל שבועיים. המפתחים משתמשים ב"קידוד וייב" כדי לעמוד בקצב. התוצאה: מוצר שעובד נהדר בדמו, אבל מכיל חוב אבטחתי של ספריות צד-שלישי פגיעות. כשהמוצר מגיע לשלב ה-Due Diligence הטכנולוגי, העסקה נעצרת בגלל דוח סריקת קוד אדום לחלוטין.

3. פרויקטים ממשלתיים ורפואיים\
כאשר משרד ממשלתי או ארגון בריאות דורש פיתוח אפליקציות שעומדות בתקני פרטיות מחמירים, אין מקום לטעויות. שימוש ב-AI ללא סביבת פיתוח שמנטרת זליגת מידע רגיש בזמן הכתיבה (Shift Left אמיתי), עלול להוביל להפרות רגולטוריות חמורות שעולות במיליוני שקלים ובאובדן אמון הציבור.

מתי הגישה הזו קורסת: הצד השני של מטבע ה-AI

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

כאשר ארכיטקטורת הבסיס של המערכת שבורה מיסודה (למשל, קוד ספגטי מונוליתי ללא הפרדת הרשאות ברורה), כלי ה-AI יציפו את המפתח באלפי התראות שווא (False Positives) על כל שורת קוד שתיכתב. במצב כזה, ה-IDE הופך לרועש כל כך, עד שהמפתחים מפתחים "עייפות התראות" ופשוט מכבים את תוסף האבטחה.

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

משמעויות פרקטיות: מה עושים מחר בבוקר

משמעויות פרקטיות: מה עושים מחר בבוקר

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

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

נקודות מפתח לסיכום

• חוב אבטחתי בשיא: 82% מהארגונים סוחבים כיום חוב אבטחתי, והקצב שבו נוצרות פגיעויות עוקף את היכולת האנושית לתקן אותן ידנית.
• סוף עידן ה-CVSS: תעדוף פגיעויות לפי ציונים אינו יעיל יותר; יש לטפל בסיכון כבר ברמת ה-IDE, לפני שהקוד מגיע לייצור.
• סכנת הקידוד העיוור: "קידוד וייב" מייצר תפוקה מהירה אך שוחק את ההבנה האנושית של המערכת, מה שעלול להיות קריטי בזמן משבר.
• סדר לפני מהירות: ארגונים חייבים לבסס תהליכי הנדסה חזקים ותיעוד מדויק לפני שהם משחררים את רסן ה-GenAI לצוותי הפיתוח.

הצעד הבא שלכם

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