חברת אבטחת היישומים Apiiro מתל אביב פרסמה ב‑ 6 בנובמבר מחקר על אישור שגרתי בסוכן התכנות של Anthropic. כאשר Claude Code מבקש רשות להריץ פקודה והמפתח עונה “Yes, and don’t ask again”, הכלי עשוי לשמור את הפקודה כפי שהיא, כולל סיסמה או מפתח שבתוכה, בקובץ ההגדרות settings.local.json שבתיקיית ה‑ .claude של הפרויקט. החוקרים איתרו ב‑ GitHub הציבורי 104,185 עותקים של הקובץ. ב‑ 1,122 מהם, כ‑ 1.1%, נמצא לפחות סוד אחד.
רוב הסודות שייכים למפתחים פרטיים, אבל בין הבעלים יש גם 63 ארגונים: קבוצות סטודנטים, סטארט‑אפים, בתי תוכנה וגם ספקים ותיקים. בין המקרים: סיסמת Postgres של סטארט‑אפ תשלומים וטוקן ייצור של Square אצל בית תוכנה. ארגון אחד אישר לחוקרי הסייבר שהמפתח שלו היה פעיל.
איך נכנסת סיסמה לקובץ הגדרות
כלל ההרשאה שהכלי שומר הוא מחרוזת. אם המחרוזת היא תבנית רחבה, שמאשרת כל פקודה שמתחילה במילה מסוימת, אין בה סוד. אם היא פקודה מלאה, למשל התחברות למסד נתונים עם שם משתמש, סיסמה וכתובת שרת, כל מה שהופיע בשורה נשמר בקובץ בטקסט גלוי. הוא נשאר שם עד שמישהו מוחק את הכלל.
לפי Apiiro, הפקודה שהכלי מציע כוללת לא פעם סוד שנשלף מקובץ התצורה, כך שהמפתח לא בהכרח הקליד אותו. אחרי כמה שאלות כאלו בכל סשן, לדברי החוקרים, רוב המפתחים כבר מאשרים בלי לקרוא.
הגנה שנשארת במחשב אחד
כדי למנוע מהקובץ להגיע למאגר, הכלי מוסיף אותו, בפעם הראשונה שהוא כותב אותו במאגר git, לקובץ ההחרגות הגלובלי של git. זו הגדרה ברמת המשתמש. היא חלה על כל המאגרים, אך רק במחשב שבו נכתבה. היא אינה נכנסת לקוד עצמו, כך שאינה עוברת יחד איתו. לפי Apiiro, ההגנה אינה מכסה תיקייה שהפכה למאגר git אחרי שהקובץ כבר נכתב, קובץ שכבר הוכנס למאגר או עותק שהועתק למחשב אחר. התיעוד הרשמי מציין שמי שיצר את הקובץ ידנית, לפני שהכלי כתב אליו, צריך להוסיף אותו ל‑ .gitignore בעצמו.
יש גם מגבלה שנובעת מ‑ git עצמו: כללי החרגה אינם חלים על קובץ שכבר נמצא במעקב. לפי Apiiro, במצב כזה המשתמש אינו מקבל הודעה: האישור הבא נוסף לקובץ שבמעקב ועשוי להיכנס ל‑ commit הבא.
מחלוקת: מי הכניס את הקבצים למאגר
בוריס צ'רני, ראש Claude Code ב‑ Anthropic, הגיב למחקר בשורת תגובות ב‑ Hacker News ב‑ 7 בנובמבר. לדבריו, הכלי לא ניקה עד היום סודות ("יש לכך הרבה כלים טובים", כתב), אך הצוות בוחן כיצד למנוע את התופעה, בין השאר באמצעות זיהוי במצב העבודה האוטומטי (auto mode) וסריקת סודות בסיסית. מאחר שהכלי מחריג את הקובץ כשהוא יוצר אותו, כתב, הקבצים שנחשפו נוצרו ידנית והוכנסו למאגר ידנית. הוא המליץ להשתמש ב‑ auto mode, שלדבריו מופעל כברירת מחדל. את ההמלצה נימק במגבלה של תשומת הלב האנושית: אדם שנדרש לאשר פקודות רבות מתעייף, עד שבטעות הוא מאשר פקודה שלא היה צריך לאשר. לפי Apiiro, כשקורא העיר שאותה שמירה עלולה לקרות גם ב‑ auto mode, כשהכלי עוצר לשאול על פקודה רגישה, השיב צ'רני “good catch” וכתב שהוא חושב כיצד לשפר זאת. הוא גם המליץ להפעיל את סריקת הסודות של שירותי אחסון הקוד.
Apiiro מציגה תמונה אחרת. לדברי החוקרים, ההתנהגות שוחזרה גם עם Opus 5.5 ו‑ Fable 5.1, כלומר היא של הכלי ולא של מודל מסוים. ב‑ 539 מתוך 1,105 מאגרים עם סוד שנבדקו, את הקובץ שינה commit שבו Claude רשום כשותף לכתיבה. מתוך 16 סוכני תכנות שהתיעוד שלהם נבדק, רק לגבי Claude Code אושר שהוא שומר כברירת מחדל את הפקודה המלאה בקובץ בתוך הפרויקט. דיווח באג שהוגש ב‑ GitHub באוגוסט 2025 תיאר את אותה התנהגות. הוא נסגר בינואר 2026 בידי בוט, בסטטוס "לא מתוכנן", אחרי 60 יום ללא פעילות.
מה נחשף ולמה הסורקים פספסו
חלק מהסודות פותחים שרתים: 43 פרטי התחברות ב‑ SSH לשרתים ציבוריים, חלקם עם סיסמת root. יותר משליש מ‑ 1,379 הסודות השונים שבעותקים הציבוריים של הקובץ, 379 סיסמאות למסדי נתונים ו‑ 122 מפתחות שירות של Supabase, מיועדים לגישה ישירה למסד נתונים. בתוספת גרסאות קודמות של הקובץ, קובץ ההגדרות המשותף ותמלולי שיחות, הספירה מגיעה ל‑ 2,539 סודות ב‑ 1,994 מאגרים.
כלי סריקת הסודות הנפוצים מתבססים על כללים שמזהים את המבנה של מפתחות שספקים מנפיקים, כמו קידומת קבועה או מחרוזת אקראית. סיסמה בתוך שורת פקודה אינה עונה לרוב על התנאים האלו. לפי Apiiro, שני הכלים מפספסים אותה ברוב המקרים. מתוך 1,122 הקבצים, gitleaks סימן 564 ו‑ TruffleHog סימן 643. בכל אחד מ‑ 215 קבצים אף כלי לא התריע.
היסטוריה ציבורית של git אינה נמחקת: מי ששכפל או פיצל מאגר מחזיק עותק מלא שלה. 211 פיצולים (forks) של 74 מאגרים נושאים את אותם סודות. בגרסאות ישנות של הקובץ נמצאו עוד לפחות 734 סודות ב‑ 509 מאגרים, שאינם מופיעים באף עותק עדכני. במאגר החציוני מבין אלו שבהם נמצא סוד, הקובץ הוכנס לראשונה 217 ימים לפני 2 בנובמבר.
הסיכון לארגון שלכם
סוד ציבורי הוא סוד שדלף. החוקרים לא בדקו אם הסודות תקפים ולא השתמשו באף אחד מהם. אף מקור אינו מדווח על ניצול שלהם. כל אחד מהם עמד בשני תנאים. הראשון: הוא נראה כמו מפתח של ספק מוכר או הופיע לצד כתובת של שרת ציבורי. השני: סוקר AI אישר אותו. מרגע שקובץ כזה פומבי, אי אפשר לדעת מי העתיק אותו.
גם קובץ שלא הגיע ל‑ GitHub חשוף. הוא יכול לצאת מהארגון בלי git בכלל, בחבילת npm, בתמונת Docker, בארכיון zip או בתיקייה מסונכרנת. במחשב עצמו הוא קובץ טקסט שכל תהליך בהרשאות המשתמש קורא. נוזקות כבר אוספות פרטי גישה ממחשבי מפתחים: בספטמבר 2025 הריצה תולעת Shai‑Hulud את TruffleHog על קבצי הקורבנות.
הספק החיצוני הוא חלק מהתמונה. לא מעט ארגונים בישראל, גם כאלו שאינם חברות טכנולוגיה, נעזרים בבתי תוכנה ובמפתחים עצמאיים. סיסמת מסד הנתונים של ארגון כזה יכולה לשבת בקובץ הגדרות על המחשב או במאגר של הספק, בלי שהארגון יודע שהספק עובד עם סוכן AI. המחקר אינו מציין אם בין הסודות שנחשפו היו סודות של לקוחות.
הבעיה אינה של קובץ אחד. Apiiro מצאה סודות גם בהגדרות האישור האוטומטי של Copilot, בקובצי זיכרון של סוכנים, בתמלולי שיחות ובמסמכי העברה. המכנה המשותף, לפי Apiiro: סוד שהופיע בפקודה שסוכן תיעד. כלי AI לפיתוח הם גם יעד בפני עצמם, כפי שהראה המבזק שפורסם כאן לפני שבוע על גרסה זדונית של התוסף הרשמי של Claude Code.
010 הגנה על מידע
כדי שהחשיפה הזו תתרחש לא נדרש תוקף: היא נובעת מאישור רגיל בתהליך העבודה. אין שירות של 010 שמתקן את הכלי עצמו. ההמלצות הבאות עוסקות בהרגלי עבודה, במדיניות ובניטור.
מניעת דלף מידע (DLP). Apiiro ממליצה להתייחס לתיקיות הסוכנים (.claude/, .cursor/, .gemini/, .specstory/) כמו לקובצי .env. במחשבים שמותקן בהם רכיב DLP, אפשר להגדיר את הקבצים האלו כרגישים ולזהות יציאה שלהם בתיקייה מסונכרנת או בקובץ zip. סריקת סודות לפני כל commit ובצנרת ה‑ CI, כולל ההיסטוריה, היא כלי של צוות הפיתוח ולא DLP במובן הקלאסי. כדי שתועיל כאן, היא צריכה לזהות גם סיסמאות בתוך פקודות.
סקר סיכונים. בירור אילו סוכני תכנות פועלים בארגון ואצל מפתחים חיצוניים שעובדים על הקוד שלו, אילו מאגרים ציבוריים, האם הקובץ מופיע בהיסטוריה של מאגר גם אם נמחק, והאם settings.local.json נכלל בתבניות ה‑ .gitignore של הארגון.
מודעות עובדים לסייבר. ההדרכה כאן מיועדת למפתחים: לא לאשר לצמיתות פקודה שמופיע בה סוד גלוי, להפנות לסודות דרך משתנים ממנהל סודות במקום לכתוב אותם בפקודה. כדאי גם להעדיף אישור של תבנית פקודה על פני פקודה מדויקת.
SIEM/SOC. כאשר SOC מקבל את רישומי מסדי הנתונים ושירותי הענן יכול לחפש התחברויות עם פרטי הגישה שנחשפו ממקורות לא מוכרים. התנאי הוא שהרישומים נאספים ונשמרים מספיק זמן לאחור: בחציון, הקובץ הוכנס למאגר 217 ימים לפני 2 בנובמבר, כך שהחלון עשוי להיות ארוך. רק היומנים יכולים לגלות אם נעשה בסודות שימוש.
מודיעין סייבר. חיפוש יזום בקוד ציבורי אחר הדומיינים ושמות השרתים של הארגון יכול לחשוף קובץ כזה, בתנאי שהקובץ מכיל אותם. מפתח בלי שם שרת לא יעלה בחיפוש כזה.
עדכוני תוכנה ואבטחה. אף מקור אינו מדווח עד כה על עדכון שמשנה את ההתנהגות. לדברי צ'רני, הצוות יבחן כמה גישות. כדאי לעדכן את הכלי כשיתפרסם שינוי.
הגנה אקטיבית מכופרה, סינון דוא"ל וגיבוי והמשכיות עסקית אינם רלוונטיים כאן.
מה עושים עכשיו, לפי הסדר: בודקים את המאגרים כולל ההיסטוריה ואת העותקים המקומיים של הקובץ כדי לדעת מה נחשף. מחליפים כל סיסמה, טוקן ומפתח שהופיעו בו אי פעם. רק אחר כך מפסיקים את המעקב של git אחרי הקובץ (git rm –cached), מוסיפים אותו ל‑ .gitignore של הפרויקט ומוחקים מהעותקים המקומיים כל כלל שמכיל סוד.
למקור הידיעה ולקריאה נוספת לחצו כאן
