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

מאת צוות מדיה דיל · 04.07.2026 · אבטחת מידע · 5 דק׳

SBOM, Dependency Confusion, תלויות טרנזיטיביות, Typosquatting, Lockfiles וחתימת Sigstore, ואבטחת CI/CD Pipeline.

אפליקציה טיפוסית מורכבת מאלפי חבילות תלויות - ישירות ועקיפות - וברוב הפרויקטים המודרניים הקוד שכתב הצוות בפועל הוא אחוז בודד מסך הקוד שרץ ב-production. כל חבילה כזו היא נקודת כניסה פוטנציאלית: אם מתחזק אחד מתוך אלפי תלויות טרנזיטיביות נפרץ, או פשוט מכניס שורת קוד זדונית במכוון, הקוד הזה רץ בהרשאות מלאות בתוך המערכת שלכם בלי שאף אחד סקר אותו. Supply Chain Security הוא תחום שלם שמתמקד בזה בדיוק - לא בפגיעויות שאתם כתבתם, אלא בסיכון שאתם יורשים.

SBOM - הרשימה שרוב הארגונים לא מחזיקים

Software Bill of Materials הוא מסמך מובנה (בפורמט כמו SPDX או CycloneDX) שמפרט כל רכיב תוכנה בפרויקט - שם, גרסה מדויקת, רישיון, ומקור. בלי SBOM, כשמתגלה חולשה קריטית כמו Log4Shell, השאלה "האם אנחנו חשופים" הופכת לחיפוש ידני ומתיש בעשרות repositories. עם SBOM מעודכן אוטומטית בכל build, התשובה היא שאילתה של שניות. רגולציה בתחומים כמו פיננסים וממשל כבר מחייבת SBOM כתנאי סף, וזה כיוון שרוב האקוסיסטם התעשייתי הולך אליו.

Dependency Confusion - כשהחבילה הפרטית שלכם נגנבת בשם

ארגונים רבים משתמשים בחבילות פנימיות עם שמות כמו company-internal-utils שמתארחות ברג'יסטרי פרטי. אם תוקף מפרסם חבילה ציבורית באותו שם עם מספר גרסה גבוה יותר, package manager שלא מוגדר נכון עלול למשוך את הגרסה ה"עדכנית יותר" מהרג'יסטרי הציבורי במקום מהפרטי - וכך קוד זדוני נכנס ישירות ל-build. ההתקפה הזו נמנעת על ידי scoping מפורש של חבילות פנימיות והגדרת registry priority נכונה בקובצי התצורה.

תלויות טרנזיטיביות - הסיכון שלא רואים ישירות

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

Typosquatting - כשהשם הקרוב מספיק כדי לרמות

תוקפים מפרסמים חבילות עם שמות דומים מאוד לחבילות פופולריות - כמו reqeusts במקום requests - בהימור שמפתח יטעה בהקלדה או יעתיק שם שגוי מקוד לא מהימן. ברגע שהחבילה מותקנת, קוד ה-install script שלה (postinstall hooks ב-npm, למשל) יכול לרוץ מיידית ולגנוב סודות סביבה, מפתחות SSH או טוקנים של CI/CD, עוד לפני שהמפתח בכלל השתמש בפונקציה כלשהי מהחבילה.

Lockfiles, Pinning וחתימה קריפטוגרפית

הגנה בסיסית אך קריטית היא נעילת גרסאות מדויקות דרך lockfile (package-lock.json, poetry.lock) כדי שכל build יקבל בדיוק אותו קוד, כולל hash קריפטוגרפי לכל חבילה. מעבר לזה, כלים כמו Sigstore מאפשרים חתימה קריפטוגרפית שקופה על artifacts, כך שאפשר לוודא שחבילה אכן פורסמה על ידי המתחזק המוצהר שלה ולא הוחלפה בדרך. יחד עם סריקת פגיעויות אוטומטית (Snyk, Dependabot) בכל pull request, זו שכבת ההגנה המעשית ביותר נגד רוב וקטורי ה-supply chain.

CI/CD כנקודת הכניסה הכי שווה לתוקף

תוקף חכם לא תמיד יתקוף production ישירות - הוא יתקוף את ה-pipeline שבונה אותו. גישה ל-runner של CI/CD עם secrets מוזרקים לתהליך build פירושה גישה למפתחות deployment, טוקני registry, ולפעמים אפילו למפתחות חתימת קוד. הגנה על השרשרת הזו דורשת ניהול סודות קפדני בתוך pipelines וגם היגיינה סביב סריקת images שנבנים בתוכם, כדי שלא יזלגו החוצה בלוגים או ב-build artifacts שנשארים נגישים.

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

תגיות: Supply Chain Security · SBOM · Dependency Confusion · Typosquatting · npm · Sigstore

← חזרה לבלוג · צור קשר