קלוד קוד ו-attack surface: איך מצמצמים את הקוד שתוקף יכול להגיע אליו

ב-20 באוקטובר 2026 פרסם הצוות האדום של Anthropic מחקר שהופך את השאלה הרגילה על אבטחת קוד. במקום לשאול איפה הבאג, הוא שואל איזה קוד בכלל לא צריך להיות נגיש. ב-25 הפרויקטים שנבדקו, התשובה כללה גם את OpenSSH.

למה לצמצם קוד נגיש ולא פשוט למצוא עוד באגים?

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

צמצום attack surface עובד אחרת. כל הקוד שתוקף יכול להפעיל מבחוץ הוא ה-attack surface. כשמזיזים חלק ממנו מאחורי שער (מלפני האימות לאחריו, מאפס קליקים לקליק אחד, מפעיל כברירת מחדל להפעלה מפורשת), כל באג שמסתתר בו נעשה קשה יותר להשגה. הבאגים לא נעלמים. החומרה שלהם יורדת, כולל של באגים שאולי מנוצלים כבר עכשיו בשקט ואף אחד עוד לא יודע עליהם.

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

אילו שלוש שאלות קלוד שואל על הקוד?

החוקרים נתנו לקלוד שלושה תיאורים של קוד נגיש מיותר, ובדקו אם הוא מוצא אותם בבסיסי קוד גדולים:

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

שימו לב שאף אחת מהשאלות לא מבקשת מקלוד למצוא פרצה. הן מבקשות ממנו למפות.

מה הוא מצא ב-25 פרויקטים?

הסריקה כיסתה 25 פרויקטים בקוד פתוח, יותר מחמישה מיליון שורות, בין השאר ב-C, ‏C++‎, ‏Java, ‏PHP ו-Python. קלוד בנה רשימה של יותר מ-17,000 אפשרויות הגדרה, ו-3,842 מהן נגעו בהגדרה של מנגנון או תכונה רלוונטיים לאבטחה. בסך הכול: 493 בעיות.

הפרויקטים חולקו לשלוש קבוצות: 10 ציבוריים (משרתים כל מי שמגיע), 11 מוגנים באימות, ו-4 פרטיים שמשרתים את הסביבה של המפעיל עצמו. המספרים המעניינים ביותר הגיעו מהקבוצה המוגנת:

• בכל 11 הפרויקטים המוגנים: נמצא קוד שנגיש שלא בכוונה. 93 נקודות חשופות לפני אימות בהגדרת ברירת המחדל, 37 מקומות שבהם קוד רץ או מצב נשמר לפני האימות, ו-61 שילובי הגדרות שהחלישו בשקט מנגנון שהמנהל הגדיר
• שילובים בלי אזהרה: 162 שילובים רגישים שהתקבלו בלי שגיאה, בלי אזהרה ובלי תיעוד. ב-94 מהם השילוב כיבה מנגנון אבטחה
• אף אחד מאלה לא ניתן לניצול מיידי לבד: כך Anthropic כותבת על ממצאי הקבוצה המוגנת. מה שהם עושים זה להגדיל את השטח שתוקף יכול לעבוד עליו

ושני ממצאים שכדאי להכיר גם אם אתם לא מתחזקים שרת.

כלל חסימה שלא חוסם. הדפוס הזה הופיע בנפרד בארבעה פרויקטים שאין ביניהם קשר. מנהל כותב כלל גישה לפי שם מארח או תבנית, ולא לפי כתובת IP. השרת משווה את הכלל לשם המארח של הלקוח, אבל הוא יודע את השם רק אם חיפוש DNS הפוך מופעל, וברוב הפרויקטים הוא היה כבוי. בלי השם, השרת משווה את התבנית לכתובת ה-IP כטקסט, וזה אף פעם לא תואם. כלל החסימה לא נתפס אף פעם, והרשימה נכשלת במצב פתוח.

21 שנה של תעודה שלא נבדקה. בפרויקט אחד אפשרות אחת דורשת מכל לקוח להזדהות בתעודה, ואפשרות אחרת אמורה רק לדחות את הבדיקה עד שהיא נדרשת. בפועל השנייה ביטלה את הבדיקה לגמרי. שרת שהוגדר לקבל רק לקוחות מהימנים קיבל חיבור מכל אחד, בלי אזהרה ובלי מילה בתיעוד. השילוב הזה היה בקוד 21 שנה.

מה קרה ב-OpenSSH?

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

בגרסה 10.4 (יולי 2026) נוספה תמיכה ניסיונית בחתימה פוסט-קוונטית שמשלבת ML-DSA-44 עם Ed25519. לפי הערות השחרור היא כבויה כברירת מחדל. אבל קלוד עקב אחרי מסלולי הקלט של sshd ומצא שכ-4,500 שורות של הקוד החדש נגישות ללקוח לא מאומת בכל מקרה, גם כשהמנהל החריג את האלגוריתם במפורש. השרת פענח כל סוג מפתח שהלקוח שלח, ורק אחר כך בדק אם הסוג מותר. לפי Anthropic, אלה כ-16% מהקוד ש-sshd מריץ לפני אימות בהגדרת ברירת המחדל.

Anthropic דיווחה למפתחים יחד עם תיקונים, וגרסה 10.5 (אוגוסט) הקדימה את הבדיקה לפני הפענוח. ואז קלוד מצא בבדיקה החדשה שני פערים:

• השם המוצהר מול המפתח בפועל: הבדיקה הסתכלה על שם האלגוריתם שהלקוח הכריז עליו, אבל המפענח נבחר לפי סוג שכתוב בתוך המפתח עצמו. לקוח יכול להכריז על ‎ssh-ed25519‎, לעבור את הבדיקה, ולשלוח מפתח ML-DSA שיפוענח בכל זאת
• חתימת ה-CA בתעודות: תעודות מופעלות כברירת מחדל, ו-sshd פענח את מפתח ה-CA שבתוך תעודה שהתוקף שלח והריץ עליו אימות חתימה מלא, לכל אלגוריתם נתמך, לפני שבדק את ההגדרות. כלומר כל מאמת חתימות בקובץ ההרצה היה נגיש לכל לקוח שהשלים החלפת מפתחות

החוקרים בנו הוכחת היתכנות ועבדו עם המתחזקים על כמה סבבים של תיקון. הבדיקה עברה לתוך המפענח עצמו, וגרסה 10.6 יצאה ב-6 באוקטובר 2026. לפי Anthropic, התיקון הוריד כחמישית מהקוד שלקוח לא מאומת יכול היה להגיע אליו בהתקנת ברירת מחדל. הערות השחרור של OpenSSH מאשרות את השינוי ומייחסות אותו ל-Chris Rohlf ״in collaboration with Claude and Anthropic Research״.

הלקח של Anthropic: אם קוד נגיש מיותר שורד ב-OpenSSH, הוא יכול לשרוד בכל מקום.

איך מריצים את זה על הקוד שלכם?

Anthropic איחדה את שלוש השיטות לסקיל אחד של קלוד, ועובדת על שילובו ב-OSS Scanner, שירות סריקה חינמי לפרויקטים בקוד פתוח שבוחרים להצטרף. הפוסט לא מצרף את הסקיל עצמו, אבל מתאר אותו בפירוט, וזה מספיק כדי לשחזר את השיטה בקלוד קוד:

• שלושה מעברים, כל אחד מאפס: ברירת מחדל, אחר כך נגישות מוקדמת, ובסוף שילובי הגדרות. כל מעבר מתחיל עם חלון קונטקסט ריק, ומקבל מהמעבר הקודם רק סיכום קצר. בקלוד קוד זה אומר שיחה חדשה עם ‎/clear‎ בין מעבר למעבר, וקובץ סיכום קצר שהמעבר הבא קורא
• מלאי נקודות כניסה קודם: בכל מעבר קלוד מתחיל ברשימה של נקודות הכניסה לקוד, ורק ממנה ממשיך לממצאים
• כל ממצא מאומת בהרצה: קלוד מאשר כל ממצא במעקב דינמי אחרי התוכנית הרצה, ולא רק בקריאת קוד. לכן הפרויקט צריך להיבנות ולרוץ בסביבה של הסוכן
• שער שלא משנה כלום: לממצאי ברירת מחדל קלוד מתכנן ומממש שער, ואז מריץ את הטסטים של הפרויקט ועוד סט רגרסיה מסוג קופסה שחורה מול הגרסה המקורית. התוצאות חייבות להיות זהות
• מה שמשנה הגדרה לא סטנדרטית, עובר לבן אדם: שער שישנה התנהגות בהגדרה שאינה ברירת המחדל לא נכנס. הוא מחכה להחלטה אנושית
• בשני המעברים האחרים, הצעות ולא קוד: הקדמת בדיקת הגדרה, שמירה על סדר מצבים בפרוטוקול, או דחיית שילוב מסוכן כבר בטעינת ההגדרות

כך יכול להיראות פרומפט פתיחה למעבר הראשון. הניסוח שלנו, לא של Anthropic:

Pass 1 of 3: default-configuration attack surface.
Build an inventory of every entry point reachable from outside
(network listeners, parsers, CLI/env input) in the default config.
For each, find code that is reachable by default but not used by
any default feature. Confirm each finding by running the program
and tracing the path; do not report anything you did not trace.
Write findings and a 10-line handoff to attack-surface-notes.md.
Do not change code yet.

ההוראה האחרונה חשובה. קודם ממפים, אחר כך שוקלים שערים, וכל שער נבדק מול הטסטים לפני שהוא נכנס.

במה זה שונה מ-‎/security-review‎?

‎/security-review‎ בקלוד קוד בודק את ה-diff של הענף שלכם מול ענף ברירת המחדל, ומחפש פרצות כמו הזרקה, בעיות אימות וחשיפת מידע. הוא שומר על מה שנכנס עכשיו.

צמצום attack surface עובד על כל הקוד, כולל קוד בן 21 שנה שאף אחד לא נגע בו, ושואל שאלה אחרת. לא ״יש כאן באג?״ אלא ״הקוד הזה צריך להיות נגיש בכלל?״. אחד לא מחליף את השני. אם צריך לבחור מאיפה להתחיל בפרויקט ותיק, צמצום attack surface נותן יותר על כל שעת עבודה, כי הוא מוריד סיכון גם מהבאגים שאף כלי עוד לא מצא.

איפה צריך להיזהר?

• אלה המספרים של Anthropic: 493 ״בעיות״ אינן 493 פרצות. בקבוצה המוגנת Anthropic עצמה כותבת שאף ממצא לא היה ניתן לניצול מיידי לבד. המקרה של OpenSSH הוא ההוכחה החיצונית היחידה בפוסט, ושם המתחזקים אישרו את השינוי בהערות השחרור
• שער יכול לשבור משתמשים: קוד שנראה מיותר בברירת המחדל משרת לפעמים הגדרה שמישהו כן משתמש בה. בגלל זה השיטה דורשת תוצאות זהות בטסטים, ומעבירה לבן אדם כל שער שנוגע בהגדרה לא סטנדרטית
• בלי הרצה, אין אימות: ממצא שקלוד ״ראה״ בקוד בלי לעקוב אחריו בתוכנית רצה הוא השערה. אם הפרויקט שלכם לא נבנה בסביבה של הסוכן, השיטה מאבדת את הבלם החשוב ביותר שלה
• הסוכן מריץ את הקוד שלכם: מעקב דינמי פירושו שקלוד מפעיל שרתים ומפענחים. הריצו את זה בסביבה מבודדת, לא על מכונה עם גישה לפרודקשן

שורה תחתונה

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

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