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

למה זה קיים

כל סקיל שנכנס לקטלוג עובר בדיקה אוטומטית של אותות אבטחה ב-GitHub. יש 5 אותות קריטיים שאנחנו דורשים מכל ריפו, ועוד 15 אותות בדרגות "מומלץ" ו"בונוס" שמעלים את ציון האמון אבל לא חוסמים פרסום.

בחרנו דווקא את חמשת האותות האלה כי הם תופסים את רוב התקלות שאנחנו רואים בריפואים של מפתחים שמתחילים: סודות שדלפו לתוך git, קוד עם פגיעויות שלא עבר סריקה, release-ים לא חתומים שאין דרך לדעת מי בנה אותם בפועל, ורישוי לא ברור שמרתיע משתמשים מלהשתמש בקוד.

הריפואים של skills-il מגיעים עם ההגדרות האלה כברירת מחדל, ולכן סקילים שלנו עוברים אוטומטית. בריפו חיצוני אתם צריכים להגדיר את הכל לבד. המדריך הזה הוא צ'קליסט הכנה להגשה. המעבר על חמשת האותות אורך בערך 15 דקות.

האותות הקריטיים

1. תאימות למפרט (spec_compliant)

מה זה בודק: gh skill publish --dry-run רץ על SKILL.md ומוודא שהוא תקין לפי המפרט הפתוח של agentskills.io. אם יש שגיאות מבנה, שדות חסרים או HTML זדוני בתיאור, הבדיקה נכשלת.

איך מפעילים:

1. התקינו את GitHub CLI בגרסה 2.90.0 ומעלה: brew install gh (Mac), או ראו הוראות לכל מערכת הפעלה. מ-2.90 ואילך הפקודה gh skill מובנית, אין צורך בהתקנת תוסף נפרד.
2. הריצו את הבדיקה אצלכם מקומית: gh skill publish --dry-run path/to/your-skill.

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

הערה: הבדיקה הזו רצה רק על סקילים, לא על MCP. שרתי MCP נבדקים במסלול נפרד (Tank, Snyk, Cisco), ולא רצים מולם gh skill publish.

2. סריקת סודות (secret_scanning)

מה זה בודק: GitHub סורק כל commit כדי לתפוס מפתחות API, סיסמאות, JSON-ים של service accounts וטוקנים שדלפו בטעות. האות עובר כשהסריקה דולקת ואין התראות פתוחות על סודות חשופים.

איך מפעילים:

1. היכנסו ל-Settings של הריפו.
2. גללו ל-Code security and analysis.
3. הפעילו את Secret scanning וגם את Push protection.

על ריפואים ציבוריים זה חינם. מ-מרץ 2024 GitHub מפעיל את זה אוטומטית על ריפואים חדשים בחשבונות אישיים, אבל ריפואים שכבר היו קיימים, או ריפואים בארגון, צריכים הפעלה ידנית. אם זה מסומן כ-Disabled אצלכם, פשוט לחצו Enable. שתי דקות עבודה ושקט נפשי שלם.

טיפ: הקפידו להפעיל גם את Push protection. הוא חוסם את ה-push ברגע שמזוהה סוד, עוד לפני שהוא מגיע ל-history. סוד שנדחף פעם אחת ל-git נחשב חשוף, גם אם תמחקו אותו רגע אחר כך.

3. סריקת קוד (code_scanning)

מה זה בודק: CodeQL סורק את הקוד שלכם לפגיעויות נפוצות (SQL injection, path traversal, XSS וכו'). האות עובר כש-CodeQL Default Setup פעיל בריפו.

איך מפעילים:

1. בריפו, היכנסו ל-Settings ← Code security and analysis.
2. תחת Code scanning לחצו Set up ← Default.
3. בחרו את ה-default branch (master/main) ואת השפות ש-GitHub זיהה אוטומטית.
4. שמרו.

הסריקה רצה אוטומטית על כל push ל-main, ובנוסף פעם בשבוע על הקוד הקיים. בריפואים פרטיים זה דורש GitHub Advanced Security (בתשלום); בריפואים ציבוריים זה חינם.

לא רואים את האפשרות? יכול להיות שהארגון שלכם חסם את זה ברמת הארגון. דברו עם מנהל GitHub שלכם, או העבירו את הריפו לחשבון אישי בינתיים.

4. release חתום (signed_release)

מה זה בודק: ל-release האחרון יש Sigstore attestation שנוצר על ידי GitHub Actions. זה מאשר שה-release נבנה באמת מהקוד שיושב ב-repo, ולא הוחלף בדרך.

איך מפעילים:

1. צרו קובץ .github/workflows/release.yml בריפו עם התוכן הבא:

name: Release
on:
  push:
    tags: ['v*']

jobs:
  release:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      id-token: write
      attestations: write
    steps:
      - uses: actions/checkout@v4
      - uses: actions/attest-build-provenance@v4
        with:
          subject-path: |
            **/SKILL.md
            **/SKILL_HE.md
            **/metadata.json

1. דחפו תג חדש: git tag v1.0.0 && git push origin v1.0.0.
2. ה-workflow ייצור attestation שיירשם ב-Sigstore Rekor.
3. אפשר לוודא דרך עמוד ה-Releases בריפו (יופיע באדג' "Verified attestation"), או להוריד artifact ולהריץ gh attestation verify <artifact> --owner <owner>.

שימו לב לפורמט של subject-path: הוא חייב להיות מופרד בשורות (כמו בדוגמה למעלה), לא ברווחים. רווח שובר את ה-action בלי הודעת שגיאה.

skills-il מספקת reusable workflow שעוטף את כל הפרטים האלה. בארגון skills-il/* הוא כבר מוטמע בכל ריפו קטגוריה. בריפו שלכם משתמשים בו ככה:

jobs:
  release:
    uses: skills-il/release-workflow/.github/workflows/release.yml@v1

5. רישיון מוצהר (license_declared)

מה זה בודק: הריפו מכיל קובץ LICENSE עם זיהוי SPDX תקני (MIT, Apache-2.0, BSD-3-Clause וכו'). ריפואים בלי רישיון, או עם רישיון ש-GitHub לא מזהה, לא עוברים את הבדיקה.

איך מוסיפים:

1. בעמוד הראשי של הריפו לחצו Add file ← Create new file.
2. שם הקובץ: LICENSE (באותיות גדולות, בלי סיומת).
3. בצד ימין יופיע כפתור Choose a license template. לחצו עליו ובחרו תבנית. MIT היא הבחירה המקובלת לסקילים.
4. דחפו ל-master.

GitHub מזהה את הרישיון אוטומטית ומציג אותו ב-sidebar של הריפו. בתוך דקה הוא מופיע גם ב-API ואצלנו הבדיקה עוברת.

למה לא להכניס את הרישיון בתוך README? GitHub לא מזהה רישיון שמופיע רק בתוך README, גם אם כתוב שם במפורש "MIT License". צריך קובץ LICENSE נפרד.

שאלות נפוצות

מה אם רק 4 מתוך 5 עוברים? אפשר בכלל להגיש? אפשר, אבל הסקיל לא יאושר אוטומטית. ההגשה תעבור לתור של בקרה אנושית עם שגיאה ברורה על האות שלא עבר, ואחד מהאדמינים יחזור אליכם במייל עם קישור למדריך הזה.

אני מתחזק לבד, אני בכלל צריך MFA? MFA הוא אחד מ-9 האותות המומלצים (לא קריטיים), אז הוא לא חוסם פרסום אבל מעלה את ציון האמון. להפעלה אצלכם: GitHub ← Settings ← Password and authentication ← Two-factor authentication. ארגונים שמחייבים MFA על כל החברים שלהם מקבלים אות נפרד שמעיד על כך.

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

הריפו שלי פרטי, אני יכול להגיש? לא. הקטלוג של skills-il עובד רק עם ריפואים ציבוריים, גם כי המשתמשים מתקינים את הסקיל ישר מ-GitHub, וגם כי חלק מהבדיקות (license, secret scanning וכו') מצריכות ש-GitHub יוכל לקרוא את הריפו.

מה ההבדל בין האותות הקריטיים לשאר דרישות האבטחה? האותות הקריטיים הם רף הכניסה לקטלוג. מעבר אליהם יש לנו עוד שכבות בקרה (סורק Tank, ביקורת ידנית, fact-check שבועי) שרצות בנפרד ולא תלויות באותות האלה.

קריאה נוספת

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