כבלי רשת וציוד שרתים במרכז נתונים
צילום: Taylor Vick / Unsplash

GitHub מתחילה לסרוק Secrets גם בלוגים של Actions — עם מגבלות חשובות

GitHub הרחיבה את Secret Scanning כך שתסרוק גם לוגים של GitHub Actions. ההרחבה, שזמינה כעת ב‑Public Preview, נועדה לזהות מפתחות, Tokens ופרטי גישה שנחשפו במהלך הרצת Workflow — גם כאשר הם לא קיימים בקוד המקור עצמו.

לפי GitHub, הסריקה מתחילה לאחר השלמת הריצה. המערכת מחפשת דפוסים של ספקים נתמכים, ופותחת התראה ברשימת Secret Scanning של המאגר. ההתראה כוללת קישור ללוג שבו נמצא הסוד, ומופיעה לצד התראות שמקורן בקוד, Issues, Wikis, Discussions ו‑Pull Requests.

למה לוגים הם נקודת סיכון

צוותי פיתוח משקיעים מאמץ במניעת Commit של סודות, אך לוגים יכולים לחשוף אותם בדרכים אחרות: פקודת Debug שמדפיסה משתנה סביבה, Script שמציג כותרת Authorization, תגובת שגיאה שמכילה Credential או כלי צד שלישי שמדפיס תצורה מלאה. הסוד עשוי להיחשף רק בזמן הריצה, ולכן סריקת המאגר לבדה לא תמצא אותו.

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

איך מפעילים את התכונה

ה‑Preview מיועד לארגונים ב‑GitHub Enterprise Cloud שיש להם GitHub Secret Protection או GitHub Advanced Security, כולל ארגונים עם Data Residency ב‑GHE.com. בעל Enterprise יכול להפעיל את המדיניות דרך:

  1. Enterprise settings.
  2. Policies.
  3. Advanced Security.
  4. בחירת Enabled תחת All repositories.

המדיניות כבויה כברירת מחדל. היא חלה רק על מאגרים שבהם Secret Scanning כבר מופעל במסגרת הרישוי המתאים. לפני הפעלה רוחבית, מומלץ לוודא שלצוות האבטחה יש תהליך תגובה, בעלים להתראות וגישה להחלפת Credentials.

המגבלות שחשוב להכיר

  • אין סריקה לאחור: רק ריצות שמסתיימות לאחר הפעלת היכולת נסרקות.
  • לא כל דפוס נתמך: דפוסים גנריים, דפוסים מותאמים אישית ו‑Secrets שמזוהים באמצעות AI אינם נסרקים בשלב ה‑Preview.
  • Secrets ממוסכים אינם מזוהים: אם GitHub Actions כבר הסתירה ערך בלוג, הסריקה החדשה אינה מדווחת עליו.
  • אין התראות יזומות: במהלך ה‑Preview ההתראות מהלוגים אינן שולחות Notifications. צריך לבדוק את רשימת Secret Scanning באופן יזום.

המגבלה האחרונה משמעותית: הפעלה ללא תהליך ניטור קבוע עלולה ליצור תחושת ביטחון שגויה. צוותים צריכים להכניס את רשימת ההתראות לבדיקת SOC או AppSec קיימת, לפחות עד ש‑GitHub תוסיף Notifications.

ארבע פעולות מומלצות לצוותי DevSecOps

  1. להפעיל בהדרגה: להתחיל בקבוצת מאגרים קריטיים ולבדוק את איכות ההתראות לפני הרחבה.
  2. להגדיר Playbook: ביטול או סבב Credential, בדיקת שימוש חשוד, זיהוי מקור ההדלפה ותיקון ה‑Workflow.
  3. לצמצם פלט רגיש: להסיר Debug מיותר, לא להדפיס משתני סביבה ולהימנע מתגובות מלאות של APIs.
  4. לא להסתמך על שכבה אחת: לשלב Masking, הרשאות מינימליות, OIDC קצר‑חיים וסריקה לפני Commit.

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

סריקת לוגים מוסיפה שכבת הגנה חשובה משום שהיא בודקת את מה שקרה בפועל בזמן האוטומציה, ולא רק את התוכן שנשמר במאגר. אבל ה‑Preview עדיין אינו תחליף לניהול Secrets תקין: אין Backfill, הכיסוי חלקי ואין Notifications. הערך האמיתי יגיע כאשר ההפעלה תחובר לתהליך תגובה מדיד ולא תישאר עוד הגדרה במסך המדיניות.

מקור

GitHub Changelog — Secret scanning detects secrets in GitHub Actions workflow logs, ‏9 בנובמבר 2026.

קרדיט תמונה: Taylor Vick / Unsplash. דף המקור: Unsplash. רישיון: Unsplash License, המתיר שימוש מסחרי ולא‑מסחרי באתר, בסושיאל ובחומר שיווקי; אין למכור את התמונה ללא שינוי מהותי ואין ליצור מאגר מתחרה. אומת ב‑10.11.2026.

דילוג לתוכן