אבטחת שרשרת אספקה בתוכנה - SBOM ומתקפות Supply Chain¶
תארו לעצמכם ארגון עם צוות אבטחת מידע מצוין, חומות אש מוגדרות היטב, וכל ההגנות הקלאסיות במקום. עכשיו תארו שתוקף פשוט מדלג על כל זה - לא על ידי פריצה ישירה לארגון, אלא על ידי פריצה לספק תוכנה שהארגון כבר סומך עליו ומריץ בעצמו. זו בדיוק מתקפת שרשרת האספקה (Supply Chain Attack), והיא אחת מהאיומים המשמעותיים ביותר בעולם הסייבר הארגוני היום.
איך מתקפת שרשרת אספקה עובדת¶
הרעיון המרכזי הוא ניצול אמון - ארגונים מריצים תוכנה, ספריות קוד פתוח, ועדכונים ממקורות שהם סומכים עליהם, בלי לבדוק מחדש כל שורת קוד בכל עדכון. תוקף שמצליח לחדור לספק תוכנה אחד - חברת פיתוח, ספריית קוד פתוח פופולרית, או אפילו כלי build שמשמש לקומפילציה - יכול להטמיע קוד זדוני שיופץ אוטומטית לכל הלקוחות של אותו ספק, דרך תהליך העדכון הרגיל והלגיטימי לגמרי.
הדוגמה הכי מוכרת היא מתקפת SolarWinds מ-2020, שבה תוקפים חדרו למערכת הבנייה (build system) של חברת תוכנה לניהול רשתות, והטמיעו קוד זדוני בעדכון תוכנה רשמי וחתום דיגיטלית. אלפי ארגונים, כולל סוכנויות ממשלתיות אמריקאיות, התקינו את העדכון "התקין" הזה מרצונם החופשי - ובכך פתחו דלת אחורית לתוקפים בלי לדעת.
למה קוד פתוח הוא נקודת תורפה מיוחדת¶
עולם התוכנה המודרני בנוי על שכבות עמוקות של תלויות (dependencies) - כל פרויקט מסחרי משתמש בעשרות עד אלפי חבילות קוד פתוח, וכל אחת מהן עשויה להסתמך על עוד חבילות. הבעיה היא שרבות מהחבילות האלה מתוחזקות על ידי מפתחים בודדים או קבוצות קטנות, בהתנדבות, בלי המשאבים או התהליכים הפורמליים שיש לחברות גדולות.
זה יוצר וקטור התקפה נוח במיוחד: תוקף יכול להשתלט על חשבון מתחזק חבילה פופולרית (למשל דרך פישינג), ולפרסם גרסה "מעודכנת" שמכילה קוד זדוני. כל פרויקט שמעדכן את החבילה הזאת אוטומטית - כפי שרוב הצוותים עושים באופן שגרתי - מכניס את הקוד הזדוני ישירות למערכת שלו, בלי שום אזהרה.
מה זה SBOM ולמה ממשלות מתחילות לדרוש אותו¶
SBOM (Software Bill of Materials) הוא בעצם "רשימת מרכיבים" מפורטת של תוכנה - בדיוק כמו רשימת הרכיבים על אריזת מזון, רק עבור קוד. SBOM מתעד בדיוק אילו ספריות, בגרסה ספציפית, נמצאות בתוך מוצר תוכנה נתון, כולל כל התלויות העקיפות (transitive dependencies) שרוב הצוותים אפילו לא מודעים אליהן.
הערך המעשי של SBOM מתבהר כשמתגלה חולשה חדשה בספרייה פופולרית (כמו שקרה עם Log4Shell ב-2021) - ארגון שיש לו SBOM מסודר יכול תוך דקות לדעת בדיוק אילו מהמערכות שלו משתמשות בגרסה הפגיעה, במקום לבצע סריקה ידנית מבוהלת של כל הקוד בארגון. בגלל זה, גופים ממשלתיים בארה"ב (ובעקבותיהם ארגונים רבים בעולם) התחילו לדרוש SBOM כתנאי לרכש תוכנה, במיוחד לאחר מתקפת SolarWinds.
איך ארגונים מתגוננים בפועל¶
סריקת תלויות אוטומטית (Dependency Scanning) - כלים שרצים כחלק מתהליך ה-CI/CD ובודקים אוטומטית אם מי מהחבילות שהפרויקט תלוי בהן מכילה חולשות ידועות, לפני שקוד מגיע לייצור.
נעילת גרסאות (Lockfiles) - שימוש בקבצי נעילה שמוודאים שכל התקנה מביאה בדיוק את אותן גרסאות שנבדקו, במקום לתת לתלויות "לזחול" אוטומטית לגרסאות חדשות בלי בקרה.
חתימת קוד ואימות שרשרת (Code Signing and Provenance) - וידוא קריפטוגרפי שקוד שמגיע מספק מסוים אכן נבנה על ידי אותו ספק, ולא שונה בדרך - שכבת הגנה שהייתה יכולה לצמצם משמעותית את הנזק במתקפת SolarWinds אילו הייתה מיושמת ברמה עמוקה יותר.
בדיקת הרשאות מוגזמות (Least Privilege for Build Systems) - הגבלת הגישה של מערכות הבנייה עצמן, כך שגם אם תוקף חודר אליהן, יכולת הנזק שלו מוגבלת.
למה זה חשוב אם אתם עובדים ב-DevOps או אבטחת מידע¶
תפקידי DevOps ו-Platform Engineering היום כוללים יותר ויותר אחריות על אבטחת שרשרת האספקה - לא רק "האם הקוד שלנו בטוח", אלא "האם כל מה שהקוד שלנו תלוי בו בטוח". זה תחום שמצריך הבנה גם של תהליכי CI/CD וגם של חשיבה אבטחתית, ולכן הוא נקודת מפגש טובה למי שכבר מכיר DevOps ורוצה להעמיק גם באבטחת מידע.
תכירו את קורס פיתוח צד שרת שלנו כאן
לסיכום¶
מתקפות שרשרת אספקה מנצלות את האמון שארגונים חייבים לתת לספקי תוכנה וספריות קוד פתוח, והופכות עדכון "לגיטימי" לנקודת כניסה לתוקפים. SBOM וכלים דומים נותנים לארגונים נראות אמיתית לתוך מה שהם למעשה מריצים - כלי הכרחי בעולם שבו כל תוכנה בנויה משכבות עמוקות של תלויות שאף אחד לא באמת בודק אחת-אחת.
אם אתם רוצים לדבר על זה עם אנשים אחרים מעולם ה-DevOps והסייבר, יש לנו קהילה שלמה בדיסקורד.