מתחזקי קוד פתוח אוהבים תרומות לקוד, אבל בשנה האחרונה תיבת הדיווחים הפרטית הפכה לסיוט של עותק-הדבק. חוקרי אבטחה מטעם עצמם מריצים מודלים של שפה על מאגרים ציבוריים, ומפציצים מתנדבים בהתראות אבטחה דרמטיות שבמקרה הטוב מנותקות מהקוד ובמקרה הרע מומצאות לגמרי. אתמול הודיעה GitHub על שני מהלכים משלימים שנועדו להחזיר את השפיות למערכת: מגבלות קצב יומיות על דיווחים וטפסים מובנים שמחייבים הוכחת היתכנות אמיתית.
הכלים החדשים זמינים לכל המאגרים הציבוריים שבהם מופעל דיווח אבטחה פרטי, בכל החשבונות של החברה כולל השכבה החינמית. המטרה אינה לסגור את הדלת בפני חוקרים שמאתרים באגים קריטיים, אלא לייקר את המחיר של ספאם אוטומטי. כשכל דיווח דורש שדות חובה והוכחה כתובה, היכולת לירות לכל הכיוונים בלחיצת כפתור נפגעת מיד.
זה צעד מתבקש שהיה צריך להגיע מזמן.
טופס קשיח במקום טקסט חופשי
עד העדכון הנוכחי, ממשק הדיווח הפרטי כלל תיבת טקסט פתוחה אחת. המבנה הזה הקל על שולחי ספאם להדביק פלט גנרי שנפלט מבוט בלי לספק שום ראיה לכך שהפגיעות אכן קיימת במציאות, כפי שמפורט בהודעה על הטפסים המובנים.
תיבת טקסט חופשי אחת הקלה על הגשת דיווחים באיכות ירודה או שנוצרו על ידי AI, והקשתה עליכם למצוא את האות בתוך הרעש.הודעת העדכון של GitHub
ברירת המחדל החדשה מחייבת מילוי של ארבעה שדות חובה, ובראשם הוכחת היתכנות באורך של 150 תווים לפחות כתנאי סף ללחיצה על כפתור השליחה. ארבעת השדות כוללים תקציר, פרטים מלאים, PoC, והשפעה. התשובות מאוחדות אוטומטית לתיאור הדיווח, כך שתהליך הבדיקה בצד המתחזק נשאר זהה למה שהיה עד כה.
אם ברירת המחדל לא מתאימה לכם, אפשר לייצר טופס מותאם אישית באמצעות קובץ VULNERABILITY_REPORT.yml תחת תיקיית github. במאגר. הטופס נשען על התחביר המוכר של טופסי Issues ותומך בהגדרת אורך מינימלי לכל שדה. כדי להחיל אותו על כל המאגרים בארגון, מניחים את הקובץ בתוך מאגר ה-github. הראשי של החשבון. בנוסף, מנהלים יכולים לדרוש סיווג CWE מחייב מדף ההגדרות, והמערכת מציגה באנר למדיניות האבטחה אם קיים קובץ SECURITY.md.
מבחינת אוטומציות וסריקות, הוספת טופס מותאם אישית משפיעה ישירות על ממשק REST API. דיווח שנשלח דרך ה-API למאגר שבו הוגדר טופס כזה יידחה אם לא יעמוד במבנה המדויק, עם הפניה לנקודת קצה שמחזירה את השדות הדרושים. ברירת המחדל של GitHub, לעומת זאת, אינה נאכפת על ה-API כדי לא לשבור אינטגרציות קיימות.
מגבלות יומיות ורשימת מהימנים
החלק השני של ההגנה תוקף את בעיית הכמות. GitHub הפעילה מגבלות קצב יומיות שמגבילות את מספר הדיווחים שמשתמש בודד יכול לפתוח ביום, הן מול מאגר ספציפי והן ברחבי הפלטפורמה כולה. חוקר שמגיע לתקרה נחסם זמנית ומקבל הודעה לנסות שוב מאוחר יותר.
לא הייתי ממהר לבנות על פתרון קסם, אבל הסינון הזה מורגש מיד.
המגבלה תקפה אך ורק לפתיחת דיווחים חדשים. תגובות, הערות או שרשורי המשך על גבי דיווחים וטיוטות שכבר נפתחו אינם נספרים ואינם מוגבלים, כך שהדיאלוג הטכני השוטף על תיקון ליקוי לא ייעצר באמצע. כדי לא לפגוע בעבודה מול חוקרים רציניים, מנהלי מאגר יכולים להגדיר מכסה יומית מותאמת אישית, ולהוסיף חשבונות מוכרים לרשימת מהימנים שאינה כפופה למגבלות כלל. ההגדרה מתבצעת תחת Advanced Security בלשונית ההגדרות של המאגר, כפי שמוסבר גם בדוקומנטציה של הפלטפורמה.
| פרמטר | לפני העדכון | אחרי העדכון |
|---|---|---|
| מבנה טופס ברירת המחדל | תיבת טקסט חופשי אחת | 4 שדות חובה כולל תקציר והשפעה |
| דרישת הוכחת היתכנות (PoC) | אין דרישת מינימום | חובה, מינימום 150 תווים |
| התאמת טפסים אישית | לא נתמך | קובץ YML ייעודי במאגר או בארגון |
| מגבלות קצב על דיווחים חדשים | ללא מגבלה יומית למשתמש | מגבלה יומית גלובלית וברמת המאגר |
| חריגים למגבלת הקצב | ללא | רשימת מהימנים (allowlist) למאגר |
| אכיפה על ה-API בדיווח ברירת מחדל | ללא אכיפת מבנה | ללא אכיפה (נאכף רק בטופס מותאם) |
האותיות הקטנות והחורים ברשת
למרות שמדובר בצעד נחוץ, יש כאן כמה נקודות תורפה שכדאי להכיר לפני שבונים על שקט מוחלט. ראשית, GitHub לא פירטה בהודעה מהן בדיוק מגבלות ברירת המחדל שהיא אוכפת, וכיצד מחושב חלון הזמן היומי, האם לפי חצות או בחלון זמנים מתגלגל. שנית, אין כרגע אפשרות מתועדת לנהל רשימת מהימנים רוחבית ברמת הארגון, אלא רק ברמת כל מאגר בנפרד, מה שמייצר עבודה ידנית מיותרת.
הטופס כולל כעת תיבת סימון שבה המדווח מצהיר האם השתמש בכלי AI כדי לאתר או לנסח את הפגיעות. מדובר במנגנון הצהרתי בלבד. מי שמציף מאגרים בדיווחי זבל מתוך כוונה לצבור קרדיט מפוקפק לא ימהר לסמן את התיבה הזאת, ו-GitHub אינה מפעילה כאן זיהוי אוטומטי.
ההגנות הללו גם לא יעצרו מתקפה מבוזרת של עשרות חשבונות שונים, והן כלל אינן תקפות למאגרים פרטיים. לפי הודעת החברה, העדכונים זמינים בכל החשבונות של הפלטפורמה ללא עלות נוספת. כדי להגן על המאגר שלכם מומלץ להיכנס כבר עכשיו להגדרות, לקבוע מכסה יומית הגיונית, ולהכניס את החוקרים שאתם עובדים איתם לרשימת הפטורים. הבוטים ימשיכו לחפש פרצות, אבל לפחות יצטרכו להזיע קצת יותר על ה-PoC.
מקורות
- Rate limits for private vulnerability reportshttps://github.blog/changelog/2026-10-01-rate-limits-for-private-vulnerability-reports
- Structured forms for private vulnerability reportshttps://github.blog/changelog/2026-10-01-structured-forms-for-private-vulnerability-reports
- our docs about configuring private vulnerability reportinghttps://docs.github.com/code-security/how-tos/report-and-fix-vulnerabilities/configure-vulnerability-reporting/configure-for-a-repository
- GitHubhttps://weba.co.il/tools/github/
- REST APIhttps://weba.co.il/glossary/rest-api/
הידיעה נכתבה מהמקורות שלמעלה בתאריך הפרסום, וכל טענה בה נבדקה מולם. מצאתם טעות? כתבו.