מתקפות שרשרת אספקה של תוכנה הופכות נפוצות יותר ויותר והרסניות. לדוגמה, גרטנר צופה כי 45% מכלל העסקים יחוו פרצה עד 2025. בנוסף, מיזמי אבטחה ברשת מדגיש את חומרת האיום הזה, וצופה נזקים שנתיים מדהימים של 138 מיליארד דולר עד 2031. בסך הכל, תחזיות אלו מדגישות את הצורך הדחוף של ארגונים לתעדף software supply chain security וליישם אמצעים חזקים להגנה על נתונים רגישים, פעולות ומוניטין.
מכיוון שהמודרני pipelineתלויים במידה רבה ברכיבים חיצוניים, עלייתן של ספריות צד שלישי, מחזורי פיתוח תוכנה מהירים יותר, שרשראות אספקה מורכבות, חוסר נראות, טכניקות תקיפה חדשות, אימוץ SaaS ומשאבים מוגבלים - כולם מניעים את העלייה ב... מתקפות שרשרת אספקה של תוכנהלכן, ארגונים חייבים לאמץ גישה מקיפה ואקטיבית כדי להתמודד עם אתגרים אלה ולהגן על שרשראות האספקה של התוכנה שלהם.
מהי מתקפת שרשרת אספקה של תוכנה?
ENISA מגדיר מתקפת שרשרת אספקה של תוכנה as "פגיעה בנכס מסוים, למשל תשתית של ספק תוכנה ותוכנה מסחרית, במטרה לפגוע בעקיפין במטרה או במטרות מסוימות, למשל לקוחות ספק התוכנה." במילים אחרות, מתקפת שרשרת אספקה של תוכנה היא פעילות זדונית המכוונת לשרשרת האספקה של התוכנה, במטרה לפגוע ולהחדיר פגיעויות או תוכנות זדוניות לתהליך הפיתוח וההפצה. כתוצאה מכך, סוג זה של מתקפה מנצל את הרשת המחוברת ולעתים קרובות מסובכת של תהליכים, כלים וישויות המעורבים בבנייה ואספקת תוכנה.
רכיבים ומושגים מרכזיים הקשורים להתקפת שרשרת אספקה של תוכנה
ספרות בנושא מודיעין איומי סייבר ומידע-סקיוריטי לעיתים קרובות מתקלקלת מתקפות שרשרת אספקה של תוכנה לקטגוריות נפרדות לצורך ניתוח והגנה טובים יותר. בהתאם לכך, סעיף זה מציג את חמשת המושגים המרכזיים שהוגדרו על ידי קטלוג תבניות התקפה של MITREקטלוג זה מבנה דפוסי תקיפה של שרשרת האספקה כדי להקל על ניתוח באמצעות מקורות שונים, כולל איומים עוינים שנאספו על ידי NIST.
חוק התקפה: מה
פעולת התקפה היא הפעולה הספציפית שמעבירה מטען או כוונה זדונית למערכת. כתוצאה מכך, היא מייצרת נזק ישיר.
- דוגמה 1: תוכנה זדונית שהוכנסה לתוכנת מערכת במהלך תהליך הבנייה.
- דוגמה 2: דרישות מערכת או מסמכי עיצוב שונו בזדון.
וקטור התקפה: איך
וקטור התקיפה הוא השיטה בה משתמשים יריבים כדי לנצל פגיעויות או לעבד חולשות. כתוצאה מכך, הוא מראה כיצד תוקפים ניגשים למשטח התקיפה ומנצלים אותו לרעה.
- דוגמה 1: תוקף משנה קוד מקור במאגר פרוץ.
- דוגמה 2: תוקף מקבל גישה בלתי מורשית לתיעוד טכני פנימי.
חקור עוד ב מילון מונחים של וקטור התקפה לתובנות נוספות.
מקור ההתקפה: המי
המקור מזהה את מקור ההתקפה. לכן, הוא מבהיר את תפקידו, מעמדו או הקשר שלו למערכת.
- דוגמה 1: גורם פנימי עם גישה מורשית לבניית שרתים משנה סקריפט.
- דוגמה 2: גורם איום חיצוני מעלה חבילה טרויאנית לרישום ציבורי.
מטרת התקפה: הסיבה
המטרה מסבירה את הסיבה מאחורי ההתקפה. מעל הכל, היא מדגישה מה היריבים רוצים להשיג.
- שיבוש: עצירת שירותים או בנייה.
- שחיתות: הפחתת אמון על ידי שינוי חפצים או קוד מקור.
- גילוי: דליפת סודות רגישים או קניין רוחני.
השפעת ההתקפה: ההשלכות
לבסוף, ההשפעה מתארת את תוצאות ההתקפה, ומציגה את ההשלכות עבור ספקי תוכנה ולקוחות.
- דוגמה 1: כל פרויקט המשתמש בתוכנית גרועה ייפגם בהמשך.
- דוגמה 2: אנשים מתקינים תוכנה גרועה במערכות העבודה שלהם מבלי לדעת זאת.
התקפות שרשרת האספקה הנפוצות ביותר של תוכנה
סוגים רבים של מתקפות שרשרת אספקה של תוכנה קיימים, וארגונים חייבים להיות מודעים לווקטורי האיום השונים בכל שלב של מחזור החיים. בהתבסס על מסגרת ה-SLSA, המכון הלאומי של ארה"ב ל Standardוטכנולוגיה (NIST), ו הסוכנות לאבטחת סייבר ואבטחת תשתיות (CISA), ניתן לקבץ איומים אלה לארבע קטגוריות: סיכוני מקור, בנייה, חבילה ותלות.
מתקפות שרשרת אספקה של תוכנה בשלב המקור
- שלח קוד גרוע → ראה כיצד בקשת בקשת בקבוק. שימוש לרעה or פגמים לא מאובטחים בהסרת סריאליזציה ליצור משטחי התקפה ישירים.
- מאגר מקורות פגיעה
- בנה ממקור שעבר שינוי
- כתיבת קוד לא מאובטח
- שיבוש קבצים קריטיים → כפי שמוסבר ב ניתוח chmod 777 של דלת אחורית.
מתקפות שרשרת אספקה של תוכנה בשלב הבנייה
ב שלב בנייה, מפתחים קומפילציה ומשלבים קוד לגרסה עובדת. כי שלב זה כה קריטי, הסיכונים כוללים דילוג על בדיקות אבטחה ב CI/CD pipeline, שינוי קוד לאחר בקרת גרסאות, או פגיעה בתהליך הבנייה. כתוצאה מכך, קוד זדוני יכול להתגנב לתוך ארטיפקטים מבלי משים.
- עקיפה CI/CD מקושר ל תוכנה זדונית של GitHub לפני בנייה.
- שינוי קוד לאחר בקרת קוד המקור
- תהליך בנייה נפגע → מופחת באמצעות זיהוי התרעה מוקדמת של DevSecOps.
- מאגר חפצים שנפגע
מתקפות שרשרת אספקה של תוכנה בשלב האריזה
השמיים שלב החבילה זה כאשר אנו מחברים את כל הקוד יחד כדי ליצור מוצר סופי. חלק זה מסוכן מכיוון שמישהו עלול להשתמש בחבילות שגויות או לשנות את המקומות המקוונים שבהם אנו מקבלים אותן. תוקפים יכולים אפילו להעלות גרסאות מזיקות של חבילות פופולריות לאתרים אלה.
- השתמש בחבילה שנפגעה → מכוסה ב הערכות של סורקי תוכנות זדוניות.
- רישום חבילות פגיעה
- העלה חבילה שעברה שינוי → נותח ב תוכנות זדוניות מזויפות של Namsogen.
מתקפות שרשרת אספקה של תוכנה בשלב התלות
ב שלב התלותאנו מוסיפים ספריות וחבילות של צד שלישי לתוכנה שלנו. שלב זה מסוכן מכיוון שכל בעיה בחלקים אלה יכולה להתפשט בקלות ובשקט לשאר הפרויקט.
- שימוש בתלות שנפגעה → מוסבר עם סיכוני DoS בתלות מעורפלות.
- תלויות מיושנות או פגיעות
- סיכוני תלות חולפת
- רישומי חבילות זדוניים → טופלו באמצעות כלי אבטחה של DevOps ו ניהול סיכונים של צד שלישי.
סיכונים נפוצים בשרשרת האספקה בכל שלב SDLC
| התמחות | איומים אופייניים | דוגמה |
|---|---|---|
| מָקוֹר | • שליחת קוד זדוני או לא מאובטח • התעסקות עם קבצים קריטיים • פגיעה במאגר המקור | אקסקוד גוסט (2015): קוד זדוני שהוזרק לתוך קומפיילר Xcode של אפל, והתפשט באפליקציות iOS. |
| לִבנוֹת | • עקיפת CI/CD בדיקות אבטחה • שינוי קוד לאחר בקרת קוד המקור • פגיעה במאגרי חפצים | סולארוונס אוריון (2020): התוקפים חדרו למבנה pipeline, הוספת דלת אחורית לעדכוני תוכנה חתומים. |
| חֲבִילָה | • העלאת חבילות שעברו שינוי • רישומי חבילות הרעלה • הפצת חפצים שנפגעו | NPM של EventStream (2018): התוקף הכניס דלת אחורית לחבילת NPM פופולרית שהורדה אלפי פעמים. |
| תלות | • שימוש בתלות מיושנות או פגיעות • ניצול תלויות טרנזיטיביות • פרסום חבילות דומות לזדוניות | XZ משתמש ב-Backdoor (2024): ספריית דחיסה מושרת טרויאנית כמעט ונשלחה במורד הזרם להפצות לינוקס. |
טכניקות נפוצות להתקפה על שרשרת אספקה של תוכנה
על פי CISלפי דו"ח של NIST, מתקפות בשרשרת האספקה של תוכנה מתחלקות לרוב לשלוש קטגוריות עיקריות.
עם זאת, אירועים אחרונים מראים וקטורים נוספים שמפתחים חייבים להבין.
להלן נרחיב על הטכניקות הרלוונטיות ביותר עם דוגמאות מעשיות.
עדכוני חטיפה
תוקפים פוגעים במנגנוני עדכון לגיטימיים כדי להפיץ תוכנות זדוניות
לדוגמה, מתקפת NotPetya בשנת 2017 ניצלה לרעה את שרת עדכוני תוכנת המס האוקראינית MEDoc, וסיפקה
תוכנה זדונית הרסנית למגבים במסווה של טלאי. כדי להתגונן מפני סיכון זה, על הצוותים ליישם זיהוי ותגובה לאיומים עבור DevOps שיטות שמסמנות התנהגות חריגה בזרימות עדכון.
פגיעה בחתימה על קוד
טכניקה זו כוללת שימוש לרעה או גניבת אישורי חתימה תקפים כדי לגרום לקוד זדוני להיראות לגיטימי.
מקרה בולט היה פריצת CCleaner בשנת 2017, שבו תוקפים הפיצו תוכנה טרויאנית חתומה עם אישורים תקפים.
כתוצאה מכך, ארגונים זקוקים לבקרות שלמות מאוחדות כגון אלו המתוארות ב אסטרטגיות פלטפורמת אבטחת סייבר
פשרה בקוד פתוח
יריבים מחדירים דלתות אחוריות לחבילות קוד פתוח פופולריות, ומאוחר יותר נשלפות לאלפי פרויקטים.
תקרית EventStream NPM והדלת האחורית של XZ Utils (2024) ממחישים עד כמה וקטור זה הפך להיות קריטי.
מפתחים צריכים לבדוק משאבים כמו שאלות נפוצות בנושא אבטחת NPM ו תקריות חבילות מסוג typosquatted כדי ללמוד כיצד להימנע מתלות מורעלת.
בלבול תלות
מתקפה זו, שתוארה לראשונה על ידי אלכס בירסן בשנת 2021, מנצלת התנגשויות בשמות בין רישומי חבילות פנימיים וציבוריים, ומטעה מערכות בנייה למשוך גרסאות זדוניות במקום חבילות פנימיות מהימנות.
חבילות Typosquatting ו-Payments זדוניות
תוקפים מפרסמים חבילות זדוניות עם שמות דומים לספריות פופולריות (למשל, "reqeusts" במקום "requests").
מפתחים מתקינים אותם בטעות, ומכניסים תוכנות זדוניות לפרויקטים שלהם.
דוגמה אמיתית מנותחת ב תוכנות זדוניות של Namso-gen וברשימה שלנו של סורקי תוכנות זדוניות בקוד פתוח.
לִבנוֹת Pipeline מתעסק
כפי שניתן לראות בפשרה של SolarWinds Orion, תוקפים יכולים לחדור לשרתי בנייה כדי להחדיר קוד זדוני במהלך הקומפילציה.
זה הופך את כל שרשרת החפצים החתומים ללא אמינה. טכניקות למניעה כוללות ניטור CI/CD יושרה עם גילוי מוקדם ומנתח
קמפיינים של תוכנות זדוניות בבניית GitHub מראש.
כיצד נראית מתקפת שרשרת אספקה של תוכנה: מקרה SolarWinds
מעל לכל, מתקפת SolarWinds Orion היא הדוגמה הידועה ביותר לפריצה לשרשרת אספקה של תוכנה. היא מראה כיצד תוקפים יכולים לנוע צעד אחר צעד בתהליך הבנייה, וכתוצאה מכך, להפיץ קוד מזיק לאלפי משתמשים.
ראשית, תוקפים חדרו לשרתי הבנייה של SolarWinds.
לאחר מכן, הם הוסיפו בשקט קוד זדוני לעדכוני Orion.
מכיוון שעדכונים אלה נחתמו ונשלחו כתוכנות מהימנות, חברות רבות התקינו אותם מבלי לדעת את הסיכון.
בסך הכל, יותר מ-18,000 ארגונים נפגעו, ותוקפים קיבלו גישה למערכות רגישות מאוד.
מנקודת מבטו של מפתח, מתקפה זו נותנת שלושה לקחים פשוטים:
- הגנות היקפיות אינן מספיקותהתוקפים שינו את המבנה pipeline עצמו.
- בדיקות מתמשכות הן קריטיותמאובטח build attestations, בדיקות שלמות וזיהוי אנומליות מסייעים בחסימת שיבושים.
- מבנה מורעל אחד יכול להפוך לגלובלייחיד pipeline פשרה עלולה ליצור משבר ביטחוני עולמי.
Xygeni: פלטפורמת AppSec האולטימטיבית הכל-באחד
מכיוון שמתקפות בשרשרת האספקה של תוכנה יכולות לפגוע בכל שלב של SDLC,
פלטפורמת AppSec הכל-באחד, קסיגני, מגן על שלבי המקור, הבנייה, האריזה והתלות. זה נותן למפתחים ולצוותי אבטחה מקום אחד למנוע, לזהות ולתקן סיכונים בצורה פשוטה. כתוצאה מכך, אינך צריך עוד ללהטט בין כלים מרובים, Xygeni מכסה את מחזור החיים המלא.
הגנה על שלב המקור
בשלב המקור, הסיכונים כוללים גורמים לא בטוחים commits, מאגרים מורעלים, או קבצים שעברו שינוי. Xygeni סורק קוד בזמן אמת עם עמוק SAST וגילוי סודות.
זה גם חוסם מזיקים commits דרך CI/CD guardrails.
בדרך זו, בעיות נעצרות עוד לפני שהן עוזבות את המאגר.
בניית הגנה על הבמה
במהלך שלב הבנייה, תוקפים עשויים לנסות לעקוף pipelineאו לשנות חפצים.
Xygeni מאבטחת את תהליך הבנייה עם בדיקות תואמות SLSA, אימות שלמות וחתימות ללא מפתח. הוא גם עוקב אחר התנהגות חריגה בתוך CI/CD עבודות. כתוצאה מכך, גרסאות מבנים שעברו שינוי מסומנות מיד ונחסמות לפני השחרור.
הגנת שלב החבילה
בשלב האריזה, רישומים שנפגעו או ספריות שעברו שינוי לעיתים קרובות מציגים תוכנות זדוניות. זיהוי תוכנות זדוניות וסריקת רישיונות של Xygeni לסקור כל חפץ, תוך כדי AutoFix מציע נתיבי שדרוג בטוחים עם ניתוח סיכוני התיקון שלה. רק חבילות מאומתות ותואמות מתקדמות ב pipeline.
הגנה על שלב התלות
קוד של צד שלישי הוא משטח ההתקפה הגדול ביותר. ניתוח הרכב התוכנה של Xygeni (SCA) עושה יותר מאשר רק רישום CVEs, היא בודקת אם ניתן בפועל לנצל קוד מסוכן. היא גם מסמנת תוכנות זדוניות נסתרות ותלויות טרנזיטיביות מסוכנות. מעל הכל, זה מבטיח שמפתחים שולחים רק תלויות בטוחות.
סודות ואבטחת תשתיות
מעבר לקוד וחבילות, התקפות לעיתים קרובות מנצלות סודות שדלפו או תשתית חלשה. Xygeni סורק אחר מפתחות, טוקנים ופרטי אישורים חשופים בקוד, בקונפיגורציות ובשכבות Docker. זה יכול גם לאמת ולבטל אוטומטית סודות שדלפו בעזרת תיקון AutoFix. באותו הזמן, IaC סריקה מונע תצורות שגויות שתוקפים עלולים לנצל לרעה בהמשך.
זיהוי ותיקונים חכמים יותר
רוב הכלים נעצרים בהתראות. קסיגני הולך רחוק יותר. מנוע ה-AutoFix שלו יוצר תיקונים מאובטחים, pull requests, או הדרכה שלב אחר שלב בהתאם לבעיה. תצוגת סיכוני התיקון שלה מראה גם איזו גרסת תיקון היא הבטוחה ביותר, כך שצוותים מתקנים בעיות מבלי להוסיף חדשות.
פלטפורמה מאוחדת אחת
מכיוון ש-Xygeni משלב SAST, SCA, זיהוי תוכנות זדוניות, ניהול סודות, IaC סריקה, זיהוי אנומליות ובקרות בנייה מאובטחות בפלטפורמת AppSec אחת,
זה נותן כיסוי מלא לכל אורך SDLCגם מפתחים וגם צוותי אבטחה מקבלים מקור אחד של אמת עם נראות ברורה, תיקונים מעשיים והגנה חזקה מפני מתקפות בשרשרת האספקה.
כל הדברים נחשבים, Xygeni, פלטפורמת AppSec האולטימטיבית הכוללת, עוזר לצוותים לבנות במהירות ולהישאר מאובטחים. על ידי הגנה על שלבי המקור, הבנייה, האריזה והתלות, ועל ידי הוספת תיקונים אוטומטיים בכל שלב, זה מבטיח שהתקפות שרשרת האספקה של תוכנה נעצרות לפני שהן מגיעות לייצור.
