סקירת אבטחה ב-Claude Code: מדריך שלב אחר שלב ואוטומציה באמצעות GitHub Action ב-2026

מחבר החומר המקורי מתאר את ניסיונו: „הרצתי עכשיו security-review על פרויקט ה-vibe שלי, והצוות מצא כמה בעיות אמיתיות בתוך 4 דקות, וכבר תיקן אותן.” אותה עבודה הייתה אורכת בעבר יום של יועץ חיצוני.

חומרים נוספים להגדרת כלים נמצאים בתיעוד של Ailoot.

מהו /security-review ב-Claude Code?#

הפקודה פועלת בשני מצבים. מקומי: מריצים /security-review בטרמינל, ו-Claude קורא את המאגר ומפיק דוח. בצד השרת: מתקינים את אותו מנוע כ-GitHub Action, והוא מוסיף אוטומטית הערות inline בכל Pull Request.

בניגוד לסורקי SAST קלאסיים (Snyk Code, Semgrep, SonarQube), /security-review אינה פועלת לפי כללים קבועים. היא קוראת את הקוד כמו מהנדס שעובד בזמן אמת: עוקבת אחר זרימת הנתונים, מבינה באיזו מסגרת עבודה אתם משתמשים והיכן נמצאים גבולות האמון, ומזהה פגיעויות שכלל אינו מתאר.

אין פירוש הדבר ש-/security-review מחליפה בדיקת חדירה חיצונית או בדיקות בזמן אמת בסביבת staging. היא יכולה להפוך חלק מסקירת הקוד הראשונית לאוטומטי, אך המאמר אינו מודד שיעור מכיסוי הביקורת. בהמשך אסביר איך להריץ אותה כראוי ומה Claude תמצא בפרויקט שלכם.

איך מריצים /security-review ב-5 שלבים?#

שלב 1. עדכנו את Claude Code. הפקודה פועלת החל מהגרסה שפורסמה ב-20 בפברואר 2026.

claude update

אם התקנתם את Claude Code דרך npm, תוכלו לעשות זאת גם כך:

npm install -g @anthropic-ai/claude-code@latest

בדקו שהפקודה /security-review הופיעה:

claude /help | grep security

שלב 2. פתחו את הפרויקט והתחברו ל-Claude Code.

cd ~/projects/my-vibe-project
claude

שלב 3. הריצו את הפקודה. בתוך Claude Code, פשוט הזינו:

/security-review

Claude עוברת אוטומטית על פני 3 שלבי ניתוח:

1. מחקר הקשר המאגר (Repository Context Research) - קוראת את המבנה ומזהה את ה-stack, הנתיבים ושאילתות מסד הנתונים.
2. ניתוח השוואתי (Comparative Analysis) - משווה את המצב הנוכחי לדפוסי פגיעות טיפוסיים עבור ה-stack הזה.
3. הערכת פגיעויות (Vulnerability Assessment) - מפרטת כל חשד עם רמת ביטחון בסולם של 1-10. רק ממצאים עם רמת ביטחון ≥ 8 נכללים בדוח.

שלב 4. קראו את הדוח. הפלט מוצג בטבלת Markdown. לכל בעיה, Claude מספקת:

• קובץ ומספר שורה (לדוגמה, src/auth/login.ts:42)
• חומרה (HIGH / MEDIUM / LOW)
• קטגוריה (sql_injection, xss, auth_bypass, insecure_storage)
• תיאור - מה לא תקין
• תרחיש ניצול - כיצד תוקף עשוי לנצל זאת
• המלצה - כיצד לתקן זאת

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

„החילי את התיקונים בחומרת HIGH מהדוח, אחד בכל פעם, עם תיאור PR.”

Claude תפתח כל קובץ ותציע שינוי; אתם תאשרו אותו. בפרויקט אמיתי סגרתי 5 ממצאים ב-40 דקות, במקום 3 השעות שתכננתי.

אילו פגיעויות /security-review מזהה?#

הרשימה המלאה של מה שנכלל בניתוח כברירת מחדל מתוארת בתיעוד הרשמי של Anthropic:

בנוסף, הפקודה מכסה קטגוריות שסורקים אוטומטיים כמעט שאינם מכסים:

• הזרקת פקודות - הרצת קלט משתמש ב-shell (child_process.exec(userInput))
• טיפוס נתיבים - טעינת קובץ באמצעות ../../etc/passwd
• XXE - XML עם ישויות חיצוניות
• הזרקת תבניות - SSTI ב-Jinja/Handlebars/EJS
• הזרקת NoSQL - אופרטורים $ne, $gt בשאילתות MongoDB
• שימוש שגוי בקריפטוגרפיה - שימוש ב-MD5, במצב ECB או ב-IV קבוע

Claude מעניקה לכל ממצא דירוג חומרה. הסולם פשוט:

• HIGH - ניצול מרחוק ללא אימות, דליפת נתונים שמשפיעה על כל המשתמשים
• MEDIUM - ניצול בתנאים נוספים (נדרשת session / נדרש קלט מסוים)
• LOW - וקטור אפשרי, שאינו קריטי כרגע, אך כדאי לתקן

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

איך מגדירים GitHub Action לסקירה אוטומטית?#

שלב 1. השיגו מפתח API. עברו אל console.anthropic.com, צרו מפתח API והעתיקו אותו.

שלב 2. שמרו את המפתח ב-secrets של המאגר. ב-GitHub: Settings → Secrets and variables → Actions → New repository secret. תנו לו את השם CLAUDE_API_KEY; הערך הוא המפתח שלכם.

שלב 3. צרו קובץ workflow. שמרו אותו בשם .github/workflows/security.yml:

name: Security Review

permissions:
  pull-requests: write
  contents: read

on:
  pull_request:

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha || github.sha }}
          fetch-depth: 2

      - uses: anthropics/claude-code-security-review@main
        with:
          comment-pr: true
          claude-api-key: ${{ secrets.CLAUDE_API_KEY }}

שלב 4. מזגו את הענף אל main. ה-action יתחיל אוטומטית עם ה-PR הבא.

מה ה-action עושה:

• רץ בכל Pull Request פתוח / שעבר synchronize.
• לוקח את ה-diff בין ענף ה-PR ל-main.
• מפעיל את אותו מנוע כמו /security-review המקומית.
• מפרסם הערות inline ישירות בשורות קוד שבהן זוהה חשד.
• משכפל את הדוח המלא ב-Job Summary.

פרטים חשובים ב-permissions:

• pull-requests: write - כדי לפרסם הערות inline.
• contents: read - כדי לקרוא את הקוד. אין write. ה-action אינו משנה את הקוד בעצמו; הוא מדווח בלבד.

ההרשאות האלה מספיקות למאגר פרטי. במאגר ציבורי אפשר להוסיף גם actions: read אם משתמשים ב-workflows לשימוש חוזר.

איך מסננים התרעות שווא ומשנים את רמת הרגישות?#

טבלת הקלטים המלאה של GitHub Action (מקור: README של המאגר):

דוגמה להגדרת סינון התרעות שווא. צרו את הקובץ .claude/security/false-positives.md:

# כללי סינון התרעות שווא עבור הפרויקט שלנו

- כל שימוש ב-`dangerouslySetInnerHTML` בתוך `src/lib/email/layout.ts` בטוח -
  ה-HTML מורכב מתבניות מהימנות ועובר דרך `sanitize-html`
  בזמן כתיבה למסד הנתונים, ולא בזמן העיבוד.
- אל תדווחי על מפתחות API קשיחים של בדיקות בתוך `__tests__/fixtures/*.ts`.
  כל המפתחות מתחילים ב-`sk-test-fake-`.
- שרשור SQL ב-`src/lib/admin/migrations.ts` מקובל - הקובץ רץ
  רק כ-root, ונתוני הקלט מגיעים ממשתני סביבה.

חברו אותו ב-workflow:

- uses: anthropics/claude-code-security-review@main
  with:
    comment-pr: true
    claude-api-key: ${{ secrets.CLAUDE_API_KEY }}
    false-positive-filtering-instructions: .claude/security/false-positives.md

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

# בדיקות נוספות עבור הפרויקט שלנו

- כל נקודת קצה תחת `/api/admin/*` חייבת לבדוק את תפקיד מנהל המערכת
  באמצעות wrapper משותף. ללא wrapper כזה, החומרה היא HIGH.
- כל webhook של YooKassa / CloudPayments חייב לאמת את החתימה לפני
  ניתוח גוף הבקשה. ללא זאת, החומרה היא HIGH.
- אסימוני magic-link חייבים להיות חד-פעמיים (מסומנים ככאלה שנעשה בהם שימוש אחרי
  הבקשה התקינה הראשונה). אסימונים הניתנים לשימוש חוזר הם MEDIUM.

זה כבר אינו preset של Anthropic: אתם מעבירים את המומחיות שלכם בפרויקט לכללים ש-Claude מחילה בכל פעם. זו המהות של „מתודולוגיה מעל המודל”.

מידע נוסף על מתודולוגיית הקשר עבור Claude נמצא במדריכים „איך להגדיר CLAUDE.md” ו-„המוח השני ב-Claude Code”.

מה Claude לא מזהה ולמה: המגבלות כפי שהן?#

Anthropic מפרטת בבירור מה מושבת כברירת מחדל ומדוע (מקור: README של המאגר):

• מניעת שירות (Denial of Service) - יותר מדי רעש, כמעט תמיד השפעה נמוכה.
• חששות לגבי הגבלת קצב - מטופלים ברמת התשתית, לא בקוד.
• מיצוי זיכרון / CPU - כנ"ל.
• אימות קלט כללי ללא השפעה מוכחת - אימות של כל שדה יוצר מבול של התרעות שווא.
• הפניה פתוחה - לעיתים קרובות זו התנהגות מכוונת.

מה סקירת קוד לבדה אינה יכולה לאמת במלואו ללא ראיות מזמן ריצה או מפריסה:

• תצורת שרת הייצור. כותרות NGINX, מדיניות CORS, הגדרות TLS, יציאות האזנה. צריך לבדוק אותן ידנית בסביבת staging.
• תנאי מרוץ. למשל, חיוב כפול עקב בקשות החזר בו-זמניות. ניתוח סטטי יכול לסמן דפוסים חשודים, אך התנהגות בו-זמנית עדיין דורשת בדיקה.
• פגמים בלוגיקה העסקית של תשלומים. אם הסכום הכולל של ההזמנה מחושב בצד הלקוח ונשלח כפי שהוא לספק התשלומים, זו חומרת HIGH, אבל Claude לא תמיד מזהה את הדפוס בלי הקשר מפורש לגבי אופן פעולתם של התשלומים.
• IDOR ברמת מסד הנתונים. אם השאילתה SELECT * FROM orders WHERE id = $1 אינה בודקת WHERE user_id = $session.userId, Claude לרוב מזהה זאת. אבל אם הבדיקה ממומשת דרך middleware של ORM ו-Claude אינה יכולה לראות את זרימת הנתונים המלאה, ייתכן שהיא תפספס זאת.
• עמידות בפני הנדסה חברתית / phishing. אין לכך קשר לקוד.

השתמשו ב-/security-review כסקירה סטטית ראשונית. המשיכו בבדיקות דינמיות ב-staging, בדיקות תפקידים והרשאות, בדיקות SAST רלוונטיות וסקירת התצורה שפרוסה בפועל. לא הוכח כאן אחוז כיסוי שנמדד.

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

איך מחבר החומר המקורי ביצע סקירת אבטחה בפרויקט vibe#

מה עלה בבדיקה. תמונה טיפוסית של פרויקט vibe ממוצע בשלב „עובד בייצור, אבל טרם נבדק”: כמה חשדות בנוגע לזרימת האימות, ללוגיקה של עיבוד webhooks משילוב התשלומים, לטיפול בהעלאת קבצים, ועוד כמה הערות ספציפיות על טיפול ב-HTML בזמן העיבוד. איני מפרט את הפרטים בפומבי; חלק מההמלצות כבר יושמו, ואחרות עדיין נמצאות ב-PR. בפרויקט המדווח הזה, הסריקה הראשונית הייתה מועילה ומהירה; היא אינה מוכיחה אחוז כיסוי ביקורת או זמן השלמה כללי.

מה פסלתי כהתרעות שווא:

• ממצאים על DoS באמצעות ביטויים רגולריים באימות קלט - העומס בפועל אינו נופל על הביטויים הרגולריים האלה.
• ממצא אחד על מפתח API שמקודד ישירות - זה היה מפתח בדיקה עם התחילית המפורשת fake- ב-fixtures.

כמה זמן זה לקח. ההרצה עצמה ארכה 4 דקות. סקירת הדוח ארכה 25 דקות. החלת התיקונים ארכה כשעה, כולל בדיקות. בסך הכול: כשעה וחצי מ„התחלתי” ועד „הכול ב-main”. בדיקת חדירה חיצונית של אותו משטח נמשכת שבוע קלנדרי ועולה פי כמה עשרות.

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

איך משלבים את /security-review בשגרת pre-commit?#

ה-hook שהוצג קודם עם git_commit, הדגל --severity HIGH והדגל --fail-on-find אינו מתכון עבודה מתועד ואסור להשתמש בו כשער אבטחה. המאמר אינו מספק hook מקומי מאומת לחסימת commit. ה-GitHub Action הרשמי שמוצג למעלה מספק ממצאים אוטומטיים ב-PR; אל תסיקו שהוא חוסם commits או מיזוג רק משום שהוא מפרסם הערות ב-PR.

הסבר מלא על hooks נמצא במדריך „Hooks ב-Claude Code”.

חלופה באמצעות routines היא ליצור routine בשם pre-deploy-check שמריצה /security-review + npm run build + npm run test בפקודה אחת. חומרים נוספים נמצאים בתיעוד של Ailoot.

אם אתם משתמשים ב-שרתי MCP, תוכלו לשלב ממצאים מ-/security-review עם מערכת תקריות (Sentry, Linear, Notion), כך שכל ממצא בחומרת HIGH יהפוך אוטומטית לכרטיס משימה.

שאלות נפוצות על /security-review#

כמה עולה הרצה אחת? זה תלוי בגודל הפרויקט. ב-30K השורות שלי, הרצה אחת צורכת כ-$0.30-0.50 מיתרת ה-API. מאגר ארגוני גדול עם מיליון שורות עולה עד $5-8 להרצה. זה זול פי כמה עשרות מכל מנוי לסורק SaaS.

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

עם אילו stacks היא פועלת? עם כל stack ש-Claude יכולה לקרוא. לפי תצפיות המחבר, נבדקו: Next.js / Node.js, ‏Python (Django, FastAPI), ‏Go, ‏Rust, ‏PHP (Laravel), ‏Ruby on Rails. האיכות נמוכה יותר בשפות אקזוטיות מאוד (Erlang, Elixir, Clojure), אך היא תמצא משהו.

מה לעשות אם Claude מוצאת בכל פעם את אותה „פגיעות”, אף שזו אינה באמת פגיעות? הוסיפו אותה ל-false-positive-filtering-instructions יחד עם הסבר של „למה זה בטוח”. Claude תפסיק לדווח עליה בהרצות הבאות.

האם אפשר להריץ אותה רק על קבצים מסוימים? מקומית, כן: פשוט הריצו /security-review src/lib/auth/*.ts. ב-GitHub Action נבדק רק ה-diff הנוכחי של ה-PR, ולרוב לכך מתכוונים ב„קבצים מסוימים”.

מקורות#

חומרים נוספים נמצאים בתיעוד של Ailoot.