AI Supply Chain Security: איך מגנים על שרשרת האספקה של מודלים ונתונים

מאת צוות מדיה דיל · 04.08.2026 · Enterprise AI · 7 דק׳

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

הבעיה: מודל שהורדתם מ-Hugging Face הוא קוד שרץ בסביבה שלכם

צוותי פיתוח שמורידים מודל pretrained מ-Hugging Face או מ-registry ציבורי אחר נוטים להתייחס אליו כאל "קובץ נתונים" - סתם מספרים (weights) שנטענים לזיכרון. במציאות, פורמטים נפוצים כמו pickle (ששימש היסטורית לשמירת מודלי PyTorch) יכולים להכיל קוד הרצה שמתבצע אוטומטית בזמן הטעינה - מה שהופך "הורדת מודל" לפעולה שקולה, מבחינת סיכון, להרצת סקריפט לא מהימן שהורד מהאינטרנט. AI Supply Chain Security היא הדיסציפלינה שמתייחסת לכל שרשרת האספקה של נכסי AI - מודלים, datasets, ספריות, וכלי MLOps - באותה רצינות שמייחסים ל-supply chain security של תוכנה רגילה, עם ההבנה ש-2026 כבר הראתה מספר תקריות ממשיות של מודלים זדוניים שהופצו במאגרים ציבוריים.

מקרה מבחן: איך תקיפת supply chain אמיתית נראית בפועל

כדי להבין למה זה לא תיאורטי, שווה לפרק תרחיש ריאלי: קבוצת תקיפה מעלה למאגר ציבורי גרסה "מכווננת" (fine-tuned) של מודל פופולרי, עם שם ותיאור שמשדרים שיפור ביצועים למשימה ספציפית - נניח, "גרסה משופרת לניתוח מסמכים משפטיים בעברית". המודל אכן מבצע את המשימה היטב ברוב המקרים, מה שגורם לו לצבור הורדות וביקורות חיוביות. אבל כשקלט מסוים מופיע (למשל, מסמך שמכיל מספר תעודת זהות בפורמט מסוים), המודל "מדליף" את המידע הזה בפורמט מוסתר בתוך הפלט - טכניקה שנקראת steganographic exfiltration. צוות שמוריד את המודל הזה בגלל הביקורות החיוביות, בלי לבדוק את מקורו לעומק, עלול להטמיע ערוץ דליפת מידע פעיל בתוך מערכת הפרודקשן שלו בלי לדעת. זו בדיוק הסיבה שאמון המבוסס רק על "פופולריות" או "ביקורות" במאגר ציבורי אינו תחליף לתהליך אימות עצמאי.

ארבע חוליות השרשרת שדורשות בקרה נפרדת

Model Provenance

מאיפה הגיע המודל, מי אימן אותו, ואיזו שרשרת אימות (chain of custody) יש מרגע האימון ועד ההורדה שלכם. חתימה קריפטוגרפית של weights (בדומה ל-code signing) היא הפרקטיקה המתפתחת בתחום, אך עדיין לא סטנדרט אוניברסלי - מה שאומר שרוב הארגונים צריכים לבנות תהליך אימות ידני או חצי-אוטומטי בעצמם, לפחות לגבי מודלים בסיכון גבוה.

Dataset Provenance

מקור נתוני האימון, כולל שאלות רישוי (licensing) - האם הדאטה נאסף בהסכמה, האם יש בו תוכן מוגן זכויות יוצרים - ושאלות זיהום (contamination): האם דאטה זדוני הוזרק בכוונה למאגר ציבורי כדי "להרעיל" מודלים שיאומנו עליו בעתיד, טכניקה שמכונה data poisoning supply-chain attack.

Dependency ו-Framework Security

ספריות ה-ML (PyTorch, TensorFlow, transformers, LangChain, וכו') הן קוד רגיל עם פגיעויות רגילות, ודורשות אותו תהליך dependency scanning כמו כל קוד production אחר - אבל בפועל צוותי data science רבים לא מריצים scanning סדיר על ה-stack שלהם, כי הם רואים בעצמם "צוות מחקר" ולא "צוות תוכנה".

MLOps Pipeline Integrity

שרשרת הכלים שמריצה training, fine-tuning, ו-deployment - CI/CD ייעודי ל-ML - צריכה את אותה רמת הגנה כמו כל pipeline production אחר: הרשאות מוגבלות, חתימת artifacts, ובקרת גישה ל-credentials שמשמשים להעלאת מודלים לפרודקשן.

MCP כחוליית שרשרת אספקה חדשה

עם אימוץ MCP, שרשרת האספקה מתרחבת מעבר למודלים ולדאטה - עכשיו גם MCP servers עצמם, שנכתבים לעיתים על ידי צדדים שלישיים ומופצים דרך registries קהילתיים, הם חוליה בשרשרת שדורשת אימות. MCP server הוא בעצם קוד שרץ, לרוב עם הרשאות משמעותיות (גישה לקבצים, API keys, יכולת ביצוע פעולות), ואימוצו בלי בדיקה שקולה להתקנת חבילת npm לא מאומתת עם הרשאות מערכת נרחבות. הסיכון מחריף כי, בשונה מחבילת קוד רגילה שנבדקת ב-code review לפני שילוב, MCP server רבים "מתחברים" ל-agent באופן דינמי בזמן ריצה, לעיתים בלי תהליך בדיקה פורמלי כלל. נושא זה מפורט יותר במאמרים הייעודיים על ארכיטקטורת אבטחת MCP ועל רישום ארגוני של MCP servers מאושרים.

AI-BOM: הרחבת SBOM לעולם ה-AI

בדיוק כמו ש-SBOM (Software Bill of Materials) מתעד כל תלות בקוד תוכנה, AI-BOM מתעד כל רכיב בשרשרת האספקה של מערכת AI: המודל הבסיסי וגרסתו, כל dataset ששימש לאימון או fine-tuning, כל ספריית תלות עם גרסתה, וה-checksum/חתימה של כל artifact. AI-BOM עדכני מאפשר תגובה מהירה כשמתגלה פגיעות חדשה - למשל, אם מתגלה שגרסה מסוימת של ספריית inference פגיעה, שאילתה פשוטה על ה-AI-BOM עונה מיידית "אילו מערכות שלנו משתמשות בגרסה הזו", במקום סריקה ידנית של כל פרויקט.

{
  "component_type": "base_model",
  "name": "llama-3.1-70b",
  "source": "meta-llama/official-release",
  "checksum": "sha256:9f2a...",
  "signed": true,
  "license": "llama-3-community",
  "known_cves": [],
  "last_scanned": "2026-07-28"
}

איתור אנומליות אחרי הפריסה: Runtime Supply Chain Monitoring

בדיקה חד-פעמית בזמן הכנסת מודל למערכת לא מספיקה, כי חלק מהתקיפות מתגלות רק בהתנהגות לאורך זמן. ניטור runtime שמשווה את דפוסי הפלט של המודל מול baseline צפוי - למשל, האם יש עלייה חריגה בשיעור התגובות שמכילות תבניות טקסט מסוימות, או האם יש דפוס עקבי של תגובה שונה לקלט עם מאפיין ספציפי - יכול לחשוף backdoor או התנהגות זדונית שנשתלה בשרשרת האספקה הרבה אחרי שהמודל כבר "עבר" את בדיקת האימות הראשונית. זה מחבר את נושא ה-supply chain בחזרה ל-AI-SPM כתהליך מתמשך: אימות בכניסה חשוב, אבל בלי ניטור מתמשך אחריו, תקיפה עדינה שמופעלת רק בתנאים ספציפיים עלולה לפעול חודשים לפני שמישהו שם לב.

Trade-offs: מודלים פתוחים מול קנייניים, ומהירות מול אימות

מודלים open-weight מציעים שקיפות (ניתן לבדוק את הארכיטקטורה) אך גם משטח תקיפה גדול יותר (כל אחד יכול להעלות "מודל מותאם" זדוני למאגר ציבורי בשם מטעה). מודלים קנייניים דרך API מספק מוכר מצמצמים סיכון supply-chain ישיר (אתם לא מורידים weights בכלל) אך יוצרים תלות מלאה בביטחון התפעולי של הספק ופחות שקיפות. ההחלטה בין השניים היא לא רק שאלת עלות אלא שאלת מודל איום: ארגון עם רגישות רגולטורית גבוהה עשוי להעדיף בקרה מלאה (self-hosted, אך עם overhead אימות משמעותי), בעוד ארגון שממהר לשוק עשוי להעדיף להסתמך על ביטחון הספק ולהתמקד באימות ברמת האפליקציה.

טעויות נפוצות בפרודקשן

הטעות הראשונה: להוריד מודלים מ-Hugging Face או מאגרים דומים בלי scanning כלשהו - יש כלים ייעודיים (Protect AI, JFrog, ואחרים) שסורקים artifacts של מודלים לאיתור קוד זדוני מוטמע, ורוב הארגונים פשוט לא מפעילים אותם. הטעות השנייה: להתייחס ל-fine-tuning כתהליך "פנימי בטוח" ולהזניח את בדיקת מקור הדאטה ששימש לכיוונון - dataset מזוהם יכול להשתיל התנהגות זדונית שרק מופעלת בתנאים ספציפיים (trigger-based backdoor), מה שהופך אותה לקשה מאוד לזיהוי בבדיקת evaluation רגילה. הטעות השלישית: לא לתחזק AI-BOM כלל, כך שכשמתגלה חולשה בספרייה או במודל מסוים, אין דרך מהירה לדעת אילו מערכות בארגון נחשפות.

Backdoored Models: כשהמודל עצמו נראה תקין אבל מסתיר התנהגות טריגר

אחת הצורות המתוחכמות ביותר של תקיפת supply chain ל-AI היא הטמעת "דלת אחורית" (backdoor) במודל עצמו במהלך אימון - התנהגות זדונית שמופעלת רק כשקלט מסוים, ייחודי ומוסכם מראש, מופיע (trigger phrase). מודל כזה עובר evaluation רגיל בהצלחה מלאה, כי ה-trigger כמעט אף פעם לא מופיע בבדיקות סטנדרטיות, ורק כשהוא מגיע לפרודקשן ומישהו (בדרך כלל התוקף שהטמיע את ה-backdoor מלכתחילה) שולח את ה-trigger, ההתנהגות הזדונית מתגלה. הגנה מפני זה קשה מבחינה טכנית - אין דרך אמינה לחלוטין "לסרוק" מודל ולזהות backdoor נסתר - אבל אפשר לצמצם סיכון דרך שילוב של: העדפת מודלים ממקורות מאומתים עם רקורד ידוע, בדיקת red team שכוללת ניסיונות חיפוש אחר טריגרים חשודים (fuzzing על מרחב קלט רחב), והגבלת ההרשאות של כל מודל כך שגם אם backdoor מופעל, הנזק הפוטנציאלי מוגבל (defense in depth, לא רק אמון במודל עצמו).

ניהול גרסאות ו-Pinning: למה "תמיד השתמש בגרסה האחרונה" מסוכן

בעולם התוכנה הרגיל, יש קונצנזוס רחב ש-pinning גרסאות (נעילת גרסה ספציפית ומאומתת, במקום "always latest") הוא פרקטיקת אבטחה בסיסית. בעולם ה-AI, זה עדיין לא נהוג מספיק: צוותים רבים מגדירים pipeline שמושך את הגרסה העדכנית ביותר של מודל או dataset מ-registry ציבורי בכל ריצה, מה שאומר שאם גרסה חדשה מכילה קוד זדוני או שינוי מזיק, הוא נכנס אוטומטית לסביבת הפרודקשן בלי שלב אימות ביניים. הפרקטיקה הנכונה מקבילה למה שקורה בניהול תלויות תוכנה: נעילת גרסה ספציפית שעברה אימות ידני, ותהליך מבוקר ומודע לעדכון לגרסה חדשה - כולל re-scan של ה-artifact החדש - ולא משיכה אוטומטית שקטה.

מתי כן ומתי לא

לכל ארגון שמשתמש במודלים open-source או open-weight, בדיקת supply chain בסיסית (סריקת artifacts, אימות checksum) היא חובה מינימלית ולא אופציונלית. עבור ארגונים שמסתמכים אך ורק על API של ספקים מוכרים וגדולים, הסיכון הישיר נמוך יותר, אך עדיין נדרשת בקרה על שכבת ה-dependencies (ספריות client, SDKs) ועל תהליך ה-MLOps הפנימי.

איך אנחנו ניגשים לזה

אנחנו במדיה דיל בונים AI-BOM כחלק מכל פרויקט שמשלב מודלים open-weight, כולל סריקת artifacts לפני טעינה לסביבת פיתוח, כדי שרכיב זדוני שהוטמע במאגר ציבורי לא יגיע בכלל לסביבת הלקוח.

תפקיד Legal ו-Licensing בבדיקת שרשרת האספקה

היבט שצוותי אבטחה טכניים נוטים להזניח: בדיקת supply chain כוללת גם שאלות רישוי משפטיות, לא רק טכניות. מודל שהותאם (fine-tuned) על דאטה שנאסף בהפרת זכויות יוצרים, או שהרישיון שלו אוסר שימוש מסחרי, יוצר חשיפה משפטית לארגון שמשתמש בו בפרודקשן - גם אם המודל עצמו "נקי" מבחינה אבטחתית. תהליך אימות שרשרת אספקה בשל כולל שלב סינון רישוי (license compliance check) לצד סריקת האבטחה הטכנית, ומעורבות של צוות המשפט הארגוני בקביעת אילו רישיונות מקובלים לשימוש. זה נכון במיוחד עבור מודלים ודאטהסטים עם רישיונות "community" או "research only", שקל לפספס את המגבלות שלהם כשמתמקדים רק בהיבט הטכני.

סיכום

AI Supply Chain Security מרחיבה עקרונות אבטחת שרשרת אספקה מוכרים - חתימה, אימות מקור, סריקת תלויות - לעולם שבו "תלות" יכולה להיות מודל, dataset, או pipeline שלם, לא רק חבילת קוד. הארכיטקטורה הנכונה כוללת AI-BOM חי, סריקת artifacts לפני טעינה, ובקרה נפרדת על כל אחת מארבע חוליות השרשרת - מודל, דאטה, dependencies, ו-pipeline עצמו.

תגיות: AI Supply Chain Security · AI-BOM · model provenance · Hugging Face security · data poisoning · SBOM · MLOps security

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