GitHub Security — אבטחת קוד ותשתיות

7.1 שכבות האבטחה של GitHub — התמונה הגדולה

אבטחה ב-GitHub היא לא פיצ'ר אחד — זה מערכת של חמש שכבות שעובדות יחד. כל שכבה מגנה על משהו אחר, וביחד הן מכסות את רוב האיומים שפרויקט תוכנה נחשף אליהם:

הנקודה החשובה: רוב השכבות חינמיות. Dependabot alerts, security updates, version updates, dependency graph, ו-SBOM — כל אלה חינמיים לכל ריפוזיטורי, public ו-private. Code scanning, secret scanning ו-push protection חינמיים לריפוזיטורים ציבוריים. רק Security Overview ופיצ'רים מתקדמים דורשים תשלום.

למה זה חשוב עכשיו? מתקפות supply chain (מתקפות שמגיעות דרך תלויות של הפרויקט) הן אחד האיומים הנפוצים ביותר בעולם התוכנה. תחשבו על זה: הפרויקט שלכם משתמש ב-200 packages, כל אחד מהם עם dependencies משלו — ביחד אולי 1,000 רכיבים. אם אחד מהם פגיע, כל המערכת בסיכון. הכלים שנלמד בפרק הזה מגנים על כל השרשרת הזו.

Dependency Graph הוא הבסיס לכל שאר השכבות. GitHub מנתח אוטומטית את קבצי התלויות שלכם (package.json, requirements.txt, Gemfile.lock, pom.xml, ועוד) ובונה מפת תלויות מלאה — כולל תלויות עקיפות (transitive dependencies). אפשר לראות את המפה ב-Insights → Dependency graph.

SBOM (Software Bill of Materials) — מסמך מתועד שמפרט את כל הרכיבים בפרויקט, כולל שם, גרסה, רישיון, ומקור. חישבו על זה כ-"רשימת מרכיבים" על אריזת מזון — אלא שזה לתוכנה. אפשר לייצא SBOM מכל ריפוזיטורי: Insights → Dependency graph → Export SBOM. הפורמט הוא SPDX (סטנדרט בינלאומי). יותר ויותר ארגונים ורגולטורים דורשים SBOM כחלק מתהליכי compliance ו-supply chain transparency — וב-GitHub זה חינמי ואוטומטי לכל ריפוזיטורי.

בפרק הזה נעבור שכבה אחרי שכבה — מהבסיס (Dependabot) דרך CodeQL ו-secret scanning, ועד ל-Security Overview. בכל שכבה: מה זה, למה צריך, ואיך מגדירים.

7.2 Dependabot Alerts — כשהתלויות שלך פגיעות

Dependabot (שם שמחבר "depend" + "robot") הוא בוט מובנה של GitHub שמנטר את כל התלויות (dependencies) של הפרויקט שלכם ומתריע כשאחת מהן פגיעה. הוא לא דורש התקנה — הוא חלק מ-GitHub. הוא משתמש ב-Dependency Graph (מפת כל התלויות, כולל תלויות עקיפות) וב-GitHub Advisory Database (מסד נתונים של פגיעויות אבטחה ידועות עם 200,000+ פגיעויות מתועדות) כדי לזהות בעיות.

איך זה עובד — ארבעה שלבים:

1. Dependency Graph — GitHub מנתח את קבצי התלויות שלכם (package.json, package-lock.json, requirements.txt, Gemfile.lock, pom.xml ועוד) ובונה מפת תלויות מלאה — כולל תלויות עקיפות (transitive)
2. Advisory Database — GitHub בודק כל תלות מול GitHub Advisory Database, מסד נתונים של פגיעויות ידועות עם CVE IDs. המסד מתעדכן באופן שוטף ע"י GitHub, חוקרי אבטחה, ו-maintainers
3. Alert — אם נמצאת התאמה (תלות + פגיעות ידועה), GitHub יוצר alert עם כל פרטי הפגיעות ושולח notification
4. Security Update — אם קיימת גרסה מתוקנת, Dependabot יוצר PR אוטומטי עם השינוי המינימלי הנדרש. ה-PR כולל changelog, release notes, ו-compatibility score

כל alert מכיל מידע מפורט שעוזר לכם להבין את הסיכון ולהחליט מה לעשות:

• Severity — critical, high, medium, low — מבוסס על CVSS (Common Vulnerability Scoring System) score מ-0 עד 10
• CVE ID — מזהה ייחודי עולמי של הפגיעות (למשל CVE-2024-12345). אפשר לחפש את ה-CVE ב-NVD לפרטים נוספים
• Affected versions — אילו גרסאות של ה-dependency פגיעות (למשל: >= 4.0.0, < 4.17.21)
• Patched version — הגרסה הראשונה שמתקנת את הבעיה (אם קיימת). לפעמים אין תיקון עדיין — ואז צריך workaround או החלפה
• Remediation — הצעה מעשית: עדכנו ל-version X, או השתמשו ב-workaround Y

Dependabot Security Updates הם PRs אוטומטיים שמתקנים פגיעויות. GitHub מזהה פגיעות, מוצא גרסה מתוקנת, ופותח PR עם השינוי המינימלי הנדרש — רק שינוי הגרסה, בלי לגעת בקוד שלכם. ה-PR כולל release notes של הגרסה החדשה, changelog, ו-compatibility score — אחוז שמסמל כמה סביר שהעדכון לא ישבור כלום (מבוסס על נתונים מפרויקטים אחרים). אתם רק צריכים לבדוק שה-tests עוברים ולמזג. זה חינמי לכל הריפוזיטורים — public ו-private.

איך לקרוא Dependabot alert? כשנכנסים ל-alert, רואים כמה אלמנטים חשובים:

• CVSS Score — ציון מ-0 עד 10 שמדרג את חומרת הפגיעות. 9.0+ = critical, 7.0-8.9 = high, 4.0-6.9 = medium, 0.1-3.9 = low
• Attack vector — איך התוקף יכול לנצל: Network (מרחוק), Adjacent (רשת מקומית), Local (גישה פיזית), Physical
• Affected versions — טווח הגרסאות הפגיעות (למשל: >= 2.0.0, < 2.3.5)
• Patched version — הגרסה שמתקנת את הבעיה (למשל: 2.3.5)
• Dependency path — איך התלות הגיעה לפרויקט (ישירה? עקיפה דרך package אחר?)

Auto-triage rules (בתשלום עם Code Security) — חוקים שמסננים alerts אוטומטית. למשל: "כל alert על devDependency בלבד — סמן כ-low priority" או "כל alert ששפע ה-CVSS שלו תלוי ב-network access ולמערכת שלנו אין network exposure — dismiss אוטומטית". זה חוסך זמן בפרויקטים עם הרבה alerts.

Malware alerts (חדש): Dependabot גם מזהה packages שידועים כ-malware — לא רק פגיעים, אלא ממש זדוניים. תחשבו על typosquatting: package בשם lodahs במקום lodash שמכיל קוד זדוני. Dependabot מזהה packages כאלה ומתריע ב-severity critical. טיפול: הסירו מיד ובדקו אם הקוד הזדוני הורץ.

Dependabot נגד supply chain attacks: מתקפות supply chain (מתקפות שרשרת אספקה) הן אחד האיומים הגדולים ביותר על פרויקטי תוכנה כיום. התוקף לא פורץ את הקוד שלכם — הוא מזריק קוד זדוני דרך dependency שאתם סומכים עליו. הדוגמאות מהעולם האמיתי רבות: event-stream (2018), ua-parser-js (2021), colors.js (2022), xz utils (2024). Dependabot מגן מפני זה בכמה דרכים: הוא מתריע על packages שידועים כ-malware, הוא מתריע כשגרסה מכילה פגיעות ידועה, ועם cooldown (שנלמד בסעיף הבא) הוא מונע אימוץ מהיר מדי של גרסאות חדשות שעלולות להיות מפוקפקות.

7.3 Dependabot Version Updates — עדכון שוטף של תלויות

עכשיו שאנחנו מבינים איך Dependabot alerts עובדים ואיך security updates מתקנים פגיעויות ידועות, בואו נדבר על הצד השני של המטבע: שמירה שוטפת על תלויות מעודכנות, גם כשאין פגיעות ידועות.

יש הבדל חשוב בין שני סוגי העדכונים של Dependabot:

למה צריך Version Updates? כי עדכון קטן כל שבוע הרבה יותר בטוח מעדכון ענקי כל שנה. תחשבו על זה כך: אם dependency עולה מ-2.1.0 ל-2.1.1 (patch) — סביר שמשהו קטן השתנה ו-tests שלכם יעברו. אבל אם חיכיתם שנה ועכשיו צריכים לעלות מ-2.1.0 ל-3.5.0 — יש breaking changes, API שהשתנה, deprecations שצריך לטפל בהם. זה פרויקט של ימים, לא דקות.

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

כדי להפעיל Version Updates, צריך ליצור קובץ .github/dependabot.yml (שם קובץ מדויק — Dependabot לא יזהה שם אחר). זה קובץ YAML שמגדיר: אילו ecosystems לבדוק, באיזו תדירות, ואיך לארגן את ה-PRs. Dependabot קורא את הקובץ ופועל לפי ההגדרות — בלי שום התערבות שלכם.

הנה דוגמה בסיסית של dependabot.yml שמכסה את שלושת ה-ecosystems הנפוצים ביותר:

# .github/dependabot.yml
version: 2
updates:
  # npm dependencies
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
      time: "09:00"
      timezone: "Asia/Jerusalem"
    labels:
      - "dependencies"
      - "automerge"

  # Docker base images
  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "monthly"

  # GitHub Actions versions
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

מה יש כאן:

• version: 2 — גרסת הפורמט (תמיד 2)
• package-ecosystem — סוג ה-dependencies. Dependabot תומך ב-30+ ecosystems: npm, pip, bundler, docker, maven, gradle, cargo, composer, gomod, github-actions, terraform, nuget, pre-commit (חדש מ-2026) ועוד
• directory — איפה קבצי התלויות נמצאים (בדרך כלל /). ב-monorepo אפשר להגדיר directories שונים: /frontend, /backend, /infra
• schedule — מתי לבדוק: daily, weekly, monthly, quarterly, semiannually, yearly, או cron expression. weekly הוא הבחירה הנפוצה ביותר — מספיק תדיר בלי להציף ב-PRs
• labels — תוויות שמתווספות אוטומטית ל-PRs (שימושי לסינון ול-automerge)

שימו לב למוסכמה חשובה: הקובץ חייב להיות בדיוק ב-.github/dependabot.yml (לא .github/dependabot.yaml, לא dependabot.yml ב-root). אם הקובץ במיקום לא נכון — Dependabot פשוט יתעלם ממנו בלי שום הודעת שגיאה.

github-actions כ-ecosystem: שימו לב שהגדרנו גם github-actions כ-ecosystem. זה מעדכן את ה-versions של Actions שאתם משתמשים בהם ב-workflows — למשל עדכון מ-actions/checkout@v3 ל-actions/checkout@v4. זה חשוב במיוחד מבחינת אבטחה: Actions ישנים עלולים להריץ על Node.js versions שכבר לא נתמכים.

7.4 dependabot.yml לעומק — כל האפשרויות

dependabot.yml תומך בהרבה יותר מ-schedule בסיסי. הנה התכונות המתקדמות שכדאי להכיר:

Groups — קיבוץ PRs

בלי groups, Dependabot פותח PR נפרד לכל dependency שצריכה עדכון. בפרויקט עם 50 dependencies, אתם עלולים לקבל 20 PRs ביום שני בבוקר — זה מכריע. Groups פותרים את הבעיה: אתם מגדירים כללים שמקבצים כמה עדכונים ל-PR אחד. במקום 20 PRs — מקבלים 3-4.

אפשר לקבץ לפי:

• dependency-type — כל ה-development dependencies ביחד, כל ה-production dependencies ביחד
• patterns — כל ה-packages שמתחילים ב-@testing-library/ ביחד
• update-types — כל ה-minor updates ביחד, כל ה-patch updates ביחד

דוגמה:

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      # קיבוץ כל ה-dev dependencies ל-PR אחד
      development-dependencies:
        dependency-type: "development"
      # קיבוץ packages של testing
      testing:
        patterns:
          - "jest*"
          - "@testing-library/*"
          - "vitest"

Cooldown — עיכוב חכם

תכונה חדשה (מ-July 2025) שמונעת אימוץ מהיר מדי של גרסאות חדשות — הגנה מפני supply chain attacks:

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default: 3    # ברירת מחדל: 3 ימים
      semver-major-version: 14  # major: חכו 14 יום
      semver-minor-version: 7   # minor: חכו 7 ימים
      semver-patch-version: 3   # patch: חכו 3 ימים

למה cooldown חשוב? Supply chain attacks מנצלים את החלון בין פרסום package זדוני לבין גילויו. תוקף מפרסם גרסה חדשה של package פופולרי (או package עם שם דומה), ופרויקטים שמעדכנים מיד — מכניסים קוד זדוני. אם Dependabot מחכה 3 ימים לפני שפותח PR — יש סיכוי טוב שה-package הזדוני כבר יתגלה, ידווח, ויוסר מה-registry לפני שהגרסה מגיעה לפרויקט שלכם.

המלצת baseline: 3 ימים ל-patch (שינויים קטנים), 7 ימים ל-minor (תכונות חדשות), 14 ימים ל-major (שינויים שוברים). זה נותן מספיק זמן לקהילה לבדוק גרסאות חדשות בלי להאט אתכם יותר מדי.

Allow/Ignore — סינון תלויות

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    # רק security updates ל-lodash
    ignore:
      - dependency-name: "lodash"
        update-types: ["version-update:semver-major"]
    # private registry
    registries:
      - npm-private

עוד אפשרויות חשובות

• open-pull-requests-limit — מקסימום PRs פתוחים (ברירת מחדל: 5)
• reviewers — מי מקבל review request אוטומטי
• assignees — למי ה-PR מוקצה
• commit-message — prefix מותאם (למשל: chore(deps):)
• versioning-strategy — auto, increase, widen, lockfile-only
• exclude-paths — דלגו על תיקיות ספציפיות (glob patterns)
• pre-commit — ecosystem חדש (מ-March 2026) שמעדכן hooks ב-.pre-commit-config.yaml. Dependabot קורא את הקובץ, מזהה hooks עם גרסאות ישנות, ופותח PR שמעדכן את ה-rev field. תומך גם ב-tag וגם ב-SHA-based revisions
• multi-ecosystem-groups (חדש 2026) — אפשר לקבץ עדכונים מ-ecosystems שונים ל-PR אחד. למשל: עדכון npm + docker ביחד ב-PR אחד

דוגמה מציאותית: startup עם Node.js backend, React frontend, Docker deployment, Terraform infra, ו-GitHub Actions. ה-dependabot.yml שלהם מגדיר 5 ecosystems, כל אחד עם schedule מותאם — npm weekly, docker monthly, terraform monthly, github-actions weekly, pre-commit weekly. Groups מקבצים dev dependencies ביחד ו-production dependencies ביחד. Cooldown מונע אימוץ מהיר של versions חדשים. התוצאה: 5-8 PRs בשבוע במקום 30+, וכל אחד כולל tests שרצים אוטומטית.

7.5 Code Scanning עם CodeQL — ניתוח סטטי שמבין את הקוד

CodeQL הוא מנוע הניתוח הסמנטי (semantic analysis engine) של GitHub. בניגוד ל-linters רגילים שבודקים תחביר, CodeQL מתייחס לקוד שלכם כאל מסד נתונים ומריץ queries שמוצאים דפוסים מסוכנים — כמו SQL injection, Cross-Site Scripting (XSS), path traversal, ועוד.

איך זה עובד:

1. בניית מסד נתונים — CodeQL מנתח את כל הקוד שלכם ובונה representation פנימי: כל פונקציה, כל משתנה, כל זרימת נתונים ממקור (source) ליעד (sink). זה שונה מ-linter שבודק שורה אחרי שורה — CodeQL מבין את הזרימה המלאה
2. הרצת queries — CodeQL מריץ מאות שאילתות (queries) שמחפשים patterns מסוכנים. כל query מגדיר: מהו source (איפה input מגיע), מהו sink (למה הוא מגיע), ומה חסר באמצע (למשל: sanitization). דוגמה: "האם יש מקום שבו input מהמשתמש מגיע ל-SQL query בלי prepared statement?"
3. יצירת alerts — אם נמצאת התאמה, נוצר alert עם description, severity, CWE reference, ו-data flow visualization שמראה בדיוק את הנתיב מ-source ל-sink. זה חלק מהערך המוסף: אתם לא רק יודעים שיש בעיה, אתם רואים בדיוק איך ה-input זורם דרך הקוד

Data flow analysis הוא היתרון המרכזי של CodeQL על פני כלי linting רגילים כמו ESLint או Pylint. Linter בודק pattern מקומי ("האם יש eval() בקוד?"). CodeQL עוקב אחרי זרימת הנתונים בין פונקציות ומודולים — הוא יודע ש-input שמגיע מ-req.body.name בשורה 5 של routes/users.js עובר דרך processInput() בשורה 12 של utils/input.js, ומגיע ל-db.query() בשורה 23 של models/user.js. אם באף שלב בנתיב הזה לא היה sanitization — זו פגיעות. הנתיב הזה בדיוק הוא מה שה-data flow visualization מראה ב-alert.

שני מצבי הגדרה: GitHub מציע שתי דרכים להפעיל CodeQL. Default setup הוא one-click — GitHub מגדיר הכל אוטומטית. Advanced setup נותן שליטה מלאה דרך קובץ workflow YAML. לרוב, default setup מספיק. עברו ל-advanced רק אם צריכים שליטה ספציפית.

שפות נתמכות (9): C/C++, C#, Go, Java/Kotlin, JavaScript/TypeScript, Python, Ruby, Swift, ו-Actions workflows (GA מ-April 2025 — CodeQL סורק גם את ה-YAML של Workflows!).

סריקת Actions workflows היא תכונה חדשה וחשובה שנכנסה ל-GA באפריל 2025: CodeQL מוצא בעיות אבטחה ב-workflow YAML files. הבעיה הנפוצה ביותר: injection attacks. למשל, שימוש ב-${{ github.event.issue.title }} ישירות ב-run: step. תוקף יכול לפתוח issue עם כותרת שמכילה פקודות shell — והן ירוצו ב-runner שלכם עם הרשאות ה-workflow. CodeQL מזהה patterns כאלה ומתריע. אם אתם משתמשים ב-Actions (ולמדתם בפרק 1) — הפעילו את זה. ב-default setup, אם יש workflows בריפוזיטורי — הם נסרקים אוטומטית.

מה CodeQL מוצא בפועל? דוגמאות מייצגות:

• SQL Injection (CWE-89) — input מהמשתמש שמגיע ישירות ל-SQL query בלי prepared statement
• Cross-Site Scripting / XSS (CWE-79) — input שמוכנס ל-HTML response בלי escaping
• Path Traversal (CWE-22) — שם קובץ מהמשתמש שמאפשר גישה לקבצים מחוץ לתיקייה המותרת
• Hardcoded Credentials (CWE-798) — סיסמאות ומפתחות שכתובים ישירות בקוד
• Open Redirect (CWE-601) — URL redirect שמבוסס על input לא מאומת
• Insecure Deserialization (CWE-502) — deserialization של נתונים לא מהימנים

גרסה נוכחית: CodeQL Action v4 (שוחרר October 2025, רץ על Node.js 24). v3 ידורג (deprecated) ב-December 2026. אם יש לכם workflows ישנים עם @v3 — עדכנו ל-@v4. ההגירה פשוטה: שנו github/codeql-action/init@v3 ל-@v4 בכל שלושת ה-steps (init, autobuild, analyze). הפורמט זהה.

7.6 CodeQL Workflow — הגדרה מתקדמת ב-Actions

Default setup מספיק לרוב הפרויקטים — הוא מזהה את השפות אוטומטית ומריץ סריקה על push ו-PR. אבל יש מקרים שצריך שליטה מלאה. מתי צריך advanced setup במקום default? כשרוצים:

• שליטה בשפות הנסרקות (למשל: רק JavaScript, לא Python)
• שימוש ב-query suites מורחבים
• build steps מותאמים (לשפות compiled כמו Java או C++)
• schedule שונה מברירת המחדל
• סריקה גם של Actions workflows

הנה workflow מלא שמגדיר סריקת CodeQL ב-advanced setup. קחו את ה-template הזה ושנו את ה-language לפי הפרויקט שלכם:

# .github/workflows/codeql.yml
name: "CodeQL Analysis"

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]
  schedule:
    - cron: '30 8 * * 1'  # כל יום שני ב-08:30 UTC

jobs:
  analyze:
    name: Analyze (${{ matrix.language }})
    runs-on: ubuntu-latest
    permissions:
      security-events: write
      contents: read

    strategy:
      fail-fast: false
      matrix:
        language: [ 'javascript-typescript' ]
        # אפשרויות: c-cpp, csharp, go, java-kotlin,
        # javascript-typescript, python, ruby, swift, actions

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Initialize CodeQL
        uses: github/codeql-action/init@v4
        with:
          languages: ${{ matrix.language }}
          queries: security-and-quality
          # query suites:
          # default — רק security
          # security-extended — security + נוספות
          # security-and-quality — הכי מקיף

      - name: Autobuild
        uses: github/codeql-action/autobuild@v4
        # לשפות compiled: אם autobuild לא עובד,
        # החליפו ב-build steps ידניים

      - name: Perform CodeQL Analysis
        uses: github/codeql-action/analyze@v4
        with:
          category: "/language:${{ matrix.language }}"

ה-workflow מגדיר trigger על push, PR ו-schedule שבועי (חשוב לזיהוי פגיעויות חדשות בקוד קיים). שימו לב ל-permissions: CodeQL צריך security-events: write כדי ליצור alerts, ו-contents: read כדי לקרוא את הקוד.

שלושה query suites:

• default — רק שאילתות אבטחה (security). מהיר, ממוקד
• security-extended — security + שאילתות נוספות ברמת confidence נמוכה יותר
• security-and-quality — הכי מקיף: security + quality + best practices

Build modes (לשפות compiled):

• none — לשפות interpreted (JS, Python, Ruby) — לא צריך build. CodeQL מנתח את הקוד ישירות
• autobuild — CodeQL מנסה לבנות אוטומטית (עובד ברוב המקרים). מזהה Maven, Gradle, MSBuild, make
• manual — אתם כותבים build steps מותאמים. נדרש כשיש build system מיוחד או תלויות מורכבות

טיפ חשוב: אם אתם עובדים עם JavaScript/TypeScript בלבד — אל תשתמשו ב-autobuild. השתמשו ב-build-mode: none (ברירת מחדל לשפות interpreted). Autobuild מיועד לשפות compiled ויאט את הסריקה ללא צורך.

הגירה מ-v3 ל-v4:

# ישן (v3) — deprecated December 2026
- uses: github/codeql-action/init@v3
- uses: github/codeql-action/autobuild@v3
- uses: github/codeql-action/analyze@v3

# חדש (v4) — מומלץ
- uses: github/codeql-action/init@v4
- uses: github/codeql-action/autobuild@v4
- uses: github/codeql-action/analyze@v4

הפורמט זהה, אין שינויים ב-configuration. פשוט שנו @v3 ל-@v4 ב-3 המקומות.

7.7 טיפול בתוצאות Code Scanning — dismiss, fix, suppress

תוצאות code scanning מופיעות ב-Security → Code scanning alerts. כל alert מכיל:

• Description — מה הבעיה (למשל: "SQL injection from user-controlled input")
• Severity — critical, high, medium, low
• CWE — מזהה סוג החולשה (למשל CWE-89 = SQL injection)
• Affected code — השורה המדויקת בקוד
• Data flow — ויזואליזציה של הנתיב מ-source (איפה ה-input נכנס) ל-sink (איפה הוא מגיע למקום מסוכן)

מה ה-data flow מראה? זה אחד הכלים החזקים ביותר של CodeQL. ה-data flow visualization מציג את הנתיב המלא של הנתונים דרך הקוד — מ-source (איפה ה-input נכנס למערכת) דרך כל הפונקציות שהוא עובר, ועד ל-sink (המקום המסוכן). כל צעד בנתיב מקושר לשורה ספציפית בקוד. זה מאפשר להבין לא רק "יש בעיה" אלא "איך בדיוק ה-input מגיע למקום הבעייתי" — וזה מקצר דרמטית את זמן התיקון.

שלוש אפשרויות טיפול:

מתי לעשות Dismiss? לפעמים CodeQL מזהה pattern שנראה מסוכן אבל בהקשר שלכם הוא לא. דוגמאות:

• SQL query ב-test file שמריץ נגד database ב-memory — אין סיכון אמיתי
• Redirect URL שמגיע מרשימה קבועה (allowlist) ולא מ-user input
• Hardcoded string שנראה כמו secret אבל הוא placeholder שמוחלף בbuild time

כש-dismiss, תמיד בחרו סיבה (false positive / used in tests / won't fix) — זה יוצר documentation ועוזר לצוות להבין למה ה-alert נסגר.

Copilot Autofix — תכונה שמשנה את משחק האבטחה. כש-CodeQL מוצא פגיעות, Copilot מציע קוד מתוקן ישירות ב-PR. אתם רואים את ה-diff של התיקון המוצע, בודקים שהוא הגיוני, ומאשרים בלחיצה. זה חינמי ל-public repos ודורש רישיון Code Security ל-private.

דוגמה מעשית: נניח ש-CodeQL מצא SQL injection בשורה 42 של api/users.js. ה-data flow מראה שה-input מגיע מ-req.query.name (source) ומגיע ישירות ל-db.query(`SELECT * FROM users WHERE name = '${name}'`) (sink). Copilot Autofix יציע להחליף את ה-template literal ב-prepared statement: db.query('SELECT * FROM users WHERE name = $1', [name]). אתם בודקים שהלוגיקה נשמרת, מאשרים, ו-merge.

Security Campaigns (בתשלום, Code Security) — כלי ניהול ברמת ארגון שמאפשר ל-security team לקבץ alerts לפי נושא (למשל "כל ה-SQL injections") ולהקצות אותם לצוותים, לעקוב אחרי התקדמות, ולוודא שהכל מטופל. שימושי כשיש עשרות ריפוזיטורים ומאות alerts.

7.8 Secret Scanning — כשמפתחות API דולפים

Secret Scanning היא אחת מהתכונות הקריטיות ביותר של GitHub מבחינת אבטחה. היא סורקת את כל ה-commits, PRs, issues ו-discussions בריפוזיטורי שלכם ומחפשת secrets — API keys, tokens, סיסמאות, connection strings, private keys וכו'. GitHub מזהה 200+ סוגי secrets מ-100+ service providers, ורשימת ה-patterns מתעדכנת כל חודש.

למה secrets מגיעים לקוד מלכתחילה? טעות אנושית. מפתח עובד על feature, מכניס API key לקובץ configuration "רק לבדיקה", שוכח להסיר, ועושה git add . ואז git push. זה קורה בכל חברה, בכל גודל צוות. Secret scanning תופס את הטעויות האלה.

הזיהוי מבוסס על patterns ספציפיים — GitHub יודע בדיוק איך נראה AWS access key, GitHub PAT, Stripe secret key וכו'. יש שני סוגי זיהוי:

• Partner alerts — כש-GitHub מזהה secret של שותף (למשל AWS access key), הוא מודיע ישירות ל-provider. AWS, Stripe, Google Cloud ואחרים יכולים לבטל את המפתח אוטומטית. זה עובד על כל הריפוזיטורים — public ו-private.
• User alerts — GitHub מודיע לכם (בעלי הריפוזיטורי) על secret שנמצא. חינמי ל-public repos, דורש רישיון Secret Protection ל-private repos.

Copilot Secret Scanning — תכונה חדשה שמשתמשת ב-AI לזיהוי secrets לא מובנים (unstructured) כמו סיסמאות שנכתבו בקוד. למשל: password = "MyS3cret!" — pattern שאין לו מבנה קבוע ש-regex רגיל לא ימצא. ה-AI מבין context: הוא יודע שמשתנה בשם db_password שמכיל מחרוזת ארוכה הוא כנראה secret אמיתי.

Custom patterns (בתשלום עם Secret Protection) — אפשר להגדיר regex patterns מותאמים לזיהוי secrets ארגוניים. למשל: אם לארגון שלכם יש internal API keys בפורמט MYORG-KEY-[a-z0-9]{32}, אפשר להגדיר pattern שיזהה אותם. אפשר גם לכלול את ה-custom patterns ב-push protection.

אילו סוגי secrets מזוהים? הנה דוגמאות חלקיות מתוך 200+ הסוגים הנתמכים:

Secret scanning מתעדכן באופן שוטף — ב-March 2026 נוספו 9 סוגים חדשים כולל Airtable, Databricks, PostHog ו-Shopify. GitHub עובד עם 100+ service providers בתוכנית שותפים (Partner Program). כל provider מספק ל-GitHub את ה-patterns של ה-secrets שלו, ובתמורה מקבל notification אוטומטי כשsecret דולף — מה שמאפשר לו לבטל את המפתח מיידית ולהגן על הלקוח.

Secret scanning ב-Issues ו-Discussions: שימו לב — secret scanning לא סורק רק commits. הוא סורק גם issues, PRs descriptions, discussions, ו-wikis. אם מישהו הדביק API key בתגובה ל-issue — GitHub יזהה ויתריע. זו סיבה נוספת שהפעלת secret scanning חשובה גם לפרויקטים שלא מפרסמים קוד רגיש.

מה לעשות כש-secret נחשף? זהו תהליך חירום של 5 צעדים שצריך לבצע מהר ככל האפשר:

1. Revoke — בטלו את המפתח מיד אצל ה-provider (AWS console, Stripe dashboard, וכו')
2. Rotate — הנפיקו מפתח חדש
3. Update — עדכנו את המפתח החדש בכל מקום שצריך (secrets, environment variables, vault)
4. Audit — בדקו logs אצל ה-provider: האם מישהו השתמש במפתח שדלף?
5. Prevent — ודאו ש-push protection מופעל כדי למנוע חזרה. הוסיפו את הקובץ שהכיל את ה-secret ל-.gitignore

זמן תגובה: לכל סוג secret יש חלון סיכון שונה. AWS access key שדלף — תוקף יכול להריץ שרתים על החשבון שלכם תוך דקות. GitHub PAT — תוקף יכול לגשת לכל הריפוזיטורים שלכם. Stripe secret key — תוקף יכול לבצע חיובים. הכלל: revoke מיד, לא "אחר כך".

7.9 Push Protection — חסימה לפני שהנזק קורה

ההבדל בין secret scanning ל-push protection הוא העיתוי:

Push protection עובד כ-pre-receive hook בצד של GitHub — לא אצלכם על המחשב, אלא ב-server של GitHub. כש-git push שולח את ה-commits, GitHub סורק את ה-diff (השינויים) של כל commit לפני שמאפשר להם להיכנס לריפוזיטורי. אם מזוהה secret — ה-push כולו נחסם. נכון ל-2026, יש 39 detectors שמופעלים כברירת מחדל — GitHub tokens, AWS keys, Azure secrets, Stripe keys, ועוד.

מה זה אומר בפועל? זה אומר שגם אם טעיתם ועשיתם git add . שכלל קובץ .env עם API key, וגם עשיתם git commit — ה-push ייחסם. ה-secret לעולם לא יגיע ל-GitHub. זה ההבדל הקריטי בין push protection לבין secret scanning: push protection מונע את הנזק, secret scanning רק מגלה אותו אחרי שכבר קרה.

מה קורה כשPush נחסם?

אם ניסיתם לעשות push ו-GitHub זיהה secret, תקבלו הודעת שגיאה בטרמינל:

remote: error: GH009: Secret detected in push
remote: —— GitHub Personal Access Token ——
remote: locations:
remote:   - file: config/api.js:15
remote:
remote: To push, either remove the secret from your commits,
remote: or visit the URL to allow the secret.

שלוש אפשרויות bypass (אם אתם בטוחים שזה בסדר):

• False positive — זה לא באמת secret (למשל: מחרוזת שנראית כמו token אבל היא בעצם hash או test fixture)
• Used in tests — secret שמשמש רק בבדיקות ולא פעיל (למשל: mock API key שלא עובד ב-production)
• Will fix later — אתם יודעים על הבעיה ותטפלו. זה האופציה הכי מסוכנת — "אחר כך" הופך ל"לעולם לא". אם אתם בוחרים באופציה הזו, פתחו issue מיד עם label "security" כדי לא לשכוח

מה קורה אחרי bypass? ה-push עובר, אבל GitHub מתעד מי עשה bypass, מתי, ובאיזו סיבה. ב-Security tab אפשר לראות את כל ה-bypass events. בארגון עם delegated bypass, ה-reviewer מקבל notification ויכול לאשר או לדחות אחרי שה-push כבר נכנס — אם הוא דוחה, הצוות צריך לתקן מיד.

Push Protection for Users — תכונת הגנה שמופעלת כברירת מחדל לכל המשתמשים שדוחפים לריפוזיטורים ציבוריים. חינמי, לא צריך הגדרה. אפשר לבדוק ולנהל: Settings (של המשתמש) → Code security and analysis → Push protection for yourself. מומלץ מאוד להשאיר מופעל.

Delegated bypass (בתשלום עם Secret Protection) — בארגון, admin מגדיר מי יכול לאשר bypass requests. במקום שהמפתח יחליט לבד אם לעקוף את ההגנה, הוא שולח בקשת bypass ל-reviewer מורשה. ה-reviewer רואה את ה-secret שזוהה ומחליט אם לאשר. זה יוצר audit trail ומונע bypass חסר אחריות.

Push protection exemptions (חדש מ-March 2026) — אפשר להגדיר ב-repository settings אילו roles, teams או apps פטורים מ-push protection. שימושי ל-automation tools שדוחפים configuration files עם patterns שנראים כמו secrets אבל לא באמת secrets (למשל test fixtures, mock data). אבל — השתמשו בזהירות. כל exemption מחליש את ההגנה.

הפרקטיקה הנכונה עם secrets: כדי לא להיתקל בחסימות של push protection, תמיד:

• שמרו secrets ב-environment variables — לא בקוד
• השתמשו בקובץ .env.local שנמצא ב-.gitignore
• ב-GitHub Actions — השתמשו ב-Repository Secrets (Settings → Secrets and variables)
• ב-production — השתמשו ב-vault (HashiCorp Vault, AWS Secrets Manager, וכו')
• לעולם אל תעשו console.log(process.env.API_KEY) — גם logs יכולים לדלוף

7.10 GHAS, Security Advisories ו-Security Overview — מה עוד יש

Security Advisories — ניהול פגיעויות בפרטיות

Security Advisories מאפשרים לכם לדווח, לדון ולתקן פגיעויות אבטחה — בפרטיות, לפני שזה הופך לידע ציבורי. התהליך:

1. חוקר אבטחה מוצא פגיעות ומדווח דרך Private Vulnerability Reporting
2. בעלי הריפוזיטורי יוצרים Draft Advisory — מרחב עבודה פרטי לתיקון
3. אחרי התיקון, מפרסמים את ה-advisory — הוא מקבל CVE ID ונכנס ל-GitHub Advisory Database

כדי להפעיל: Settings → Code security and analysis → Private vulnerability reporting → Enable. אפשר גם ברמת ארגון — הפעלה על כל הריפוזיטורים בבת אחת.

למה זה חשוב? בלי ערוץ מאובטח לדיווח, חוקרי אבטחה שמוצאים פגיעות בפרויקט שלכם יכולים לפרסם אותה פומבית (responsible disclosure) לפני שתספיקו לתקן. עם Private Vulnerability Reporting, הם יכולים לדווח ישירות דרך GitHub, אתם מקבלים notification, ויש לכם זמן לתקן לפני פרסום. Draft Advisory מאפשר שיתוף פעולה פרטי על התיקון — אפשר להוסיף collaborators, ליצור temporary fork פרטי לעבודה על הfix, ולפרסם רק כשהכל מוכן.

GHAS — ההיסטוריה והמבנה החדש

עד אפריל 2025, כל פיצ'רי האבטחה המתקדמים נמכרו כחבילה אחת: GitHub Advanced Security (GHAS). מאז אפריל 2025, GHAS פוצל לשני מוצרים עצמאיים:

חדש: גם לקוחות GitHub Team יכולים עכשיו לרכוש את המוצרים האלה — עד 2025 זה היה זמין רק ל-Enterprise. המחירון הוא per active committer — כלומר אתם משלמים רק על מפתחים שעשו commit בפועל באותו חודש, לא על כל חבר בארגון.

Consumption-based billing — המודל החדש (מ-2025) הוא pay-as-you-go. אתם לא מתחייבים על מספר committers מראש. אם בחודש מסוים רק 3 מפתחים עשו commit — משלמים על 3. בחודש הבא 10 — משלמים על 10. זה מפחית את הסיכון ומאפשר להתחיל בקטן.

לקוחות GHAS הקיימים: אם הארגון שלכם כבר משלם על GHAS, המעבר למודל החדש (Secret Protection + Code Security) יקרה בחידוש הבא אחרי אפריל 2025. ברוב המקרים העלות דומה — אבל עכשיו אפשר לרכוש רק את מה שצריכים (למשל Secret Protection בלי Code Security).

מה חינמי ומה בתשלום — הטבלה המלאה

איך לקרוא את הטבלה: אם הפרויקט שלכם הוא public repo — כל האבטחה חינמית. זה אחד היתרונות הגדולים של פרויקטי קוד פתוח ב-GitHub. אם הריפו private — Dependabot חינמי לגמרי, אבל code scanning, secret scanning ו-push protection דורשים רישיון (Secret Protection או Code Security).

טיפ אסטרטגי: אם אפשר, שקלו להפוך ריפוזיטורים ל-public (כמובן לא כאלה שמכילים IP, לוגיקה עסקית רגישה, או credentials) — תקבלו את כל כלי האבטחה בחינם. הרבה חברות מחזיקות internal tools, libraries, ו-config repos שאפשר להפוך ל-public בלי סיכון.

Security Overview — Dashboard ברמת ארגון

Security Overview הוא dashboard שמציג את מצב האבטחה של כל הריפוזיטורים בארגון:

• Detection — כמה alerts פתוחים, מה ה-severity, אילו ריפוזיטורים הכי פגיעים
• Remediation — איך alerts נסגרים, זמן ממוצע לתיקון, מגמות
• Prevention — כמה secrets נחסמו ע"י push protection, אחוז הצלחה

זמין לבעלי ארגון, security managers, ומי שיש לו רישיון Secret Protection או Code Security.

Enablement trends — Dashboard נוסף ב-Security Overview שמציג אילו ריפוזיטורים בארגון כבר הפעילו כל כלי אבטחה ואילו עדיין לא. שימושי מאוד ל-security team שרוצה להגיע ל-100% coverage: אפשר לראות בדיוק אילו repos עדיין לא הפעילו Dependabot, CodeQL, או secret scanning.

GitHub Code Quality (Public Preview מ-February 2026) — Dashboard ברמת ארגון שמציג לא רק אבטחה אלא גם code quality: code coverage, test results, lint issues. עדיין ב-preview אבל מצביע על הכיוון — GitHub הופך לפלטפורמה שלמה לניטור איכות קוד, לא רק אבטחה.

Free secret risk assessment — גם בלי רישיון Secret Protection, ארגוני Team ו-Enterprise יכולים להריץ סריקה חד-פעמית שמראה כמה secrets דולפים ב-repos שלהם. זה בחינם ונותן תמונה ברורה של מצב הסיכון — טוב לקבלת החלטה אם שווה לרכוש רישיון.

7.11 סיכום ומבט קדימה

מה למדנו ביחס ל-pipeline המלא

אחרי הפרקים הקודמים, ה-pipeline שלכם כולל:

1. פרק 1 (Actions): CI/CD — build, test, deploy אוטומטי
2. פרק 6 (Packages): פרסום packages ו-images אוטומטי
3. פרק 7 (Security): Dependabot מגן על dependencies, CodeQL סורק קוד, push protection חוסם secrets

כל שכבה מתחברת לקודמת: ה-packages שפרסמתם בפרק 6 עכשיו מוגנים ע"י Dependabot — אם תלות של ה-package שלכם פגיעה, Dependabot ייצר PR שיתקן. ה-Actions workflows מפרק 1 עכשיו כוללים גם CodeQL scanning שרץ על כל PR. וה-secrets שמפעילים את ה-pipeline — GITHUB_TOKEN, PATs, Docker credentials — push protection מוודא שהם לא דולפים לקוד.

טיפ לשימור ידע: אם עשיתם את כל התרגילים בפרק, הפרויקט שלכם כבר מוגן ע"י: dependabot.yml עם schedule ו-cooldown, CodeQL workflow עם security-and-quality queries, push protection מופעל, secret scanning פעיל, ו-SECURITY.md עם private vulnerability reporting. שמרו על זה — השגרה מסעיף "שגרת עבודה מומלצת" מוודאת שהכל ממשיך לעבוד.

בפרק הבא: נלמד לגשת ל-GitHub API ולבנות Webhooks ו-GitHub Apps. ה-tokens שתשתמשו בהם שם — PATs (classic ו-fine-grained), OAuth tokens, App installation tokens — אלה בדיוק הסוגים ש-push protection מגן עליהם. תלמדו את ההבדל בין סוגי האימות ואיך לבחור את הנכון. מה שלמדתם בפרק הזה על אבטחת secrets הוא הבסיס לעבודה בטוחה עם ה-API — כי כל טוקן שנוצר ב-API הוא secret שצריך הגנה.