איך לאבטח מפתחות גישה וסיסמאות בקוד המקור

⁦TL⁩;⁦DR⁩:

• האישורים נשארים תקפים זמן רב לאחר החשיפה: סודות חשופים מהווים סיכון מתמשך, שכן 64% מהסודות שאומתו כתקפים ב-2022 היו עדיין בתוקף בינואר 2026, והם עוברים בין מאגרים (repos), תהליכי CI/CD, מחשבים ניידים וכרטיסי תמיכה.

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

• פלטפורמה אחת לזיהוי, תיקון ומניעה: הניטור משתרע על מאגרים, CI/CD, GitHub ציבורי ונקודות קצה של מפתחים, עם זרימות עבודה, הוספת סודות לכספות (vault onboarding) ובדיקות תוקף חוזרות כדי לוודא שהאישור הישן אינו פעיל עוד.

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

זה לובש צורות רבות; לדוגמה, מפתחות API מחברים יישומים לשירותים. אסימוני גישה מאפשרים לאוטומציה ליצור אינטראקציה עם התשתית. חשבונות שירות שומרים על פעילות מערכות הייצור. סוכני AI משתמשים באישור שמוטמע בקוד (hardcoded) בשרתי MCP (Model Context Protocol) כדי לגשת לכלים ולמשאבים הדרושים להם להשלמת משימותיהם.

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

מציאת אישורים חשופים היא הצעד הראשון במשימתנו לזהות (Detect), לתקן (Remediate) ולמנוע (Prevent) את התפשטות הסודות בטקסט גלוי. בעוד צוותים רבים ניסו שיטות שונות לאיתור סודות במערכות מבודדות, מציאת כל הסודות ברחבי הארגון נותרה אתגר אמיתי, במיוחד כאשר שטח התקיפה גדל ללא הרף. GitGuardian עוזר לך לראות את כל שכבת האישורים. האתגר האמיתי הנוסף עבור צוותי אבטחה מתחיל לאחר גילוי הסוד. המענה לשאלות כמו "מי הבעלים של זה?", "למה זה מתחבר?" ו-"מה יישבר אם אבטל את האישור הזה?" הופך לאתגר המיידי של צוותי האבטחה, וזהו השלב שבו תוכניות רבות קורסות תחת העומס.

הדבר הופך לקשה יותר ויותר עבור ארגונים ככל שהם מרחיבים במהירות את התשתית שלהם ורואים מהנדסים לא מסורתיים, או "מקודדים אזרחיים", מאמצים פיתוח בעזרת AI. מחקר State of Secrets Sprawl 2026 של GitGuardian מצא 28.65 מיליון סודות חדשים שהוטמעו בקוד ב-commits ציבוריים ב-GitHub במהלך 2025, עלייה של 34% מהשנה הקודמת. מספר האישורים הדורשים הגנה ממשיך לגדול ככל שפיתוח התוכנה מתרחב.

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

מהי שכבת האישורים ומדוע תוקפים מכוונים אליה

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

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

כפי שהוסבר במאמר הקודם שלנו, מה זה ⁦Credential Layer Security⁩? , שכבת האישורים משתרעת על המערכות המקשרות בין התוכנה, התשתית והשירותים של הארגון.

איפה גרות האישורים עכשיו

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

נניח שאפליקציה משתמשת במקש ⁦API⁩. מפתח יצר אותו בתוך ספק זהות. הם אחסנו אותו ב-⁦AWS⁩ ⁦Secrets Manager⁩ והפנו אליו דרך תצורה של ⁦Kubernetes⁩, שם הוא נצרך בסופו של דבר על ידי עומס עבודה בקונטיינר.

מאוחר יותר, מפתח אחר פותר בעיות באפליקציה ומעתיק "באופן זמני" את האישור הדרוש לקובץ תצורה מקומי, ושוכח להסירו לפני ה-commit.

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

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

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

מדוע אישור חשוף נשאר בסיכון עומד

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

אישורים סטטיים בטקסט רגיל יוצרים הזדמנות מתמשכת לשימוש לרעה בזמן שהאישור נשאר תקף. והם בדרך כלל נשארים תקפים במשך זמן רב. המחקר של 2026 ⁦State of Secrets Sprawl⁩ מצא כי 64% מהסודות שאושרו כתקפים בשנת 2022 היו עדיין תקפים כאשר נבדקו מחדש בינואר 2026.

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

כאשר סוכנים ⁦AI⁩ משתלבים בתהליכי עבודה ארגוניים, חשיפת האישורים מקבלת משמעות נוספת. סוכנים צריכים גישה אל ⁦APIs⁩, תשתית ושירותים כדי להשלים משימות. ⁦Credentials⁩ והרשאות קובעות את רדיוס הפיצוץ כאשר אחת מהזהויות הללו נפגעת.

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

כיצד ⁦GitGuardian⁩ ניגש לאבטחת שכבת אישורים

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

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

הטבלה הבאה ממפה שאלות אבטחה נפוצות ליכולות הטכניות שעוזרות לענות עליהן.

מיפוי סיכון אישור ליכולות ⁦GitGuardian⁩

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

בדיקת תוקף ואימות מחדש ספציפיים לספק כאשר נתמכים

עוזר להבחין בין סיכון גישה פעיל לבין אישורים לא חוקיים

⁦Secret Analyzers⁩ ומידע על הרשאות שמקורן בספק

עוזר להעריך השפעה אפשרית ולתעדף תגובה

ייחוס ל-commit, מטא-נתונים של מקור, הצעות לבעלות והקצאה ידנית.

מחבר אירועים לאנשים האחראים לתיקון

זיהוי אירועים, התאמת סודות ומלאי בין מקורות מחוברים.

עוזר לזהות חשיפות נוספות ועותקים מאוחסנים

מלאי של מנהל סודות, התאמת כספת, מטא נתונים והערכות מדיניות

חושף אישורים לא מנוהלים ופערי כיסוי כספת

⁦Exploration Map⁩ קשרים המחברים בין צרכנים ידועים, משאבים ותקריות

עוזר למשיבים לחקור תלות תפעולית

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

מפחית תיאום ידני ותומך בתיקון

בדיקות תוקף חוזרות, בדיקות נוכחות, פעילות אירוע ומעקב אחר מחזור חיים

מספק ראיות לתמיכה בהחלטות על פתרון הבעיה.

ניתוח כיסוי, איתור, תיקון ומניעה

עוזר להנהלה להעריך את התקדמות האבטחה ואת יעילות ההשקעה.

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

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

זיהוי: מצא אישורים ברחבי הארגון

תחום אבטחת הסודות צמח ברובו מעולם פיתוח התוכנה, ולכן הגיוני שסריקת הסודות המסורתית התרכזה בקוד המקור, בצינור ה-CI/CD (אינטגרציה רציפה ואספקה רציפה) ובארטיפקטים שנוצרו בתהליך. זו אכן נקודת התחלה מהותית, אך עלינו להכיר בכך שאלו רק היבטים בודדים של שכבת האישורים.

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

קוד, ⁦CI/CD⁩, מכולות וכלי שיתוף פעולה

Git הוא על שמנו, אז כמובן שסיפקנו סריקת קוד במאגרי git דרך ⁦Internal Secrets Monitoring⁩ . אבל הפלטפורמה חורגת מקוד, ומזהה אישורים חשופים בסביבות פיתוח פנימיות מחוברות ומקורות נוספים נתמכים. זה כולל ניטור תשתיות פיתוח ומיקומים נתמכים כגון כלי שיתוף פעולה, אחסון בענן ומקורות הקשורים למכולות.

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

מפתח ⁦API⁩ שהתגלה במאגר עשוי להיות גם הועתק לכרטיס ⁦Jira⁩ או נחשף באמצעות קובץ תצורה. מציאת ההתרחשויות הידועות האחרות שלה עוזרת לצוותי אבטחה לחקור את החשיפה המלאה במקום להתייחס לכל גילוי באופן עצמאי.

⁦Public GitHub⁩, כולל מאגרים אישיים של מפתחים

⁦Public Secrets Monitoring⁩ מרחיב את הגילוי לציבור ⁦GitHub⁩.

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

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

חשיפה ציבורית מעלה את הדחיפות בהבנת התוקף וההרשאות, שכן ייתכן שהאישור כבר נגיש מחוץ לארגון.

מחשבים ניידים למפתחים וסוכני הקידוד ⁦AI⁩ הפועלים שם

GitGuardian יודע שכל דליפה בבסיס קוד, בפלטפורמת SaaS או בשרשרת כלים חייבת להתחיל איפשהו. המקום הזה הוא לרוב הסביבה שבה המפתח יצר והעתיק לראשונה את הסודות. אנו מתייחסים לסביבות אלו כאל נקודות קצה של מפתחים (Developer Endpoints). כאן מצטברים קבצי תצורה מקומיים, היסטוריית shell, מטמוני IDE וספריות של עוזרי AI המכילים סודות בטקסט גלוי במהלך תהליך הפיתוח השגרתי.

GitGuardian's ⁦Developer Endpoint Protection⁩ חושף את האישורים החשופים הללו ונותן לצוות שלך תובנות לגבי הסיכונים שהם נושאים.

ניתן להטמיע את ה-Developer Endpoint Protection בכל המכונות בארגון באמצעות פלטפורמות MDM (ניהול מכשירים ניידים) כמו Jamf, Intune או Iru. הזיהוי מתרחש באופן מקומי, והכלי שולח רק ערכי hash ומטא-נתונים של הממצא לפלטפורמת GitGuardian. ל-GitGuardian אין שום כוונה לאחסן את הסודות בטקסט גלוי שלכם. הממצאים מוערכים לפי מכונה, חומרה ותוקף.