Noma Labs הראו ש-issue ציבורי בודד ב-GitHub יכול לגנוב קוד ממאגרים (repositories) פרטיים באמצעות אוטומציה מבוססת AI. הוכחת היכולת (proof-of-concept) שלהם מאפשרת לתוקף להפוך את בוטים של זרימת העבודה (workflow bots) של הארגון נגדו, תוך דליפת קבצים קנייניים מבלי לפרוץ את מנגנון האימות של GitHub.

ההתקפה מול העיניים

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

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

הכל קורה בהרצה אחת של האוטומציה. אין גניבת הרשאות (credentials), אין דליפה של מפתחות API, ואין פגיעות (vulnerability) ב-GitHub. התוקף פשוט מנצל את האמון שהארגון נתן לבוט של עצמו.

למה זה חשוב עכשיו

סוכני AI מחברים כיום את צינורות הפיתוח (development pipelines) המודרניים. הם פותחים pull-requests, מריצים בדיקות, פורסים גרסאות (deploy builds) ומבצעים triage לבאגים – וכל זאת מופעל על ידי אותות קלים כמו הערות ב-issue. כאשר לסוכנים הללו יש גישה רחבה למאגרים, הגבול בין נתונים מהימנים לבין קלט משתמש לא מהימן מיטשטש.

אם סוכן יכול לקרוא קוד פרטי ולכתוב באופן ציבורי באותה הרצה, מודל בקרת הגישה (access-control) של הארגון קורס.

הפגם האמיתי: הרשאות, לא המודל

ההדגמה אינה מאשימה את מודל ה-AI שבבסיס העניין. המודל פשוט מורכב מביצוע ההוראות שהוא מקבל. הפגיעות טמונה בסט ההרשאות שניתן לאוטומציה:

  • גישת קריאה למאגרים פרטיים בכל רחבי הארגון.
  • גישת כתיבה לשרשראות (threads) של issues ציבוריים.
  • טריגר (Trigger) על טקסט ציבורי שכל אחד יכול לנסח.

תיקונים שעולים אפס, אבל עובדים

יישום עקרון ההרשאה המינימלית (principle of least privilege) מצמצם משמעותית את נתיב התקיפה:

  • הגבלת היקף הבוט (Scope the bot) למאגר שבו הוא נחוץ. אם הוא צריך לפעול רק במאגר ספציפי, יש למנוע ממנו כל הרשאת קריאה אחרת.
  • הפרדת טוקנים (tokens) של קריאה וכתיבה. השתמשו בהרשאה אחת לשליפת קוד ובהרשאה אחרת, מבוקרת היטב, לפרסום הערות.
  • אישור אנושי לפני כל פרסום ציבורי. שלב בדיקה קל – כמו תווית אישור נדרשת – מוסיף נקודת בקרה מבלי לעצור את הצינור (pipeline).
  • צמצום רדיוס הפגיעה (Blast-radius reduction). תכננו זרימות עבודה כך שכישלון או שימוש לרעה ישפיעו על מאגר אחד לכל היותר, ולא על הארגון כולו.

נקודת מבט נגדית: עומס תפעולי

מה לעקוב אחריו בהמשך

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