כותרת: מפגש עם עוזר קוד מבוסס AI הפך לתקיפת שרשרת אספקה

מקרה הבוחן האחרון של Mandiant מראה שסשן (session) של עוזר קוד מבוסס AI שנחטף אפשר לתוקף להחדיר חבילה מורעלת (poisoned package) לבסיס הקוד של חברת תוכנה, תוך פגיעה ב-100 מאגרים (repositories) פנימיים, גניבת טוקנים (tokens) של GitHub OAuth והוצאת קוד מקור וסודות (secrets) החוצה. הפריצה מוכיחה שמפתחים אינם יכולים להתייחס להצעות שנוצרו על ידי AI כקוד בטוח.

מה קרה

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

החבילה המורעלת הורידה infostealer (תוכנה לגניבת מידע) שגבה טוקנים של GitHub OAuth שנשמרו בתחנת העבודה. באמצעות הטוקנים הללו, התוקף פרס את תולעת (worm) ה-"Shai-Hulud", שהעתיקה את עצמה ל-100 מאגרים פנימיים. מכיוון שהקוד הזדוני נשא את ה-namespace של החברה עצמה, מפתחים אחרים שמשכו מאוחר יותר את אותן החבילות נדבקו גם הם.

למה זה חשוב

עוזרי קוד מבוססי AI יכולים לקרוא קבצי פרויקט, ליצור פקודות התקנה, לערוך קובצי הגדרות תלות (dependency manifests) ואפילו להריץ פקודות טרמינל. טווח הגישה הזה הופך אותם לווקטורים אטרקטיביים לתקיפות שרשרת אספקה (supply-chain attacks). כאשר מפתח סומך על הצעה של AI יותר מאשר על עצה של אדם זר, עבודת התוקף הופכת לקלה יותר: העוזר יכול להחדיר בשקט קוד זדוני שנראה לגיטימי.

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

כיצד התקיפה התרחשה

  1. Session hijack – החטיפת סשן – התוקף השתלט על סשן פעיל של עוזר ה-AI.
  2. Poisoned recommendation – המלצה מורעלת – העוזר שנפרץ נאלץ להציע חבילה זדונית.
  3. Developer acceptance – קבלת ההצעה על ידי המפתח – מתוך אמונה בהמלצת ה-AI, המפתח הוסיף את החבילה והריץ את פקודת ההתקנה שנוצרה.
  4. Payload execution – הרצת ה-payload – החבילה התקינה infostealer שקרא טוקנים מקומיים של GitHub OAuth וסודות אחרים.
  5. Worm propagation – התפשטות התולעת – באמצעות הטוקנים הגנובים, התוקף פרס את תולעת ה-Shai-Hulud, שהתפשטה ל-100 מאגרים פנימיים.
  6. Exfiltration – הוצאת מידע – קוד מקור, ספריות פנימיות ומפתחות סודיים נשאבו לתשתית של התוקף.

מה מפתחים יכולים לעשות עכשיו

התייחסו לכל הצעה של AI כאל קוד שאינו מהימן. החילו את אותם שלבי אימות שבהם אתם משתמשים עבור כל תלות (dependency) של צד שלישי.

  • אימות החבילה

    • בדקו תיעוד רשמי והיסטוריית גרסאות.
    • אשרו את זהות המפרסם ואת המוניטין שלו.
    • סקרו את מאגר המקור (source repository) ו-commits אחרונים.
    • בדקו את עץ התלויות (dependency tree) המלא לאיתור קישורים בלתי צפויים.
    • בחנו בקפידה סקריפטים של התקנה לאיתור פקודות נסתרות.

  • הקשחת ניהול פרטי גישה (credentials)

    • העניקו את ההרשאות המינימליות האפשריות לכל טוקן.
    • העדיפו טוקנים בעלי תוקף קצר על פני טוקנים ארוכי טווח.
    • שמרו סודות של סביבת production מחוץ למכונות פיתוח מקומיות.
    • הגבילו הרחבות של עורכי קוד (editor extensions) מגישה להרשאות שהן אינן זקוקות להן.

  • תגובה לחשד לפריצה

    • בודדו את הסביבה שנפגעה באופן מיידי; מחיקת node_modules או תיקיות דומות אינה מספיקה.
    • בצעו rotation (החלפה) לכל ההרשאות ב-GitHub, npm, PyPI ובענן.
    • בצעו audit (ביקורת) לפעילות במאגרים לאיתור commits או מיזוגי pull-requests בלתי צפויים.
    • סקרו לוגים של CI/CD וסקריפטים של Git-hooks לאיתור התנהגות חריגה.

מבט לעתיד

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

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

שורה תחתונה: המלצה שנוצרה על ידי AI אינה אמינה יותר מכל קוד אחר של צד שלישי. אמתו, הגבילו ונטרו אותה בקפידה, או שתסתכנו בהפיכת עוזר מועיל למסלול לפריצה רחבת היקף בשרשרת האספקה.