תיקון פרצות אבטחה בעזרת AI בשיעורי הצלחה גבוהים

תַקצִיר

סמנו עד כמה מודלים מובילים מייצרים תיקוני פגיעות שהם גם מאובטחים וגם פונקציונליים, על פני ~150 דוגמאות קוד פגיעות אמיתיות ב-⁦JavaScript⁩, ⁦Java⁩ ו-⁦Python⁩. הרצנו כל דגם בפני עצמו ועם ⁦Snyk Intelligence⁩ (הארכיטקטורה הסוכנת ⁦Agent Fix⁩ החדשה). ממצאי הכותרת:

• מודלי ה-frontier (דגמי חזית) המוכנים לשימוש מתקבצים סביב 72%–75%. Gemini 3.1 Pro, Claude Sonnet 4.6 ו-Claude Opus 4.6 כולם משיגים תוצאות קרובות מאוד זה לזה. בכל הנוגע לתיקון מאובטח ופונקציונלי, לבחירת המודל כמעט ואין השפעה על התוצאות.

• Snyk Intelligence מקפיץ את אותם מודלים מעבר לאותו טווח. Opus 4.6 עולה מ-74.6% ל-85.4%, עלייה של 10.8 נקודות (תיקון של 14.48% יותר דוגמאות). המשתנה הקריטי הוא הקשר האבטחה (Security Context), לא המודל.

• השיפור הוא המשמעותי ביותר במקומות שבהם המודל חלש במיוחד. Opus לבדו מתקן רק 64% מדוגמאות ה-Python; עם Snyk Intelligence, השיעור מגיע ל-88%.

מָבוֹא

קיימים כיום מדדים (benchmarks) לסוכני קידוד עבור יצירת בדיקות יחידה, תיקון באגים בסגנון SWE-bench והשלמת קוד. עם זאת, אין מדד ציבורי נפוץ למשימה שבאמת חשובה לצוותי אבטחה: לקחת קוד עם פגיעות ידועה ולהפיק תיקון שמסיר את הפגיעות ומבטיח שהקוד ימשיך לעבוד. מדובר בשני קריטריונים בלתי תלויים, וכשל באחד מהם הוא מצב נפוץ ויקר. תיקון שמסיר הזרקת SQL אך משנה את תוצאות השאילתה אינו מועיל לאיש. תיקון שנראה נקי אך משאיר את ההזרקה על כנה הוא גרוע אף יותר, שכן הוא נראה כמו פתרון תקין.

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

הגרסה הקצרה: הדגמים היוצאים מהקופסה הגיעו לרמה של 72-75%, ו-⁦Snyk Intelligence⁩ הוא מה שמעביר אותם מעבר לזה. שאר הפוסט הזה הוא הנתונים והשיטה מאחוריו.

איך אנחנו מודדים: מדד ⁦Golden Test⁩

רוב מדדי הקוד בודקים אם הקוד רץ או אם הוא פותר דוח באגים. אף אחד מהם אינו מספיק לתיקון פגיעויות, שכן הוא חייב לעמוד ברף אבטחה וברף פונקציונלי בו-זמנית. מערך ההערכה שלנו, ה-Golden Tests, תוכנן למדוד את שניהם. העיצוב שואב השראה מ-SWE-bench, אך מותאם לצרכי אבטחה.

המתקנים

הסט הוא ~150 דוגמאות קוד פגיעות אמיתיות: 50 ב-⁦Python⁩, 54 ב-⁦JavaScript⁩, ו-39 ב-⁦Java⁩. כל דוגמה היא פיסת קוד עם פגיעות אחת בדיוק, שנמצאה על ידי ⁦Snyk Code⁩ ומאושרת על ידי מומחה אבטחת אנוש, ונבחרה כך שהיא ניתנת לתיקון מהקוד שלפני המודל מבלי להחמיץ הקשר חיצוני.

הניקוד

כל דוגמה מסופקת עם שתי בדיקות יחידה מאומתות אנושית:

• בדיקה שנכשלת בגלל שהפגיעות קיימת, ו

• בדיקה שעוברת כאשר הפונקציונליות המקורית של הקוד נשמרת (לדוגמה, עוזר שאמור להדהד 'hello world' עדיין מחזיר 'hello world' לאחר התיקון).

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

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

מה הערכנו

שש תצורות: המודל הפנימי הקודם של Snyk מבוסס StarCoder, שלושה מודלי חזית (Gemini 3.1 Pro, Claude Sonnet 4.6, Claude Opus 4.6), וכן Sonnet 4.6 ו-Opus 4.6 הפועלים עם Snyk Intelligence תחת ארכיטקטורת ה-Agent Fix הסוכנת החדשה. "Snyk Intelligence" מתייחס כאן להנחיה דינמית מסוג few-shot: בזמן התיקון, אנו מזריקים את התיקונים הרלוונטיים ביותר שנכתבו על ידי מומחים עבור אותה חולשה ספציפית, מתוך מאגר של למעלה מ-35,000 פגיעויות של Snyk. (זה מתבסס על עבודה מוקדמת שבה רעיון זה שיפר את הביצועים של LLMs מוכנים לשימוש).

איך מדד ⁦Snyk Agent Fix⁩ בהשוואה למדדים קודמים?

סט ה-Golden Test הוא חלק מרצף עבודות שהעלו בהתמדה את הרף להערכת AI בקוד. SWE-bench קבע את הדפוס של ניקוד מודלים מול בדיקות נסתרות ואמיתיות, במקום להסתמך על סבירות מדווחת עצמית. בתחום האבטחה, Vul4J הציג פגיעויות שניתנות לשחזור בשילוב עם בדיקות הוכחת פגיעות וחבילת רגרסיה פונקציונלית, התקדים הקרוב ביותר לעיצוב ה-FAIL-to-PASS ו-PASS-to-PASS שלנו. עבודות עדכניות יותר, כמו BaxBench ו-SEC-bench, מחזקות את ההנחה שבנינו לפיה קוד תקין פונקציונלית הוא לעיתים קרובות עדיין לא מאובטח, ולכן מדד תיקון אמין חייב לבחון את שני המאפיינים בו-זמנית. מה שמייחד את ה-Golden Test הוא החלת שני המבחנים יחד, על דוגמאות אמיתיות מאומתות על ידי בני אדם, כשהבדיקות אינן נגישות למודל, וזאת בשלוש שפות תכנות.

תוצאות

מדד הכותרת הוא החלק של ⁦Golden Tests⁩ שבו התיקון היה מאובטח ופונקציונלי.

המודלים המוכנים לשימוש נמצאים בטווח של שלוש נקודות. הוספת Snyk Intelligence פותחת פער של 8 עד 11 נקודות באותו המודל: Opus 4.6 עולה מ-74.6% ל-85.4%.

פירוק ההשוואה של Opus לפי שפה מראה שהשיפור אינו תוצאה של ממוצע מקרי. הוא בא לידי ביטוי בכל שפה שבדקנו, והוא המשמעותי ביותר במקומות שבהם המודל הבסיסי היה החלש ביותר.

Python הוא המקרה המובהק ביותר: Opus לבדו מתקן 64.0% מהדוגמאות, ועם Snyk Intelligence, זה קופץ ל-88.0%. ב-JavaScript ו-Java, שבהן Opus מתחיל מנקודת מוצא חזקה, כל אחת רשמה עלייה של חמש עד שש נקודות.

מה המשמעות של המספרים

גודל המודל בלבד הגיע לתקרת ביצועים בתיקון מאובטח ופונקציונלי

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

ההקשר הביטחוני, לא מודל גדול יותר, הוא המנוף

אותו Opus 4.6 מרוויח 10.8 נקודות (14.48% יותר דוגמאות) אך ורק בזכות דוגמאות האבטחה שהוזרקו בזמן התיקון. מכיוון שהגישה אינה תלויה במודל ספציפי, כל שיפור במודלי החזית הבסיסיים מצטבר עם ההקשר הזה במקום להתחרות בו. הנכס בעל הערך המתמשך הוא 35,000+ תיקוני מומחים; המודל הוא רכיב שניתן להחליף ככל שהתחום מתפתח, וזו הסיבה ש-Agent Fix בגרסת ה-Production משלב כעת את Snyk Intelligence עם Claude Opus 4.7.

ההרמה היא הגדולה ביותר במקום בו הדגם החלש ביותר

אופוס לבדה תיקנה רק 64% מהדגימות ⁦Python⁩, השפה הגרועה ביותר שלה. עם ⁦Snyk Intelligence⁩ הוא הגיע ל-88%, הרווח הטוב ביותר שלו מבין השלושה. ההקשר הביטחוני לא רק מעלה את הממוצע; זה מרים את הרצפה.

התוצאה מחזיקה עד מראה שני

המספר ⁦Opus-plus-Snyk⁩ הוא ממוצע על פני ריצות (84.6% ו-86.0% בשתי הריצות שצברנו), כך שהכותרת 85.4% משקפת ביצועים עקביים בריצות. השונות של הפעלה לריצה על סט זה היא בערך נקודה, שכדאי לזכור כאשר משווים תצורות שנמצאות בטווח של נקודה או שתיים אחת מהשנייה.

למעלה הבא: ⁦Snyk VulnBench⁩ וזיהוי פגיעות עם סוכני קידוד

תיקון פגיעות מניח שמצאת אותה. ביוני 2026, פרסמנו את המאמר ⁦Snyk VulnBench⁩ ⁦JS⁩ 1.0 , שמטרתו הייתה להשוות את ⁦Snyk Code⁩ כמנוע ⁦SAST⁩ דטרמיניסטי ומהיר לעומת ⁦LLMs⁩ המופעל על ידי סוכני קידוד (רתמת ⁦Claude Code⁩) כדי לזהות נקודות תורפה בקוד מלכתחילה, לפני שהם זקוקים לתיקון.

הממצאים שלנו מ-Snyk VulnBench גילו שאפילו מודלי שפה גדולים ומתקדמים כמו Claude Opus 4.7 ברמת ההיגיון המקסימלית שלהם (המכונה max), וגם כאשר הם מופעלים על ידי רתמת סוכן קידוד מתקדמת (Claude Code עצמה), התמודדו עם אתגרים הנוגעים ליכולת חזרה (repeatability) ודטרמיניזם. כמה ממצאי כותרת:

• במקרה אחד, המודל וסוכן הקידוד דיווחו על כ-50% מהממצאים שלא חזרו על עצמם בארבע מתוך חמש ההרצות הבאות, מה שיצר צבר של תוצאות חיוביות שגויות (false positives) ועייפות פגיעויות עבור מפתחי סוכנים ומהנדסי אבטחת AI.

• במקרים אחרים, 13% מסוכני הקידוד דיווחו על פגיעויות לא תואמות שהופיעו בכל 5 ההרצות, מה שיצר מצב מבלבל של עומס קוגניטיבי מבחינת צבר בעיות האבטחה שעלולות להתברר כחיוביות שגויות.

אנו מזמינים אותך לחקור ולחקור באמצעות מערך הנתונים ⁦Snyk VulnBench⁩ אשר הפך מקוון ופומבי עבורך לעיון ב-⁦https://vulnbench.com/⁩

מגבלות

ארבע מגבלות שקורא צריך לשקול לפני שהוא נשען על המספרים האלה:

• גודל הסט: ~150 דוגמאות (50 Python, 54 JavaScript, 39 Java) מספיק כדי להציף דפוסים ברורים, אך לא מספיק כדי לטעון למובהקות סטטיסטית בפערים קטנים. קו הבסיס של StarCoder נבדק על דוגמאות קטנות בכ-20% (רק כללים הנתמכים על ידי Agent-Fix, שבהם היו נתוני אימון); בכל הכללים, הוא מקבל 54.9%. זהו המודל הפנימי והמכוונן של Snyk, והוא נכלל לעיון בלבד ולא כקו בסיס לחזית הטכנולוגיה.

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

• שלוש שפות: מדדנו את ⁦JavaScript⁩, ⁦Java⁩ ו-⁦Python⁩. הארכיטקטורה החדשה תומכת בכל השפות ש⁦Snyk Code⁩ תומכות בהן, אך אלו הן השלוש עם ⁦Golden Test⁩ כיסוי כיום.

• ריצות מוגבלות עבור שונות: צברנו שתי ריצות עבור תצורות ⁦Snyk-boosted⁩ ולא הרצנו מספיק חזרות כדי לשים פסי שגיאה רשמיים בכל תא. התייחס להבדלים של תת שתי נקודות כמקורבים.

אנו נותנים שמות אלה כדי לעזור לכייל מי שטוען להישען עליהם, לא כדי לגדר את הממצאים. הפער של 10 נקודות פלוס מ-⁦Snyk Intelligence⁩ נמצא הרבה מחוץ לרעש הריצה לרוץ; הסדר לפי שפה של פערים קטנים לא.

מה הלאה

• הרחבת כיסוי השפות: הרחבת ערכות ה-Golden Test מעבר ל-JavaScript, Java ו-Python כך שהמדד יתאים לתמיכה המלאה של הארכיטקטורה בשפות תכנות.

• כימת השונות: הרץ כל תצורה מספיק פעמים כדי לפרסם פסי שגיאה מתאימים במקום ממוצע של שתי ריצות.

• איתור, לא רק תיקון: רף זה מודד תיקון. מאמץ נלווה מודד עד כמה סוכנים מוצאים פגיעויות בהשוואה ל-⁦Snyk Code⁩, ואנו נדווח על כך בנפרד.

ה-Agent Fix הסוכן החדש זמין כעת, בשילוב Snyk Intelligence עם Claude Opus 4.7. רוצה לראות תיקון מאובטח ופונקציונלי בקוד שלך? התחל עם Snyk Code ו-Agent Fix, ולמד עוד על ההנדסה שמאחורי המספרים הללו.

האם ניתן לבטוח בקוד שנוצר על ידי AI? בניתי סורק כדי לגלות

נספח: מתודולוגיה וצבירה

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

צבירה: התעריפים המדווחים הם חלקם של הדגימות הקבועות.

• נתון המודל הקודם (⁦StarCoder⁩) של 72.4% הוא הממוצע של שיעורי השפה שלו, ומשקף את הכללים ⁦Agent-Fix-supported⁩ בלבד; בכל הכללים, הוא יורד ל-54.9%.