זיהוי פגיעויות בקוד מבוסס בינה מלאכותית (AI SAST)

SAST מסורתי המבוסס על חוקים ותבניות AST מזהה היטב הזרקת SQL ו-XSS בתבניות קלאסיות, אך מפספס פגיעויות לוגיות, תנאי מרוץ ומסלולי הפצת זיהום מורכבים דרך מספר פונקציות. אנו מפתחים מערכות AI-SAST שמנתחות קוד ברמת גרף מאפייני הקוד ומשתמשות ב-LLM מכווננים להבנה הקשרית.

כתוצאה מכך, שיעור החיוביים הכוזבים יורד מ-80% ל-20–40%, וזמן המיון מצטמצם פי 3–4. אנו מבטיחים זיהוי של שגיאות לוגיות מורכבות שכלים מסורתיים מפספסים.

מדוע AI-SAST מדויק יותר מ-SAST מסורתי?

ניתוח זיהום דרך גרף

קלט משתמש → טרנספורמציות → פונקציות שעלולות להיות מסוכנות. SAST מסורתי מאבד את המעקב אחר מספר קריאות לפונקציות או בעת העברה דרך תורים. מודל ML על גרף מאפייני קוד (CPG) עוקב אחר זרימת נתונים across כל בסיס הקוד.

פגיעויות לוגיות

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

פגיעויות תלויות הקשר

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

הפחתת תוצאות חיוביות שגויות

SAST קלאסי על פרויקט גדול מפיק אלפי אזהרות, 70–90% מהן חיוביות שגויות. AI עם הבנת הקשר מפחית FPR ל-20–40%.

כיצד אנו בונים AI-SAST

Code Property Graph (CPG). Joern בונה CPG: AST + CFG + PDG בייצוג אחד. GNN על CPG הוא הגישה המתקדמת ביותר לזיהוי פגיעויות.

ניתוח מבוסס LLM. GPT-4 / Claude עם קוד בהקשר—להסבר פגיעויות שהתגלו ולהערכת ניצולות. המודל לא רק מוצא אלא גם מסביר: "הנה SQL injection מכיוון שהמשתנה user_id מפרמטר HTTP משורשר ללא סניטציה; הנה exploit הוכחת-היתכנות."

מודלים מכווננים (Fine-tuned). CodeBERT או StarCoder מכווננים על מערכי נתוני פגיעויות (SARD, CVEfixes, BigVul). סיווג: פגיע/בטוח + סוג פגיעות. הם עובדים טוב יותר עבור שפות ספציפיות.

from transformers import AutoTokenizer, AutoModelForSequenceClassification

# Fine-tuned CodeBERT for vulnerability detection
tokenizer = AutoTokenizer.from_pretrained("microsoft/codebert-base")
model = AutoModelForSequenceClassification.from_pretrained(
    "vuln-detector-codebert-finetuned",
    num_labels=len(VULN_TYPES)  # CWE categories
)

def analyze_function(code_snippet: str) -> VulnAnalysis:
    inputs = tokenizer(code_snippet, return_tensors="pt", max_length=512, truncation=True)
    outputs = model(**inputs)
    probs = torch.softmax(outputs.logits, dim=-1)
    return VulnAnalysis(
        vuln_type=VULN_TYPES[probs.argmax()],
        confidence=probs.max().item()
    )

כיצד פועל Code Property Graph?

CPG משלב AST, CFG ו-PDG למבנה יחיד המנותח על ידי GNN. הדבר מאפשר זיהוי של דפוסי פגיעוּת מורכבים הפרוסים על פני צמתי גרף רבים.

כיצד לשלב AI-SAST ב-CI/CD?

SAST פועל אוטומטית על כל PR. קריטי להגדיר ספים מתאימים:

זמן סריקה בפרויקט אמיתי: 100K שורות Python → 3–7 דקות עבור AI-SAST לעומת 30–60 שניות עבור שיטה מסורתית. פשרה: הרצת סריקה מהירה מבוססת חוקים על כל commit, AI-SAST על PR לפני מיזוג.

מקרה מעשי: סטארטאפ פינטק

מהניסיון שלנו: סטארטאפ פינטק, 180K שורות Python/Go, 4 מפתחים. Bandit + Semgrep מסורתיים: 340 אזהרות בשבוע, 80% חיוביים כוזבים. הצוות הפסיק לקרוא אותן.

לאחר פריסת AI-SAST (Semgrep AI + הסברים מבוססי LLM):

• 340 → 47 ממצאים מתועדפים עם הסברים מפורטים וציוני CVSS
• 3 פגיעויות קריטיות שהוחמצו על ידי SAST מסורתי: הזרקת SQL דרך ORM (מקרה עדין עם שם שדה דינמי), דה-סריאליזציה לא מאובטחת בנקודת קצה של API, מצב מרוץ בעיבוד תשלומים
• זמן מיון לכל ממצא ירד מ-15 ל-4 דקות — ההסבר כבר מוכן
• חוב אבטחה הופחת תוך 3 חודשים: כל ממצאי Critical ו-High תוקנו

הממצא המעניין ביותר: מצב מרוץ בחיוב — שתי בקשות סימולטניות עלולות להוביל לחיוב כפול בתזמון מסוים. SAST מסורתי לעולם לא יתפוס זאת.

מגבלות של AI-SAST

AI-SAST אינו מחליף בדיקות חדירה וסקירת קוד ידנית עבור רכיבים קריטיים. מודלים של שפה גדולה (LLM) עלולים לטעות במקרים מורכבים. השימוש הנכון: סינון אוטומטי ברמה ראשונה + תיעדוף עבור בני אדם, ולא החלפת המומחה.

מה כלול בעבודה?

• ביקורת של בסיס הקוד הנוכחי: קביעת שפות, frameworks ונפח. בחירת המודל האופטימלי (CPG, LLM, fine-tuning).
• התאמת המודל: fine-tuning על הנתונים שלך או כוונון חוקים ללוגיקה העסקית.
• אינטגרציה ל-CI/CD: הגדרת pipeline (GitHub Actions, GitLab CI, Jenkins) עם ספי חומרה.
• השקה פיילוט וכוונון ספים.
• תיעוד תהליכים והדרכת הצוות לפרשנות תוצאות.
• תמיכה טכנית במהלך הפריסה.

תהליך עבודה: 5 שלבים

1. ביקורת של בסיס הקוד הנוכחי
2. בחירת מודל והתאמה אישית
3. אינטגרציה של CI/CD
4. השקה פיילוט
5. השקה לפרודקשן + הדרכת צוות