שרשרת אספקת ה-AI שלכם היא סיכון האבטחה הגדול ביותר שאינכם מנהלים

הבעיה

בפברואר 2024, חוקרי אבטחה מחברת JFrog גילו יותר מ-100 מודלי בינה מלאכותית זדוניים ב-Hugging Face, אחד המאגרים הציבוריים הפופולריים ביותר ללמידת מכונה. מודלים אלה לא היו סתם פגומים. הם היו מחומשים (weaponized). כאשר מפתח הוריד מודל כזה וטען אותו באמצעות פקודה סטנדרטית, המודל פתח בחשאי דלת אחורית — reverse shell — לשרת מרוחק. התוקף השיג באופן מיידי גישה למערכת של אותו מפתח.

מודל ספציפי אחד, שהועלה על ידי משתמש בשם "baller423", השתמש בפורמט קבצים נפוץ בשם pickle כדי להזריק קוד במהלך תהליך הטעינה. ברגע שמדען נתונים הריץ את פקודת torch.load() הסטנדרטית, קוד זדוני הופעל אוטומטית. הוא התחבר לכתובת IP השייכת ל-Korea Research Environment Open Network.

אין מדובר בסיכון תאורטי. זה קורה ממש עכשיו בפלטפורמות שהצוותים שלכם ככל הנראה משתמשים בהן מדי יום. אם הארגון שלכם מושך מודלי בינה מלאכותית ממקורות ציבוריים — ורובם עושים זאת — אתם מייבאים קבצים בינאריים שאף אדם אינו יכול לקרוא או לבדוק בעין בלתי מזוינת. בניגוד לקוד תוכנה מסורתי, משקולות של מודלי בינה מלאכותית הן מבנים אטומים (opaque). התנהגות זדונית מסתתרת בתוך מיליוני פרמטרים מספריים. תהליכי סקירת הקוד הקיימים שלכם פשוט אינם מסוגלים לזהות זאת. שרשרת אספקת ה-AI היא כעת החלק הפגיע ביותר ובעל המשילות הנמוכה ביותר במערך הטכנולוגי שלכם.

מדוע זה חשוב לעסק שלכם

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

• ל-83% מהארגונים חסרות בקרות אבטחת AI אוטומטיות. רק ל-17% יש מנגנוני הגנה אוטומטיים כלשהם. השאר, בניסוחם של החוקרים, "פועלים בעיוורון".
• בינה מלאכותית בצל (Shadow AI) — שימוש לא מורשה בכלי AI על ידי עובדים — מהווה 90% משימוש ה-AI בארגונים. סביר להניח שצוותי ה-IT והאבטחה שלכם אינם רואים את רוב פעילות ה-AI בארגון שלכם כרגע.
• תקריות שבהן מעורבים כלי AI שלא נבדקו מגדילות את עלות דליפת הנתונים ב-670,000 דולר בממוצע. זוהי הפרמיה שאתם משלמים על אימוץ AI ללא משילות.
• רק 12% מהארגונים יישמו משילות בינה מלאכותית עם בקרות טכניות אמיתיות. 56% נוספים טוענים שהם "מוכנים", אך חסרים להם מנגנוני האכיפה לגבות זאת.
• ל-86% מהארגונים אין נראות לגבי האופן שבו AI מעביר נתונים באופן פנימי. אם אינכם יכולים לראות את זרימות הנתונים, אינכם יכולים להגן עליהן או להוכיח עמידה ברגולציה (compliance).

עבור הדירקטוריון והרגולטורים שלכם, השאלה פשוטה. האם אתם יכולים להציג למבקר בדיוק אילו מודלי בינה מלאכותית פועלים בסביבה שלכם, מהיכן הם הגיעו ובאילו נתונים הם נוגעים? אם אינכם יכולים, אתם עומדים בפני פערי ציות תחת מסגרות מתפתחות כמו NIST AI 100-2. אתם עומדים גם בפני נזק תדמיתי של פריצה שלא ראיתם מגיעה — מכיוון שווקטור התקיפה היה מודל AI שאיש לא בדק.

מה שקורה בפועל מתחת למכסה המנוע

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

תופעה זו נקראת הרעלת נתונים (data poisoning), והמתמטיקה שמאחוריה מדאיגה. חוקרים מ-Anthropic ומצוות ה-AI Red Team של NVIDIA הראו כי הרעלה של 0.00016% בלבד מנתוני האימון — כ-250 מסמכים מתוך מערך נתונים ענקי — פוגעת לצמיתות במודל בעל 13 מיליארד פרמטרים. ברגע שהנתונים המורעלים הוטמעו בתוך משקולות המודל, הוספת נתונים נקיים נוספים אינה מתקנת זאת. הדלת האחורית נשארת לצמיתות.

מודלים מורעלים אלה פועלים כ"סוכנים רדומים" (sleeper agents). הם עוברים כל מבחן ומדד ביצועים (benchmark) סטנדרטיים. הם מתנהגים באופן רגיל בסביבת ה-QA שלכם. אך כאשר הם נתקלים בטריגר ספציפי — מחרוזת טקסט ייחודית, תבנית תמונה מסוימת, או אפילו מניפולציית קלט ברמת הביט — המודל עובר למצב הזדוני שלו. משמעות הדבר עשויה להיות עקיפת אימות, הדלפת נתונים רגישים או יצירת קוד מזיק שהמערכות במורד הזרם שלכם מריצות באופן אוטומטי.

הסכנה חורגת מעבר למודלים עצמם. אפילו סורקי האבטחה שנועדו להגן עליכם נכשלים. חברת JFrog מצאה שלוש פגיעויות יום-אפס (zero-day) ב-PickleScan, כלי נפוץ לבדיקת מודלי AI. תוקפים יכלו לתמרן סיומות קבצים כדי לגרום למודל שנפרץ להיראות "בטוח". מחקרים מראים שעד 96% מהתרעות הסורקים כיום הן התרעות שווא (false positives), מה שגורם להקהיית חושים של צוות האבטחה שלכם בפני איומים אמיתיים.

מה עובד (ומה לא)

נתחיל בשלוש גישות נפוצות שאינן מספקות את הסחורה:

• הסתמכות על ציוני אמון של מאגרים ציבוריים. Hugging Face אינה ספקית תוכנה שנבדקה ואושרה. יותר מ-100 המודלים הזדוניים שנמצאו שם מוכיחים שפופולריות וזמינות אינן שוות ערך לבטיחות.
• כתיבת מדיניות משילות AI ללא אכיפה אוטומטית. מסמך מדיניות אינו מונע ממפתח להוריד מודל שלא נבדק ב-2 לפנות בוקר. ללא מחסומים טכניים, 77% מהעובדים ימשיכו להדביק נתונים קנייניים בתוך כלי בינה מלאכותית ציבוריים.
• הרצת סורקי קוד סטנדרטיים על קובצי מודל AI. לכלי ניתוח סטטיים מסורתיים חסר ההקשר הנדרש לבדיקת משקולות של מודלים. הם אינם יכולים לזהות דלתות אחוריות המוסתרות בפרמטרים מספריים או תבניות זדוניות המוטמעות במטא-נתונים של המודל.

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

1. קלט — צרו רשימת רכיבים ללמידת מכונה (ML-BOM). לפני שכל מודל נכנס לסביבה שלכם, הפיקו תיעוד חסין מפני חבלה של מקורו, נתוני האימון שלו, תלויות הפריימוורק שלו וחתימה קריפטוגרפית. חשבו על כך כעל מסמך שרשרת משמורת עבור כל תוצר בינה מלאכותית. תקנים כמו CycloneDX ו-SPDX 3.0 תומכים כעת בפרופילים ייעודיים ל-AI בדיוק למטרה זו. נוהגי מקוריות נתונים ויכולת מעקב שלכם מהווים כאן את הבסיס.

2. עיבוד — אכפו אימות קריפטוגרפי בזמן הטעינה. שרת ההיסק (inference server) שלכם — המערכת שמריצה מודלי בינה מלאכותית — צריך לכלול "Admission Controller" הבודק את החתימה הדיגיטלית של כל מודל מול מרשם מהימן לפני טעינתו לזיכרון. פירוש הדבר שרק מודלים שנחתמו באמצעות המפתחות של הארגון שלכם יוכלו לרוץ. השתמשו ברכיבי אבטחת חומרה (HSM) כדי לנהל מפתחות אלה. אסרו לחלוטין על השימוש בפורמט pickle לטובת SafeTensors, פורמט שאינו מאפשר קוד בר-ביצוע.

3. פלט — נטרו את התנהגות המודל באופן רציף בזמן ריצה. השוו את פלטי המודל מול קווי בסיס נקיים של תיקוף כדי לזהות סחף (drift) או אנומליות המאותתות על הפעלת דלת אחורית. החילו שכבות חיטוי קלט (input sanitization) שמנסחות מחדש שאילתות לפני שהן מגיעות למודל, ובכך משבשות מטעני טריגר (payloads) שתוכננו בקפידה. הגבילו את קצב השאילתות (rate-limit) כדי למנוע מתקפות חילוץ מודל (model extraction).

יתרון שובל הביקורת (audit trail) הוא מה שהופך גישה זו לבעלת ערך רב עבור צוות הציות שלכם. לכל מודל יש ML-BOM חתום. לכל פריסה יש שרשרת חתימות מאומתת. לכל היסק יש פלטים מנוטרים. כאשר הרגולטור או המבקר שלכם שואל "כיצד אתם יודעים שמודל ה-AI הזה בטוח?", תוכלו להצביע על הוכחה קריפטוגרפית — ולא על מסמך מדיניות.

עבור ארגונים בתחום אבטחה וחוסן של בינה מלאכותית, הדבר אינו עוד בגדר רשות. ההתכנסות בין אבטחת בינה מלאכותית לאבטחת שרשרת אספקת תוכנה פירושה שההגנות הקיימות בצינור ה-CI/CD שלכם חייבות להתרחב כדי לכסות תוצרי מודלים. אם המודל שלכם מאובטח אך ספריית ה-Python המריצה אותו פרוצה, המערכת שלכם עדיין חשופה לפריצה. גישה אחודה ל הערכת אבטחה והקשחה בכלל נכסי התוכנה וה-AI היא הדרך היחידה לסגור פער זה.

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