תוקפים כבר אינם מבצעים דיוג למשתמשים סופיים: הם מרמים מפתחים ומתחזקי חבילות קוד פתוח כדי להזריק קוד זדוני לתלויות קריטיות. מקרים כמו xz-utils (2024) או event-stream (2018) חושפים דפוס: דיוג בשרשראות אספקה מנצל את האמון במאגרים ציבוריים ואת היעדר אימות חתימות. הפתרון אינו רק טכני — הוא מחייב שינוי באופן שבו צוותי פיתוח מעניקים עדיפות לאבטחה בזרימות העבודה שלהם.

מדוע מפתחים הם היעד החדש לדיוג?

דיוג מסורתי מכוון לעובדים עם גישה לנתונים רגישים. בשרשראות אספקה, היעד הוא מתחזקי חבילות קוד פתוח — מפתחים המתחזקים ספריות המשמשות אלפי פרויקטים. ההיגיון פשוט: פגיעה במאגר יחיד יכולה להדביק מאות יישומים במורד הזרם. מחקר של Sonatype (2023) מצא כי ל-12% מהחבילות ב-npm, PyPI ו-Maven Central יש פגיעויות ידועות, אך הסיכון האמיתי טמון בחבילות שאיש אינו מבקר.

התקיפה מתחילה בדוא"ל או בהודעה ב-GitHub/GitLab שנראית לגיטימית: בקשת pull request, דיווח על באג, או אפילו הצעת שיתוף פעולה. במקרה של CyberShield, תועדו מקרים שבהם התוקפים השתמשו בחשבונות מזויפים עם שמות דומים למתחזקים אמיתיים (למשל: "johndoe-dev" לעומת "johndoe") כדי לשלוח קישורים למאגרים משובטים עם קוד זדוני. ההנדסה החברתית כאן אינה מתוחכמת — היא מנצלת את עומס התחזוקה: פרויקטים רבים בקוד פתוח מתוחזקים על ידי מתנדבים שאין להם זמן לבדוק כל תרומה.

שלושה מקרים שחשפו את הבעיה (וכיצד הם חוזרים על עצמם)

1. event-stream (2018): ההתקפה שאיש לא צפה

בנובמבר 2018, מפתח אנונימי שלח בקשת pull request לחבילה event-stream (המשמשת יותר מ-2 מיליון פרויקטים) כדי "לייעל" את הקוד. המתחזק המקורי, שאין לו זמן לבדוק, קיבל את השינוי. המשתף פעולה החדש הוסיף לאחר מכן תלות נסתרת (flatmap-stream) שגנבה אישורי ארנקי ביטקוין. ההתקפה לא זוהתה במשך חודשים מכיוון שהקוד הזדוני הופעל רק ביישומים ספציפיים (כמו הארנק Copay).

לקחים מרכזיים:

2. ua-parser-js (2021): כאשר הדיוג מתרחב לרמה גלובלית

באוקטובר 2021, החבילה ua-parser-js (עם 7 מיליון הורדות שבועיות) נפגעה לאחר שתוקף השיג גישה לחשבון npm של המתחזק. וקטור ההתקפה הראשוני היה דוא"ל דיוג שהתחזה לתמיכה של npm, וביקש "אימות חשבון". התוקף פרסם לאחר מכן גרסאות זדוניות של החבילה שהתקינו כורי מטבעות קריפטוגרפיים וטרויאנים במערכות Linux ו-Windows.

הדאגה לא הייתה בהתקפה עצמה, אלא בתגובת הקהילה:

3. xz-utils (2024): הדלת האחורית שכמעט שברה את האינטרנט

המקרה האחרון והמתוחכם ביותר. במרץ 2024, התגלתה דלת אחורית ב-xz-utils (ספריית דחיסה המשמשת בלינוקס) שאפשרה ביצוע קוד מרחוק. ההתקפה בוצעה על ידי משתף פעולה בשם "ג'יה טאן" (שם בדוי), שבמשך שנתיים צבר אמון של המתחזק המקורי באמצעות תרומות לגיטימיות. וקטור ההתקפה הסופי היה קובץ בדיקה (.m4) שהכיל קוד זדוני מוסווה.

פרטים טכניים של ההתקפה (CVE-2024-3094):

מקרה זה חשף כשלים קריטיים בשרשרת האספקה:

מדוע הפתרונות הקיימים אינם עובדים?

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

1. SBOM (רשימת חומרי תוכנה)

SBOM הוא מלאי של כל התלויות של פרויקט. כלים כמו syft או Dependency-Track יוצרים מלאים אלה באופן אוטומטי. הבעיה אינה ביצירת ה-SBOM, אלא בעדכון ואימות:

2. חתימות דיגיטליות (Sigstore, in-toto)

פרויקטים כמו Sigstore מאפשרים חתימה על commits ו-releases באמצעות מפתחות קריפטוגרפיים. in-toto הולך צעד נוסף: הוא חותם על כל שלב בפייפליין הפיתוח (מהקומיט ועד לפריסה).

מגבלות:

3. סריקת פגיעויות (Dependabot, Snyk)

כלים כמו Dependabot סורקים תלויות בחיפוש אחר CVEs ידועים. אך:

מודל האפס אמון המיושם בשרשראות אספקה

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

1. אימות חתימות בכל שלב

לא מספיק לחתום על הקוד הסופי. כל commit, כל PR, כל release חייבים להיות חתומים באמצעות מפתחות קריפטוגרפיים הניתנים לאימות. פרויקטים כמו Sigstore ו-in-toto מאפשרים זאת, אך דורשים:

2. בדיקה אוטומטית של תלויות

כלים כמו OpenSSF Scorecard מנתחים פרויקטים בקוד פתוח בחיפוש אחר סיכונים (למשל: היעדר MFA, commits ללא חתימה). אך הבדיקה חייבת להיות פרואקטיבית ורציפה:

3. צמצום משטח ההתקפה

פחות תלויות = פחות סיכון. אסטרטגיות:

מה יכולות לעשות חברות קטנות ובינוניות באמריקה הלטינית כבר היום (ללא תקציב אינסופי)

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

1. יישום SBOM בסיסי

כלים חינמיים כמו syft יוצרים SBOMs בפורמט SPDX או CycloneDX. שלבים:

  1. הרץ syft scan dir:. -o spdx-json=sbom.json בספריית הפרויקט.
  2. העלה את ה-SBOM למאגר פרטי (למשל: GitHub/GitLab).
  3. הגדר התראות לשינויים בתלויות (באמצעות Dependency-Track או Trivy).

2. הפעלת MFA וחתימות בכל המאגרים

GitHub ו-GitLab מאפשרים הגדרת מדיניות אבטחה:

3. ניטור תלויות קריטיות

זהה את 5-10 התלויות הקריטיות ביותר של הפרויקט ו:

4. הכשרת מפתחים לדיוג

החוליה האנושית עדיין החלשה ביותר. אימונים מעשיים:

העתיד: אוטומציה או קריסה?

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

1. בינה מלאכותית לזיהוי אנומליות

כלים כמו CodeQL או Semgrep יכולים לנתח דפוסי קוד חשודים (למשל: שינויים בקבצי תצורה, הזרקת תלויות נסתרות). אך הם דורשים:

2. בלוקצ'יין למעקב

פרויקטים כמו Hyperledger Fabric מאפשרים לרשום כל שינוי בשרשרת אספקה ב-ledger בלתי ניתן לשינוי. זה יכול לשמש ל:

האתגר הוא האימוץ: זה ידרוש שכל המתחזקים ירשמו את השינויים שלהם בבלוקצ'יין.

3. מודלים של אחריות משותפת

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

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

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

מקורות

  1. CISA. (2023). Securing the Software Supply Chain: Recommended Practices Guide for Developers. CISA SBOM. https://www.cisa.gov/resources-tools/resources/securing-software-supply-chain-developers
  2. Linux Foundation. (2024). XZ Utils Backdoor: CVE-2024-3094 Incident Report. https://www.openwall.com/lists/oss-security/2024/03/29/4
  3. Sonatype. (2023). State of the Software Supply Chain Report. https://www.sonatype.com/resources/state-of-the-software-supply-chain-2023
  4. Sigstore. (2023). Sigstore Documentation: How It Works. https://docs.sigstore.dev/
  5. in-toto. (2023). in-toto: A Framework to Secure the Integrity of Software Supply Chains. https://in-toto.io/
  6. GitHub. (2021). Incident Report: Compromised npm Package (ua-parser-js). https://github.blog/2021-10-22-npm-package-compromised/
  7. NPM. (2018). Security Incident: event-stream. https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident
  8. OpenSSF. (2023). Scorecard: Security Health Metrics for Open Source Projects. https://securityscorecards.dev/
  9. Torres-Arias et al. (2019). in-toto: Providing farm-to-table guarantees for bits and bytes. arXiv:1901.09206. https://arxiv.org/abs/1901.09206
  10. NIST. (2022). Software Supply Chain Security Guidance. NIST SP 800-218. https://csrc.nist.gov/publications/detail/sp/800-218/final