איך לתעדף דליפות מידע רגיש לפי רמת סיכון אמיתית
אמ;לק
דליפות של סיסמאות ומפתחות גישה הן סכנה קריטית. המאמר מסביר שכלים אוטומטיים מפספסים חלק גדול מהדליפות, ומציע שיטה לדרג את הסיכון לפי מה שתוקף יכול להשיג בפועל כדי שתדעו מה לסגור בדחיפות.
סיכום בעברית: מערכת VibeSec · מדיניות המקורות
נוסף ל-VibeSec:
כותרת מקורית: What Is a High-Impact Leak? How to Rank Compromised Credentials by Real Risk

התוכן המלא בעברית
תרגום אוטומטי מהמקור; מונחים טכניים נשארו באנגלית. לנוסח המחייב — הכתבה המקורית.
TL;DR
• דליפה בעלת השפעה גבוהה היא סוד חשוף: היא עלולה לגרום לנזק חמור אם תגיע לידיים הלא נכונות, מכיוון שהיא עדיין פעילה או שלא ניתן להוכיח שהיא אינה פעילה, והיא מעניקה גישה לסביבות ייצור (Production), לקוד מקור, לנתונים רגישים או לזהויות בעלות הרשאות גבוהות.
• תוקף אינו מספיק: תעדוף המבוסס על אימות (Validation) בלבד מחמיץ 46% מהסודות הקריטיים, מכיוון שלא ניתן לאמת אותם באופן אוטומטי.
• חמשת הגורמים הקריטיים: טווח הגישה (Reach), הסביבה, רמת הפעילות (Liveness), המיקום והזמן יחד עם הבעלות, קובעים את חומרת הנזק הפוטנציאלי של הדליפה ואת הדחיפות הנדרשת להכיל אותה.
• מה לעשות תחילה: יש להכיל דליפות בעלות השפעה גבוהה עוד באותו היום, ולבצע הסלמה (Escalation) לסוד שאינו ניתן לבדיקה אך מעניק גישת ניהול, מבלי להמתין לבדיקת תוקף.
שתי התראות נוחתות באותו תור באותו בוקר, ושתיהן מסומנות כתקפות. האחת היא מפתח לקריאה בלבד עבור לוח מחוונים (Dashboard) של ניתוח נתונים בסביבת Staging. השנייה היא מפתח פרטי של GitHub App, סוג של אישור שלעולם לא פג תוקפו. תור שממוין אך ורק לפי תוקף מציב את שתי ההתראות הללו זו לצד זו.
דירוג אישורים שנפגעו על סמך מה שהם מאפשרים לעשות דורש מענה לחמש שאלות. הן יסדירו את רוב ההתראות, אם כי חלקן עדיין יישארו באזור אפור.
מהי דליפה בעלת השפעה גבוהה?
דליפה בעלת השפעה גבוהה היא סוד חשוף שעלול לגרום לנזק חמור אם יגיע לידיים הלא נכונות. הוא עדיין פעיל, או שאף אחד לא יכול להוכיח שאינו פעיל, והוא מעניק גישה למערכות ייצור, לקוד מקור, לנתונים רגישים או לזהויות בעלות הרשאות גבוהות.
GitGuardian מציב רף מחמיר יותר עבור הדלפות פומביות לפני שהוא מזהיר מישהו. הסוד חייב להיחשף בפומבי ולהיות קשור לארגון ספציפי, מכיוון שאישור שדלף הופך לבעיה דחופה רק ברגע שידוע למי הוא שייך. בתוך תור התקריות הארגוני שלך, השאלה הזו בדרך כלל כבר פתורה. עבור מפתח שנמצא במאגר ציבורי של זר, נדרשת חקירה של ממש. חקירה זו היא העבודה מאחורי תוכנית ה-Enterprise Good Samaritan של GitGuardian, שמזהירה ארגונים מפני הדלפות שטרם גילו.
לפגיעויות יש שפת חומרה משותפת בדמות CVSS. לסודות שדלפו אין מקבילה בשימוש נרחב, לכן כל צוות מפתח הגדרת עבודה משלו, בין אם היא מתועדת ובין אם לא. חמשת הגורמים שלהלן מהווים גרסה אחת של הגדרה כזו, המבוססת על השאלות שהחוקרים שלנו שואלים לפני ביצוע הסלמה במקרה של הדלפה פומבית.
דלף פירושו נפגע
אנחנו יוצאים מנקודת הנחה שהייתה פריצה, ולכן אנו מתייחסים למידע שדלף כאל מידע שנפגע. אישור שנחשף מחוץ ל-Vault הוא אישור שמישהו אחר יכול להשתמש בו. המתנה להוכחה לשימוש לרעה לפני שמכריזים על האישור כנפגע אינה עובדת עבור אישורי מכונה, כי כאשר מופיעה הוכחה כזו, זה כבר מאוחר מדי.
השאלה המועילה היא כמה נזק זה יכול לגרום. הגדרת ההשפעה (Impact) מסווגת את האישור ואת ההקשר שלו, כך שניתן להעריך אותו מיד. דליפה בעלת השפעה גבוהה מגיעה לסביבות ייצור, לנתונים רגישים או לגישת מנהל מערכת, ויש להכיל אותה באותו היום.
מדוע פגיעה באישור נותרת לעתים קרובות ללא מענה
שימוש לרעה באישור מכונה מעורר אזעקה לעתים רחוקות בלבד. התוקף מאומת כשירות לגיטימי, ללא דרישת MFA בדרך. הראיות נמצאות ביומני הביקורת (Audit Logs) של הספק, שלרוב אינם נקראים. גם חלונות החשיפה ארוכים מאוד. מתוך הסודות שאישרנו כתקפים בשנת 2022, 64% היו עדיין תקפים בינואר 2026, לפי דו"ח The State of Secrets Sprawl 2026.
אישורים חשובים הרבה מעבר לשלב הראשוני של התקיפה. דו"ח Data Breach Investigations Report של Verizon לשנת 2026 זיהה שימוש לרעה באישורים בכל שלב, כולל לאחר הפריצה הראשונית, ומצא זאת ב-39% מהפרות האבטחה, יותר מכל שיטת גישה אחרת שנבחנה.
מדוע חלק מהסודות שדלפו אינם בעלי השפעה גבוהה
הנפח הוא שהופך את הדירוג להכרחי. ספרנו 28.65 מיליון סודות חדשים שקודדו באופן קשיח (Hardcoded) ב-GitHub הציבורי בשנת 2025, זינוק של 34% לעומת השנה הקודמת. כאשר כל ממצא מסומן כקריטי, אף אחד לא יכול להבדיל בין מצב חירום לבין ניקוי שגרתי, ועייפות מהתראות אבטחה משתלטת במהירות.
ממצאים רבים ראויים לדירוג נמוך יותר או לתור טיפול אחר:
• מפתחות בדיקה ו-Sandbox: אישורים אמיתיים שמאמתים מול שירותים שאינם חשובים.
• סודות שבוטלו או שפג תוקפם: עדיין כדאי לבדוק את השימוש שנעשה בהם בזמן שהיו פעילים, אך הם כבר אינם מהווים דרך כניסה.
• מפתחות בעלי טווח גישה מצומצם: גישת קריאה בלבד למשאב יחיד בעל רגישות נמוכה.
• סודות שאינם שייכים לך: מפתח שמזכיר את הדומיין שלך אך שייך לספק או לפרויקט אישי של מישהו.
• כפילויות: סוד אחד שנמצא במקומות רבים, מה שמהווה אירוע אחד לתיקון.
דליפה בעלת השפעה נמוכה עדיין עוברת סבב (Rotation) לפי לוח הזמנים של הבעלים שלה ולא לפי דחיפות של היום. מדובר במקרה שונה מ-False positive, שאינו סוד פעיל כלל.
חמשת הגורמים שהופכים דליפה לבעלת השפעה גבוהה
טווח גישה, סביבה, רמת פעילות ומיקום קובעים את חומרת הנזק שהדליפה עלולה לגרום, בעוד שהזמן והבעלות קובעים את דחיפות ההכלה. הם לא תמיד יצביעו על אותה רמת דחיפות. אישור עשוי להעניק הרשאות רחבות ללא דרך לאמת אם הוא עדיין פעיל.
1. טווח הגעה: למה האישור יכול לגשת
התחל עם הרשאות. תפקידי מנהל מערכת, גישת כתיבה, התקנות כלל-ארגוניות, הרשאות Wildcard והיכולת להשתמש בתפקידים אחרים, כל אלה מרחיבים את מה שדליפה עלולה לאפשר. מפתח AWS בעל הרשאות יתר המקושר ל-AdministratorAccess ומפתח המוגבל ל-Bucket אחד לקריאה בלבד הם אירועים שונים, גם כאשר אותו גלאי מסמן את שניהם.
המחקר שלנו על מפתחות GitHub App שדלפו מראה עד כמה טווח הגישה יכול להתרחב. מבין האפליקציות שהמפתחות שלהן עדיין פעלו, ל-44 היו הרשאות ניהול ארגוניות, מה שהספיק להשתלטות על הארגונים שהתקינו אותן. הנזק יכול גם להתפשט למערכות המחוברות לכל מה שהאישור פותח.
2. סביבה: ייצור, הבמה או ארגז חול
לאותו סוג מפתח יש משקל שונה בהתאם למקום שבו הוא מבצע אימות. מפתח פעיל של ספק תשלומים יכול להעביר כסף, בעוד שמפתח הבדיקה שלו לא משפיע על שום דבר אמיתי. אותות המצביעים על סביבת ייצור כוללים שמות מארח, שמות משתנים עם קידומת PROD_, ענף ברירת המחדל וקבצי פריסה. שים לב לשימוש חוזר בסביבות שונות. אם סוד של סביבת Staging עובד גם בייצור, דרג אותו כסוד של סביבת ייצור.
3. חיים: תקף, לא ידוע או בוטל
סוד שאושר כתקף עובד ברגע זה. אישור שבוטל כבר אינו מאמת, אם כי כל מה שנעשה באמצעותו בזמן שהיה פעיל עדיין דורש בדיקה. המקרה המורכב הוא סוד שאף אחד לא יכול לבדוק אוטומטית, דבר שכיח בסיסמאות של מסדי נתונים ואישורים פנימיים ללא נקודת קצה ציבורית לבדיקה. כאשר לא ניתן לבדוק סוד, ההקשר חייב להכריע. אם הוא נמצא בסביבת ייצור או שהזהות שמאחוריו מחזיקה בזכויות מנהל, בצע הסלמה מבלי לחכות לבדיקת תוקף.
סודות שלא ניתן לבדוק הם המקום שבו תעדוף מבוסס-תוקף נכשל. הדו"ח שלנו, State of Secrets Sprawl 2026, מצא כי תעדוף המבוסס על אימות בלבד מחמיץ 46% מהסודות הקריטיים מכיוון שלא ניתן לאמת אותם באופן אוטומטי.
4. מיקום: היכן שהסוד צץ
מיקום הסוד קובע מי יכול למצוא אותו ובאיזו מהירות. מאגרים ציבוריים ורישומי מכולות (Container registries) נסרקים באופן אוטומטי. כלי שיתוף פעולה מפיצים סוד לכל מי שבשרשור השיחה במהלך עבודה דחופה, והדו"ח לשנת 2026 מצא שסודות שדלפו מחוץ לקוד הם בעלי סבירות גבוהה ב-13 נקודות אחוז להיות קריטיים, בהשוואה לאלה שנמצאו בתוך הקוד בלבד.
מכונות של מפתחים הן נקודת ריכוז נוספת. על פני מחשבים ניידים בתוכנית הגישה המוקדמת שלנו ל-Developer Endpoint Protection, מצאנו בממוצע כ-150 אישורים לכל מכונה, כאשר חלקן החזיקו אלפים. סוד שמופיע בפומבי וגם באופן פנימי מהווה בעיה גדולה יותר מאותו סוד שנמצא רק בתוך היקף הרשת שלך.
5. זמן ובעלות: כמה זמן הסוד נותר פעיל ומי יכול לבטל אותו
זמן מתייחס למשך הזמן שהסוד נחשף, והאם הוא נותר בהיסטוריית ה-git גם לאחר שמישהו מוחק אותו מהענף הנוכחי. בעלות מתייחסת למי שיכול לבצע סבב (Rotation) בבטחה. סוד ללא בעלים ברור נותר פעיל זמן רב יותר, כי אף אחד לא רוצה לשבור את השירות שהוא מפעיל. אישורים סטטיים ארוכי ימים מרחיבים את שני החלונות הללו. במחקר ה-GitHub App, מפתח של אפליקציה אחת דלף בנובמבר 2020 וההתקנות שלה עדיין פעלו שנים לאחר מכן, הרבה אחרי שהפרויקט מאחוריה נזנח.
מאגר ציבורי, צ'אט משותף נרחב, מחשב נייד שנפגע
דוגמאות לדליפות בעלות השפעה גבוהה ממחקר GitGuardian
מאגר ממשלתי נותר ציבורי למשך שישה חודשים
במאי 2026, מצאנו מאגר GitHub ציבורי בשם Private-CISA שהכיל 844 MB של נתוני CISA, כולל סיסמאות בטקסט גלוי ואסימוני (Tokens) AWS, שנחשפו מאז נובמבר 2025. חלק מהאישורים היו עדיין בתוקף. טווח הגישה, רמת הפעילות, המיקום והזמן קיבלו כאן דירוג גבוה. CISA הורידה את המאגר מהרשת תוך 26 שעות מהחשיפה שלנו.
אסימון Jira בתוך תמונת מכולה ציבורית
תמונה ציבורית של Docker מחברת מוצרי אלקטרוניקה הכילה אישורי Jira תקפים הקשורים לחשבון של עובד. הדליפה מעולם לא הגיעה למאגר קוד, כך שסורק שצפה רק בקוד המקור היה מפספס אותה. צוות האבטחה של החברה השיב במהירות לדיווח שלנו והחל בתהליך תיקון.
אישורי Kubernetes שזוהו דרך רישום מכולות (Container registry)
אישורים תקפים עבור אשכול (Cluster) Kubernetes הופיעו ב-Commit ציבורי ב-GitHub. הרמז לבעליהם היה רישום המכולות של האשכול, שהתארח בדומיין של מפעיל תקשורת גדול. בהתאם להרשאות שלהם, אישורים אלה היו עשויים לאפשר למישהו לשנות עומסי עבודה פעילים או לגשת לנתונים רגישים. דיווחנו על הדליפה דרך תוכנית הפרסים על באגים (Bug bounty) של החברה, שבה הדירוג היה 9.8, ציון חומרה קריטי, תוך שלושה ימים.
כיצד GitGuardian מדרג את השפעת הדליפה
יכולות שונות של GitGuardian עונות על השאלות שלעיל. כל אחת מהן ממופה לפחות לגורם אחד:
• בדיקות תוקף (רמת פעילות): בדיקות מול הספק, במידת האפשר, מאשרות אם סוד עדיין עובד.
• ציון סיכון (מספר גורמים): ציון מבוסס למידת מכונה מ-0 עד 100 עבור תקריות Internal Monitoring, הנגזר מסוג הסוד, תוקף, הקשר הזיהוי ודפוסי חשיפה. תצוגת ה-Critical מציגה ציונים מעל 80.
• Secrets Analyzer וממשל NHI (טווח גישה): ממפים את התפקידים וההרשאות של סוד ומסמנים זהויות מנהל או זהויות מכונה בעלות הרשאות יתר, כך שהממצאים הקשורים אליהן מדורגים גבוה יותר.
• Public Secrets Monitoring (טווח גישה, מיקום): GitGuardian מעריך כל תקרית ציבורית בהתאם לרלוונטיות שלה לארגון ולסיכון, ומציג את ההיגיון שמאחורי ההחלטה. הצוות שלך הוא זה שמקבל את ההחלטה הסופית.
בהערכה של GitGuardian, דירוג למידת המכונה עלה על פני 72% מהדליפות הקריטיות, עם דיוק של 75% בדגלים קריטיים.
GitGuardian מספק לצוותי אבטחה רשימה מדורגת של סודות חשופים ואת ההקשר הנדרש כדי לפעול קודם כל על אלה בעלי ההשפעה הגבוהה, בעוד שהיומנים של הספק מאשרים האם נעשה שימוש באישור.
ראה את התקריות שלך מדורגות לפי השפעה.
FAQ
סוד חשוף שעלול לגרום נזק חמור אם מישהו ישתמש בו. הוא מעניק גישה למערכות ייצור או הרשאות מנהל, ואף אחד לא יכול להוכיח שהוא הפסיק לעבוד. רוב ההדלפות אינן עומדות ברף הזה, וזו הסיבה שצוותים מדרגים אותן לפי השפעה לפני שהם מתחילים לבטל אותן. GitGuardian מוסיף שני תנאים לפני שמזהיר ארגון חיצוני: הדליפה חייבת להיות פומבית, ועליה להיות קשורה בבירור לאותו ארגון.
פגיעה באישור מתרחשת כאשר סיסמה, מפתח API, אסימון או סוד אחר מגיעים למקום שמישהו אחר עלול להשתמש בו ללא הרשאה. עבור חשבונות משתמש אנושיים זה מתחיל לעתים קרובות בפישינג או בתוכנות זדוניות לגניבת מידע. עבור אישורי מכונה זה מתחיל לעתים קרובות יותר בדליפה, כגון מפתח במאגר קוד או במחשב נייד של מפתח. ברגע שהתוקף מבצע אימות, רוב בקרות האבטחה במורד הזרם מתייחסות אליו כאל הזהות הלגיטימית.
עבור אישורי מכונה, אנו מתייחסים אליהם כאל אותו הדבר. אישור שנחשף מחוץ ל-Vault הוא אישור שמישהו אחר יכול להשתמש בו, לכן הוא נחשב לנפגע מרגע גילויו. מה שמשתנה מדליפה אחת לאחרת הוא ההשפעה.