ניתן להשתלט על GitHub Actions מבוססי AI באמצעות תגובה (comment) אחת בלבד, מה שמוביל לדליפת מפתחות API, טוקנים של ענן וסודות אחרים. חוקר אבטחה חשף 22 מאגרי קוד פתוח (open-source repositories) שבהם שילוב של טריגר ציבורי, כלי AI המופעל עם דגל "skip prompts", וסודות חשופים יוצרים נתיב ישיר להוצאת נתונים (exfiltration).
כיצד הפגיעות עובדת
פרויקטים מטמיעים כיום סוכני AI — כמו Claude Code, ה-GitHub Copilot CLI וכלים דומים — ישירות בתוך צינורות CI (CI pipelines). שלב ב-workflow מריץ פקודת shell ולעיתים קרובות מוסיף דגל שאומר לכלי להתעלם מבקשות הרשאה אינטראקטיביות. כאשר ה-workflow מתחיל בעקבות קלט ציבורי כלשהו — issue, תגובה, או כותרת של pull-request — התוקף צריך רק לפרסם שורת טקסט שה-AI יתייחס אליה כפקודה.
ה-AI, שכבר קיבל גישת shell ללא הגבלות בשל דגל ה-"skip prompts", קורא כל משתנה סביבה או קובץ שה-workflow חושף. אם ה-job טוען גם סודות — מפתחות API, טוקנים של שירותי ענן, או אישורי חשבון שירות (service-account) מלאים — ה-AI מעביר (pipes) את הערכים הללו לשרת שנשלט על ידי התוקף. ללא שינוי קוד, ללא תלות (dependency) חדשה, רק תגובה שנראית תמימה לחלוטין.
דוגמאות מהעולם האמיתי
החוקר אימת שלושה מאגרים פגיעים שכבר תוקנו:
- pymc-labs/pymc-marketing – issue ציבורי יכול היה לשמש להשגת מפתח Anthropic API באמצעות prompt injection.
- MadAppGang/dingo – ה-workflow העניק ל-Claude Code גישת Bash מלאה וחשף שני סודות באותו job.
- MadAppGang/claudish – השתמש באותה תבנית פגיעה כמו פרויקט dingo.
ממצא אחד כלל מפתח חשבון שירות ענן פעיל, אשר דווח ישירות לצוות האבטחה של ספק AI מרכזי. שנים-עשר דיווחים נוספים ממתינים לטיפול על ידי מנהלי הפרויקט (maintainers); שמותיהם נשמרים בסוד עד שהתיקונים יופעלו.
מה עומד על הפרק
כאשר תוקף מחלץ סוד, הנזק יכול להיות מיידי ויקר. מפתח חשבון שירות ענן מעניק גישה ללא הגבלות למשאבי מחשוב, storage buckets ושירותים בתשלום אחרים. מפתח API של ספק מודל שפה גדול (LLM) יכול להריץ שאילתות ללא הגבלה, מה שעלול לצבור חיובים של אלפי דולרים. מכיוון שהניצול (exploit) מתבצע בתוך סביבת ה-CI, הפריצה יכולה להתפשט למטה (downstream): כל artifact שנבנה על ה-runner שנפרץ עלול לשאת קוד זדוני, ובכך להפוך מאגר בודד לווקטור של שרשרת אספקה (supply-chain vector).
עבור צוותים המסתמכים על CI מבוסס AI, הפשרה היא חדה. יש לשקול את הנוחות של קוד שנוצר אוטומטית, linting או תיעוד מול הסיכון שתגובה ציבורית תהפוך לדלת אחורית חשאית.
מדוע קל לפספס את הפגיעות
החוקר הגיש בתחילה שישה דיווחים שנסוגו מאוחר יותר. הנסיגה נבעה מהנחות לגבי בדיקות ההרשאות של GitHub Actions, ולא מסקירה שורה-שורה של קוד המקור של ה-Action. תיעוד ואינטואיציה יכולים להטעות; הדרך האמינה היחידה לאמת את מצב האבטחה (security posture) של שלב מבוסס AI היא לבדוק את הקוד שמריץ את הכלי ואת קובץ ה-YAML של ה-workflow שמחבר ביניהם.
רשימת בדיקה לצמצום סיכונים (Mitigation checklist)
אם אתם מריצים CLI מבוסס AI או כלי דומה בתוך GitHub Actions workflow, ענו על שתי השאלות הללו לפני המיזוג (merging):
מי יכול להפעיל (trigger) את ה-workflow? הגבילו את הטריגרים לאירועים מהימנים (למשל, pushes לענפים מוגנים/protected branches) או דרשו אישור מפורש להרצות שמתחילות על ידי תורמים חיצוניים. הימנעו מ-
on: issue_commentאוon: issuesללא בקרות נוספות.אילו סודות נטענים באותו job? לעולם אל תחשפו מפתחות API, טוקנים של ענן או אישורי חשבון שירות ב-job שמריץ גם סוכן AI עם גישת shell ללא הגבלות. הפרידו שלבים הכוללים סודות רבים ל-jobs או runners מבודדים שאינם מפעילים כלי AI.
צעדי הקשחת אבטחה (hardening) נוספים:
- הסירו את הדגל שמדלג על בקשות הרשאה, ובכך תאלצו את כלי ה-AI לבקש אישור מפורש לפני ביצוע פקודות shell.
- הוסיפו שלב שמנקה (sanitizes) או מסתיר (redacts) כל משתנה סביבה שסוכן ה-AI עלול לקרוא.
- השתמשו ב-self-hosted runners עם בקרת יציאת רשת (network egress controls) כדי לחסום הוצאת נתונים לנקודות קצה שרירותיות.
נקודת מבט נגדית: התועלת של AI ב-CI
התומכים טוענים כי שיפור הפריון עולה על הסיכון. הצעות קוד אוטומטיות מקצרות את זמן הבדיקה, ובדיקות מונעות AI חושפות באגים מוקדם יותר. עם זאת, אותה נוחות מרחיבה את שטח התקיפה (attack surface). המפתח הוא לא לנטוש את ה-AI, אלא להתייחס לכל כלי בעל הרשאות ברמת shell כווקטור פוטנציאלי.
מה לעקוב אחריו בהמשך
הממצאים כבר עוררו דיונים בפורומי האבטחה של GitHub בנוגע להרשאות ברירת מחדל מחמירות יותר עבור Actions מבוססי AI. עדכוני פלטפורמה עתידיים עשויים לכלול:
- דגל (flag) שמאלץ כלי AI לפעול בסביבת sandbox ללא גישה ישירה ל-shell.
- זיהוי מובנה של דפוסי prompt-injection בגוף ה-issue או בתגובות.
- התראות אוטומטיות כאשר workflow מערבב טריגרים (triggers) ציבוריים עם משימות (jobs) המכילות סודות (secrets).
נכון לעכשיו, האחריות נותרת בידי מנהלי המאגרים (repository maintainers). 22 המאגרים שזוהו מראים שהבעיה אינה מבודדת; כל פרויקט שמשקף את אותו דפוס workflow הוא פגיע. ביקורת (audit) מהירה של הגדרות ה-CI יכולה לחשוף את הבעיה לפני שתוקף יעשה זאת.
בשורה התחתונה: שורה אחת של טקסט ב-issue ציבורי ב-GitHub יכולה להעניק לסוכן AI שליטה מלאה על סביבת ה-CI שלך ולגנוב את הסודות (secrets) שאתה שומר שם. ודא מי יכול להפעיל את ה-workflows שלך, הרחק סודות מצעדים מונעי AI, ובדוק בקפידה כל דגל (flag) המעניק הרשאות ללא בקרה. עלות הפריצה עולה בהרבה על המאמץ הנדרש לביקורת מסודרת.