הגדרת Secret Scanning באמצעות GitHub Advanced Security

דליפות סודות: מה GitHub Advanced Security לא סוגר

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

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

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

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

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

מה נותנת סריקת סודות רציפה

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

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

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

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

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

השוואת מצבים: היכן ומתי להפעיל סריקה

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

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

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

שלבי הטמעה: מביקורת מאגרים ועד העברה

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

1. ביקורת מאגרים. אוספים רשימה מלאה, מפרידים פרויקטים ארכיוניים ובדיקות, ומסמנים מאגרים של קבלנים ופתוחים החוצה.
2. סכמת כיסוי. לכל קבוצה קובעים מצב: בדיקה בכל שינוי, ריצה תקופתית או מעבר חד-פעמי על כל ההיסטוריה.
3. כללים וחריגים. מפעילים סט תבניות סטנדרטי, משלימים בתבניות מותאמות לפורמטים פנימיים של מפתחות, ומגדירים חריגים ממוקדים לפי נתיבים, ולא על ידי השבתת הבדיקה.
4. בדיקת התראות שווא. מריצים את הכללים על היסטוריה אמיתית, מסמנים רעש ומשפרים את המסננים, עד שחלק הממצאים המאומתים נעשה סביר עבור צוות התורנות.
5. התראות והרשאות. מסכמים מי מקבל הודעה על ממצא, מי רשאי לסגור אותו ואיך מוגדרות תזכורות אם המקרה נשאר בלי תגובה.
6. העברה והדרכה. מוסרים תיעוד ונוהל תגובה לדליפה, כולל סדר ביטול מפתח, ומנתחים דוגמאות חיות עם הצוותים.

GitHub Advanced Security משתלב בסביבה הזו, ולא מחליף אותה. אחרי ההעברה נשארים לצוות סכמת כיסוי, כללים, חריגים וסדר פעולה ברור בעת ממצא.

ערכת הגדרות, סכמות ונוהלי תגובה

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

• קונפיגורציות סריקה: אילו ענפים ונתיבים נמצאים בבדיקה, איך מוגדרים חריגים לנתוני בדיקה, היכן הוגדרו ספי התראה.
• סכמת כיסוי מאגרים — מה מחובר, ומה בכוונה מחוץ לתחום (ארכיון, מראות ספק), כדי שפרויקט חדש לא ייווצר בלי בדיקה.
• רשימות תבניות מותאמות לפורמטים הפנימיים שלכם של מפתחות, טוקנים ומחרוזות חיבור — מה שסטי כללים בסיסיים לא תופסים.
• מדיניות גישה: מי משנה כללים, מי רואה ממצאים, מי סוגר התראה. התפקידים מופרדים כדי שלא יכבו בדיקה למען בנייה ירוקה.
• מטריצת אחריות — לכל סוג ממצא מוגדר בעלים: צוות שירות, פלטפורמה או אבטחה, וזמן תגובה לאות.
• נוהל תגובה — הסדר מהתראה ועד רוטציה: למי נשלח האות, מי עוצר את הצינור, מי מאשר ביטול והחלפת מפתח.
• תיעוד אירועים — תבנית תחקור עם שדות „איך המפתח נכנס להיסטוריה” ו„מה שינו בתהליך”, כדי שחזרה לא תלך באותו תרחיש.
• תזכורת למפתח: בדיקה מקומית לפני דחיפת שינויים, סדר פעולה בעת התראה, ניקוי היסטוריית ענף בלי לאבד עבודה.

מקרה בוחן: הסרנו דליפות מפתחות מצינור הבנייה

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

הטמענו את GitHub Advanced Security כך שהבדיקה תרוץ בכל קומיט ובאופן מתוזמן על כל ההיסטוריה, ולא רק על השינוי האחרון.

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

מדדים לפני ואחרי

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

במה סריקה מובנית של GitHub נבדלת מסורקים חיצוניים

סריקה מובנית של GitHub Advanced Security פועלת בתוך הפלטפורמה: המנוע בודק לא רק את מצב הענף הנוכחי, אלא את כל היסטוריית השינויים, כולל קומיטים שנמחקו מהענף הראשי. דווקא שם לרוב נשארים מפתחות שנכנסו בטעות לקוד ו„נמחקו” בקומיט הבא. סורק חיצוני שמחובר לאירועי המאגר רואה רק את השינוי האחרון ומפספס עקבות כאלה.

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

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

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

שאלות טכניות בהגדרת סריקה

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

איך להבדיל בין התראת שווא לדליפה אמיתית?

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

סדר העדיפויות של הניתוח נקבע ידנית: מפתח מסביבה סגורה מנתחים לפי תוכנית, ומפתח ייצור עם גישה לנתונים — מחוץ לתור.

הנתונים כבר עברו לפורק חיצוני — מה לעשות?

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

האם זה יאט את עבודת המפתחים?

הבדיקה מופעלת ברקע בעת דחיפת שינויים ופתיחת בקשת מיזוג, ומאטה רק במצב חוסם בהגנת הענף. בהטמעה שמים „התראה”, וענפים קריטיים עוברים למצב חוסם מאוחר יותר: זמן הבנייה לא גדל.

יש לנו קבצי סביבה מקומיים — גם אותם לנקות?

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

נדבר על המשימה: מאיפה להתחיל את ההגדרה

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

מה כדאי להכין לדיון על המשימה:

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

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

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