GitHub הודיעה כי החל מ־8 בדצמבר 2026 היא תפסיק את Dependabot alerts ברוב המאגרים שלא נרשמה בהם פעילות במשך שנה. ההתראות הקיימות לא יימחקו אלא יועברו לארכיון, אך עבור צוותי אבטחה שמסתמכים על Dependabot כמנגנון ניטור שוטף, השינוי עלול ליצור נקודה עיוורת דווקא בקוד ישן שנשאר בשימוש.
מה נחשב מאגר לא פעיל
לפי GitHub, מאגר ייחשב פעיל אם בוצעה בו אחת מהפעולות הרלוונטיות במהלך השנה האחרונה: דחיפה של branch או tag, יצירת המאגר, או הפעלה של Dependabot alerts. מאגר שלא עומד בתנאים האלה עשוי להיכלל במדיניות החדשה.
ההיגיון ברור: סריקה ושמירת התראות עבור מיליוני מאגרים נטושים צורכות משאבים, ולעיתים ההתראות אינן נבדקות כלל. הבעיה היא ש”אין פעילות ב‑Git” לא תמיד שווה ל”אין שימוש”. שירות ותיק יכול להמשיך לרוץ בייצור חודשים ואף שנים בלי שינוי בקוד, ובכל זאת להיות חשוף לחולשה חדשה בתלות קיימת.
מה יקרה להתראות הקיימות
GitHub מדגישה שההתראות אינן נמחקות. כאשר המדיניות מופעלת, Dependabot alerts נכבות וההתראות הקיימות עוברות לארכיון. ניתן לשחזר אותן לאחר הפעלה מחדש. כל push למאגר אמור להפעיל את ההתראות מחדש, וגם שינוי ידני בהגדרה יכול לעשות זאת.
מבחינת ניהול סיכונים, ארכוב עדיף על מחיקה, אך הוא עדיין משנה את התהליך. אם צוות ה‑SOC או AppSec מושך התראות באופן קבוע, מאגר שעבר למצב לא פעיל עלול להיעלם מדוחות תפעוליים בלי שהיישום עצמו יצא משימוש.
מי לא אמור להיפגע מהשינוי
יש מספר חריגים חשובים. מאגרים שעליהם נאכפת תצורת אבטחה הכוללת Dependabot alerts אמורים להישאר פעילים מבחינת ההתראות. בנוסף, ארגוני Enterprise שבהם מדיניות מונעת ממנהלי מאגרים להפעיל או להשבית את Dependabot alerts לא ייכללו במהלך באופן זהה.
השינוי חל על תוכניות GitHub.com ועל GitHub Enterprise Cloud עם data residency. הוא אינו חל על GitHub Enterprise Server המקומי. לכן ארגון היברידי צריך לבדוק כל סביבת GitHub בנפרד ולא להניח שההתנהגות אחידה.
למה “מאגר רדום” עדיין יכול להיות מסוכן
תלות תוכנה אינה מפסיקה להשתנות רק משום שהקוד לא השתנה. חולשה יכולה להתגלות בספרייה שכבר נכללת ב‑build, בתמונה של container או ברכיב שממשיך לשרת תעבורה. מאגר ארכיון אמיתי, שאין לו deployment פעיל ואין ממנו artifacts בשימוש, הוא סיכון מסוג אחד. מאגר שמפעיל שירות יציב ולא קיבל commit שנה הוא סיכון אחר לגמרי.
לכן המדיניות החדשה מחייבת לחבר בין נתוני GitHub לבין מלאי היישומים: אילו מאגרים מייצרים שירותים פעילים, אילו כלולים בתהליכי build, ואילו באמת ננטשו. ללא המיפוי הזה, אפשר בטעות לכבות את שכבת ההתראה על נכס שעדיין חשוף לאינטרנט.
חמש פעולות מומלצות לצוותי DevSecOps
- הפיקו רשימת מאגרים ללא פעילות של 11–12 חודשים. התחילו לפני 8 בדצמבר כדי לאתר מאגרים שצפויים להיכלל במדיניות.
- הצליבו עם נכסי ייצור. בדקו deployment, container registries, package registries ו‑CI/CD כדי לזהות קוד “שקט” שעדיין עובד.
- אכפו security configuration. במאגרים קריטיים, תצורה ארגונית נאכפת עדיפה על תלות בהגדרת מאגר בודד.
- תעדו חריגים ובעלות. לכל מאגר רדום אך פעיל צריך להיות owner, תאריך בדיקה ומנגנון חלופי אם Dependabot מושבת.
- בדקו אינטגרציות. ודאו שה‑SIEM, כלי ניהול החולשות או דוחות האבטחה יודעים להבחין בין “אין התראות” לבין “ההתראות הושבתו”.
לא לבצע push מלאכותי רק כדי לעקוף את המדיניות
טכנית, push מפעיל את ההתראות מחדש. אבל commit ריק אחת לשנה אינו תחליף לממשל אבטחה. הוא יכול לטשטש את מצב המאגר ולהקשות על זיהוי נכסים נטושים. עדיף לקבוע אם המאגר פעיל עסקית, לאכוף עליו תצורת אבטחה מתאימה, או לבצע תהליך מסודר של הוצאה משירות.
השורה התחתונה
המדיניות החדשה של GitHub אינה מוחקת מידע, והיא כוללת דרכים פשוטות להפעלה מחדש. עם זאת, היא הופכת את “פעילות המאגר” לאות שמשפיע על רציפות ההתראות. ארגונים צריכים לוודא שהאות הזה משקף את המציאות התפעולית שלהם. עד 8 בדצמבר כדאי למפות מאגרים רדומים, לזהות אילו עדיין משרתים מערכות חיות, ולאכוף Dependabot במקום שבו היעדר commit אינו מעיד על היעדר סיכון.
מקור: GitHub Changelog — Dependabot alerts will pause on inactive repositories.
קרדיט תמונה: Ben Griffiths / Unsplash. התמונה זמינה לשימוש מסחרי ולא־מסחרי באתר וברשתות חברתיות לפי רישיון Unsplash; אין למכור את התמונה ללא שינוי מהותי ואין ליצור ממנה שירות תמונות מתחרה. דף המקור.
