כלי AI כבר מסוגלים למצוא חולשות בקצב גבוה, אבל מספר הממצאים לבדו אינו מדד להצלחה. מחקר חדש של Microsoft FORGE Lab, שפורסם ב־7 באוקטובר 2026, מצביע על צוואר בקבוק אחר: היכולת לשחזר ממצא, לסנן כפילויות, להעריך השפעה ולמסור תיקון בטוח בזמן.
במאמר הרשמי, Microsoft מציגה שלושה לקחים ממחקר חולשות בעזרת AI. לפי החברה, בין מאי לספטמבר סייע FORGE בגילוי חולשות Windows שקיבלו 140 מזהי CVE, ובהן 52 שטופלו במהדורת האבטחה של ספטמבר. הצוות גם הגיש 155 דיווחים שעברו אימות פנימי ב־23 פרויקטי קוד פתוח.
לקח ראשון: גילוי בקנה מידה גדול אינו מספיק
סוכן יכול להפיק מאות מועמדים לחולשה, אך כל ממצא חדש מוסיף עומס לצוותי הטריאז', למפתחים ולמנהלי הפרויקט. אם קצב הדיווחים גבוה מקצב האימות והתיקון, מתקבל תור ארוך יותר — לא מערכת בטוחה יותר.
לכן יחידת המדידה הנכונה אינה “כמה התראות נוצרו”, אלא כמה ממצאים הפכו לבעיה ניתנת לשחזור, עברו הערכת סיכון והגיעו לתיקון שנבדק. Microsoft מתארת שימוש בכלי ניתוח קוד, מחוללי Proof of Concept וסביבות בדיקה מותאמות לפרויקט. באחד התהליכים, שילוב ניתוח דטרמיניסטי סייע להפחית כ־45% מהממצאים הכפולים בין סריקות.
לקח שני: לא מודדים רק טוקנים
קל למדוד כמה טוקנים או זמן מחשוב צרך הסוכן, אך עלות נמוכה אינה בהכרח יעילות. דוח קצר וחסר הקשר עשוי לחסוך בעלות המודל ולהעביר שעות עבודה לחוקר אנושי. מנגד, ניתוח ארוך שמוכיח מסלול הרצה ומייצר קלט משחזר עשוי להקטין את העלות הכוללת.
הגישה המעשית היא לזהות מה חסר כדי לקבל החלטה: קובץ Build תקין, מסלול קריאה לפונקציה, תנאי מוקדם, קלט שגורם לקריסה או הסבר סיבתי. את הבדיקות השגרתיות אפשר להפנות לכלים זולים ודטרמיניסטיים, ואת השאלות הקשות יותר למודל חזק. זו אינה הבטחה לחיסכון; צריך למדוד אם כל שלב באמת מצמצם אי־ודאות.
לקח שלישי: אימות ותיקון הם חלק מהלולאה
ממצא אינו מסתיים כאשר הסוכן מסמן שורת קוד. עליו לעבור שחזור, סקירה אנושית, פיתוח תיקון ובדיקת רגרסיה. גם כישלון בשחזור הוא מידע שימושי אם מתעדים את הסיבה: נתיב לא נגיש, קונפיגורציה שגויה, כפילות או הנחה שלא התקיימה.
לפי Microsoft, בכל מקרה מוצלח מתוך קבוצה של 182 קריסות מאומתות בליבת Linux, יצירת PoC אוטומטית עלתה בממוצע 3.61 דולר ונמשכה 21.5 דקות. הנתונים אינם כוללים את כל שלבי הסינון והעבודה האנושית, ולכן אין להסיק מהם שכל חולשה ניתנת לאימות בעלות הזאת. הם כן מדגימים שאוטומציה יכולה להיות מעשית כאשר סביבת הבדיקה בנויה נכון.
מה המשמעות לצוותי אבטחה ופיתוח?
- הגדירו מדד סיום: ממצא מאומת, בעל השפעה ברורה, תיקון ובדיקת רגרסיה.
- הפרידו בין מועמד לחולשה לבין חולשה מאושרת: אל תעבירו התרעת AI ישירות לייצור או לדיווח ציבורי.
- שמרו ראיות: גרסת קוד, קונפיגורציה, קלט משחזר, פלט קריסה והנחות הבדיקה.
- סננו כפילויות מוקדם: אותו באג יכול להופיע בכמה נתיבי ניתוח ולבזבז זמן יקר.
- שמרו אדם בתהליך: הערכת השפעה, תאימות התיקון ותזמון החשיפה דורשים שיקול דעת.
העיקרון דומה למה שראינו בהרחבת תוכנית הסייבר של Anthropic: גישה למודל מתקדם מועילה רק בתוך מסגרת של הרשאה, אימות ותיעוד. וכאשר קיימת חולשה מנוצלת בפועל, התהליך עדיין צריך להגיע לפעולה תפעולית — מיפוי נכסים, צמצום חשיפה ועדכון — כפי שפירטנו במקרה של Citrix NetScaler.
איפה אריאל מרום רואה את הסיכון הארגוני
לדברי אריאל מרום, העוסק בתשתיות IT, ענן וסייבר, האתגר בארגון אינו רק להכניס כלי AI חדש אלא לקבוע מי אחראי על כל מעבר בתהליך: מי מאשר יעד סריקה, מי משחזר, מי מתעדף, מי מאשר תיקון ומי בודק שהשינוי לא פגע במערכת אחרת. בלי בעלות ברורה, מהירות הגילוי עלולה להפוך לעוד שכבת רעש.
גם שירותי ניטור וניהול כמו MCS יכולים להפיק תועלת מכלי AI בסינון ובהעשרת אירועים, אך אין בכך תחליף לניהול חולשות, תיקון מערכות ובקרת שינויים. נכון יותר למדוד זמן מממצא מאומת ועד תיקון, שיעור כפילויות וזמן סקירה אנושי — ולא להסתפק במספר ההתראות שהמודל יצר.
השורה התחתונה
המחקר של Microsoft אינו טוען שסוכני AI מחליפים חוקרי אבטחה. הוא מראה שהיכולת לאתר מועמדים מתקדמת במהירות, בעוד הערך האמיתי נוצר במערכת שמסביב: סביבות Build אמינות, כלים לשחזור, תיעוד, תעדוף, אחריות הנדסית ותהליך עדכון. ארגון שרוצה לאמץ AI למחקר חולשות צריך לבנות קודם את המסלול מממצא לתיקון.
תמונת המחשה: נוצרה באמצעות AI עבור מערכת ITPortal.
