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

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

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

דעו מה לחפש

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

• הזרקה (Injection) — קלט של SQL, מעטפת (shell) או תבנית שנבנה על ידי שרשור מחרוזות במקום שימוש בשאילתות עם פרמטרים.
• Cross-site scripting (XSS) — קלט משתמש שמוצג בתוך HTML ללא escaping.
• אימות/הרשאה שבורים — נקודות קצה שבודקות מי אתם אך לא האם מותר לכם; חוסר בבדיקות בעלות על רשומות.
• טיפול לא מאובטח בנתונים — סודות בתוך הקוד, פרטי הזדהות ביומנים, מידע רגיש בהודעות שגיאה.
• תלויות פגיעות — חבילה שהסוכן הוסיף ובה CVEs ידועים.

אלה מתמפים בצורה הדוקה ל-OWASP Top 10, והם בדיוק הקטגוריות ש-Anthropic מציינת שסקירת האבטחה האוטומטית שלה מחפשת. שמירה על הרשימה הקצרה הזו בראש הופכת את הסקירה הידנית ליעילה בהרבה.

השתמשו בסוכן כדי לסקור את עצמו — בהקשר חדש

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

הנחיה (prompt) שעובדת טוב:

Review the diff on this branch for security vulnerabilities only.
For each finding, give me: the file and line, the vulnerability class
(e.g. SQL injection), a concrete exploit scenario, and the fix.
If you find nothing, say so — do not invent issues.

הסעיף "concrete exploit scenario" הוא החלק החשוב. הוא מכריח את המודל להוכיח שהבעיה אמיתית, במקום לנפק רשימה מעורפלת של הנחיות "שקלו לאמת קלט".

הושיטו יד לכלים המובנים

אם אתם משתמשים ב-Claude Code, יש פקודה ייעודית /security-review שמנתחת את השינויים שלכם לאיתור דפוסי פגיעות נפוצים, וכשאתם מאשרים, מחילה את התיקונים ישירות. היא זמינה בתוכניות בתשלום Pro ו-Max ובחשבונות API בתשלום לפי שימוש.

לכיסוי רציף, Anthropic גם משחררת GitHub Action בקוד פתוח שרץ על כל pull request ומפרסם הערות מוטמעות בדיוק על השורות שמדאיגות אותו. הכנסתו לתוך מאגר נראית בערך כך:

# .github/workflows/security.yml
name: Security Review
on: [pull_request]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-security-review@main
        with:
          claude-api-key: ${{ secrets.ANTHROPIC_API_KEY }}

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

אל תדלגו על הבדיקות הדטרמיניסטיות

סקירת AI היא תוספת חזקה, לא תחליף לכלים המשעממים שלעולם אינם מתעייפים:

• סריקת תלויות — npm audit, pip-audit או Dependabot תופסים חבילות פגיעות ידועות שמודל שפה לא יזהה לפי שם.
• סריקת סודות — כלים כמו gitleaks או ההגנה על push של GitHub עוצרים מפתח שדלף מלהגיע אי פעם להיסטוריה.
• ניתוח סטטי (SAST) — linters וכלים כמו Semgrep אוכפים כללים בעקביות על פני כל בסיס הקוד.

השתמשו ב-AI כדי להסיק לגבי לוגיקה והקשר — "האם משתמש מאומת יכול לקרוא כאן את הרשומות של משתמש אחר?" — והשתמשו בסורקים דטרמיניסטיים לדברים המכניים והניתנים להתאמת-דפוס. הם מכסים זה את הנקודות העיוורות של זה.

דוגמה קונקרטית

נניח שהסוכן שלכם מייצר את נקודת הקצה הזו:

@app.get("/invoices/{invoice_id}")
def get_invoice(invoice_id: str, user=Depends(current_user)):
    return db.query(f"SELECT * FROM invoices WHERE id = '{invoice_id}'")

מעבר אבטחה אמור לסמן שתי בעיות: השאילתה היא הזרקת SQL שמחכה לקרות (ה-invoice_id משורשר בתוך המחרוזת), ואין בדיקה שהחשבונית אכן שייכת ל-user — כל חשבון מחובר יכול לקרוא כל חשבונית על ידי ניחוש מזהים. התיקון הוא שאילתה עם פרמטרים בתוספת סינון לפי בעלות:

@app.get("/invoices/{invoice_id}")
def get_invoice(invoice_id: str, user=Depends(current_user)):
    return db.query(
        "SELECT * FROM invoices WHERE id = %s AND owner_id = %s",
        [invoice_id, user.id],
    )

ההזרקה היא סוג הדבר שסורק תופס. בדיקת ההרשאה החסרה היא סוג הדבר שדורש שמישהו — או סוקר AI עם ההנחיה הנכונה — יבין למה הקוד נועד. זו החלוקה שכדאי לזכור.

השורה התחתונה

התייחסו לכל diff שהסוכן שלכם מייצר כאל בלתי-אמין עד שנסקר — אותו סטנדרט שתחילו על ה-pull request הראשון של חבר צוות חדש. שלבו סקירת AI בהקשר חדש, בדיקת PR אוטומטית וסורקים דטרמיניסטיים, ותקבלו את רוב המהירות של פיתוח בסיוע AI בלי לרשת את ההרגלים הגרועים ביותר שלו.