דיווח: אישור קבוע ב־Claude Code עלול לשמור סודות בקובץ הגדרות
לפי דיווח על מחקר Apiiro, אישור קבוע ב־Claude Code עלול לשמור פקודה עם סיסמה או מפתח בקובץ הגדרות. העלאת הקובץ למאגר GitHub ציבורי תחשוף אותם.

לחיצה על “Don't ask again” ב־Claude Code נועדה לחסוך אישורים חוזרים, אבל לפי דיווח על מחקר של Apiiro היא עלולה גם להשאיר סיסמה או מפתח בתוך קובץ הגדרות. אם הקובץ הזה נכנס בהמשך למאגר GitHub ציבורי, פעולה מקומית שנועדה לייעל את העבודה עלולה להפוך לחשיפת מידע רגיש. עבור צוותי פיתוח בישראל, המשמעות המעשית היא לבדוק לא רק את הקוד שהסוכן כתב, אלא גם את הקבצים שבהם נשמרים האישורים שניתנו לו.
מה דווח: הפקודה נשמרת, והסוד עלול להישמר איתה
לפי דיווח ב־RuntimeWire על מחקר שפרסמו שמוליק כהן ומתן גלעדי מ־Apiiro ב־5 בנובמבר 2026, המסלול מתחיל בפקודה הכוללת פרט רגיש. המשתמש מאשר אותה באמצעות האפשרות שלא לבקש שוב אישור, והפקודה עלולה להישמר בקובץ הגדרות. הסיכון מתממש כאשר אותו קובץ נכלל בשינויים המועלים למאגר ציבורי, בלי שהמשתמש מבחין שהמידע הרגיש נמצא בתוכו.
בסריקה המורחבת שעליה דווח, Apiiro מצאה 2,539 סודות ב־1,994 מאגרים. אלה נתונים שמצביעים על היקף הממצאים המדווחים, אך אינם מוכיחים שכל פרטי ההזדהות היו תקפים בזמן הבדיקה, או שנעשה בהם שימוש לרעה. גם אין להסיק מהם שכל לחיצה על האפשרות יוצרת דליפה: התרחיש תלוי בתוכן הפקודה, במה שנשמר ובמה שמתפרסם לבסוף.
גבולות האימות: עמוד המחקר המקורי של Apiiro לא נטען בבדיקת התחקיר, והכתבה נשענת על הדיווח המפנה אליו. אין בידינו אימות ישיר של שיטת הסריקה או של תוקף הסודות שנמצאו, ולכן הממצאים מובאים כאן בייחוס ולא כבדיקה עצמאית.
למה קובץ הרשאות צריך לעבור בדיקת אבטחה
ההבחנה החשובה היא בין הרשאה לבצע פעולה לבין החלטה לשמור את תוכנה. מפתח עשוי להבין היטב שהוא מאפשר לסוכן להריץ פקודה, ועדיין לא לצפות שהפרטים שהקליד יישארו בקובץ שילווה את הפרויקט. בתרחיש המתואר, הסוד אינו חייב להופיע בפונקציה או בקוד האפליקציה: הוא יכול להימצא דווקא במידע התפעולי שמאפשר לכלי לעבוד בנוחות.
מכאן נובע פער אפשרי בבדיקת שינויים. בודק קוד שמתרכז בלוגיקה העסקית, בבדיקות ובתלויות עלול להקדיש פחות תשומת לב לקובץ הגדרות שנראה שגרתי. אלא שההבחנה בין קוד לבין הגדרות אינה גבול אבטחה: אם קובץ מכיל פרט שמאפשר גישה לשירות, יש לבדוק אותו בהתאם לרגישות המידע, בלי קשר לשמו או לתפקידו בפרויקט.
אישור להריץ פקודה אינו אישור לפרסם את הסוד שבתוכה.
אין בתחקיר בסיס לקביעה ש־Claude Code מפרסם בעצמו את הסודות, או שמדובר בתקיפה שביצע גורם חיצוני. שרשרת הסיכון המדווחת מחברת בין שמירת פקודה לבין פרסום הקובץ בהמשך. זו הבחנה חשובה: הטיפול אינו מסתכם בבדיקה אם הסוכן כתב קוד בטוח, אלא כולל גם את תהליך האישור, שמירת ההגדרות ובקרת השינויים לפני העלאה למאגר.

המשמעות לצוותי פיתוח ולסטארטאפים בישראל
לסטארטאפ ישראלי שמפרסם SDK, דוגמאות אינטגרציה או פרויקט קוד פתוח, ההפרדה בין סביבת עבודה פנימית לבין תוצר ציבורי צריכה להיות מפורשת. לדוגמה, פקודה שנועדה לבדוק חיבור לשירות במסגרת הפיתוח עשויה לכלול מפתח שאינו אמור לצאת מהמחשב. זהו תרחיש המחשה, לא ממצא נוסף מהמחקר, אבל הוא מסביר מדוע גם פרויקט קטן מצריך בדיקה של הקבצים הנלווים.
גם עבודה עם פרילנסרים או עם צוותים של לקוחות מחייבת להגדיר מי אחראי להגדרות סוכן הקוד. אין צורך להניח שכל קובץ כזה מסוכן, אך כדאי לקבוע אילו הגדרות משותפות לכל הצוות ואילו חייבות להישאר מקומיות. עבור עסק בארץ שמפתח ללקוחות, בדיקת מסירה צריכה לכלול גם מידע רגיש בקובצי העזר, ולא רק אישור שהמוצר פועל.
הלקח הניהולי אינו בהכרח לאסור שימוש בסוכן, אלא להוסיף לו גבולות ברורים. מנהל פיתוח יכול לדרוש בדיקה של קובצי הרשאות חדשים; אחראי אבטחה יכול להגדיר סריקת סודות; והמפתח יכול להימנע מהכנסת סיסמה לפקודה שאמורה להישמר. חלוקת אחריות כזו עדיפה על הסתמכות בלעדית על תשומת הלב של אדם אחד ברגע האישור.
מה כדאי לבדוק עכשיו במאגרים
הדיווח מצדיק בדיקה ממוקדת, לא מסקנה שכל מאגר שבו נעשה שימוש ב־Claude Code נחשף. מומלץ להתחיל בפרויקטים ציבוריים ובפרויקטים שעומדים להתפרסם, ולבדוק אילו קובצי הגדרות נוספו במהלך העבודה עם הסוכן. ההמלצות הבאות הן אמצעי זהירות כלליים לניהול סודות, ולא הוראות תיקון מאומתות מטעם Apiiro או ספקית הכלי.
- בדקו את השינויים לפני commit, לרבות קובצי הגדרות והרשאות. חפשו פקודות שמכילות סיסמאות, מפתחות API או פרטי חיבור.
- העדיפו העברת סודות באמצעות מנגנון ניהול סודות מתאים, במקום להקליד אותם ישירות בשורת פקודה שעלולה להישמר. ודאו שגם פלט ולוגים אינם חושפים אותם.
- הגדירו במפורש אילו קבצים מקומיים אינם מיועדים למאגר. הוספה ל־gitignore אינה מסירה קובץ שכבר נמצא במעקב.
- שלבו סריקת סודות לפני העלאה ובתהליך CI, והתייחסו להתראות כחומר לבדיקה. סריקה אינה מבטיחה שכל סוד יזוהה.
- אם נמצא סוד שפורסם, בטלו או החליפו אותו אצל השירות הרלוונטי ובדקו שימוש חשוד. מחיקתו מהגרסה הנוכחית בלבד אינה מבטלת את החשיפה.
מה עדיין צריך להתברר
לפני שאפשר לקבוע את מלוא היקף הבעיה, נדרש לעיין במחקר המקורי: כיצד הוגדר סוד, איך נבדקו הממצאים ואילו תנאים הובילו לשמירת הפקודות. התחקיר המצורף אינו מספק גרסה מושפעת, הודעת תיקון או תגובה רשמית של ספקית הכלי. לכן אין בסיס להכריז שהבעיה נפתרה, או להמליץ על עדכון מסוים כפתרון.
עד לבירור הזה, המסקנה המעשית מצומצמת וברורה: קובצי הגדרות של סוכני קוד צריכים להיכלל בבדיקת האבטחה של המאגר. נוחות באישור פקודות יכולה לחסוך עבודה חוזרת, אבל אינה מחליפה החלטה מודעת לגבי המידע שנשמר ולגבי הקבצים שמותר לפרסם.
שאלות נפוצות
האם האפשרות Don't ask again ב־Claude Code עלולה לחשוף סיסמאות?
לפי דיווח על מחקר Apiiro, אישור קבוע עלול לשמור פקודה המכילה סיסמה או מפתח בקובץ הגדרות, שעלול להתפרסם עם המאגר. אין בכך הוכחה שכל שימוש באפשרות חושף מידע, ועמוד המחקר המקורי לא נבדק לצורך כתבה זו.
מה עושים אם מפתח API הגיע למאגר GitHub ציבורי?
יש לבטל או להחליף את המפתח אצל השירות שהנפיק אותו, ולבדוק יומני גישה לזיהוי שימוש חשוד. מחיקת המפתח מהקובץ הנוכחי אינה מספיקה, משום שהוא עשוי להישאר בהיסטוריית Git או בעותקים אחרים.
איך מצמצמים סיכון לחשיפת סודות בעבודה עם סוכן קוד?
נמנעים מהקלדת סודות ישירות בתוך פקודות שנשמרות, ובוחנים גם קובצי הגדרות והרשאות לפני commit. מומלץ לשלב ניהול סודות, הרשאות מצומצמות וסריקה אוטומטית לפני העלאת שינויים למאגר.
דרגו את הכתבה
הדירוג עוזר לנו לדעת מה שווה לכם.



תגובות