מפתח תוכנה עובד על מחשב נייד כחלק מתהליך סקירת קוד מאובטח
צילום: Glenn Carstens-Peters / Unsplash

Google CodeMender סורקת, מאמתת ומתקנת חולשות — אבל עדיין לא לייצור

Google מרחיבה את CodeMender, סוכן אבטחת קוד שמנסה לטפל בכל השרשרת: איתור חולשה, אימות שהיא ניתנת לניצול, יצירת Patch ובדיקתו. בעדכון שפורסם ב‑4 בנובמבר 2026 נוספו אפשרויות בידוד מאובטחות יותר וסריקה גמישה של תיקייה, מאגר שלם או רק קבצים שהשתנו.

הכלי נמצא ב‑Public Preview עבור קבוצה מוגבלת של לקוחות. Google מדגישה שמדובר בשירות Pre‑GA המיועד לבדיקה והערכה בלבד, לא לשימוש מסחרי או בסביבת ייצור, ושיש לפקח מקרוב על כל פעולה שלו.

שלושה שלבים: Find, Verify, Fix

  • Find: CodeMender סורקת את בסיס הקוד בעזרת LLM וכלים ייעודיים, או מקבלת רשימת ממצאים מסורק חיצוני.
  • Verify: היא בונה את הפרויקט ומנסה לשחזר את החולשה בסביבה מקומית כדי לבדוק אם הממצא באמת ניתן לניצול ולצמצם False Positives.
  • Fix: היא מייצרת תיקון, מריצה בדיקות ומציגה Diff לפני החלת השינוי.

לפי התיעוד, CodeMender תומכת כברירת מחדל ב‑C/C++, C#/.NET, Go, Java, JavaScript ו‑TypeScript, Kotlin, Python, Ruby, Rust ו‑PHP, וכן במסגרות נפוצות כמו Django, Flask, React, Spring Boot, ASP.NET ו‑Express.

מה חדש בעדכון הנוכחי?

היכולת החדשה המרכזית היא Secure autonomous remediation. אימות חולשות והרצת תרחישי ניצול יכולים להתבצע בתוך Sandbox ברמת מערכת ההפעלה או במכונה וירטואלית מבודדת. פעולות כתיבה מקומיות והרצת פקודות יכולות לדרוש אישור אנושי, כדי למנוע מסוכן בדיקות האבטחה לבצע שינוי לא רצוי.

נוספה גם בחירת היקף סריקה: תיקייה מסוימת, מאגר שלם או רק קבצים שהשתנו. כך צוותים יכולים להתאים את העומק והעלות בין סריקה מהירה ב‑Pull Request לבין בדיקה רחבה יותר לפני Release.

מה עושה ה‑Sandbox המקומי?

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

התיעוד מציין שתיקיות אישורים נפוצות כמו .ssh,‏ .aws,‏ .config/gcloud,‏ .kube ו‑.docker אינן נחשפות לסוכן. משתני סביבה ששמם נראה כמו Token, Secret, Key או Password מוסרים לפני הרצת פקודות.

עם זאת, Google מזהירה ש‑Sandbox ברמת תהליך חלש יותר ממכונה וירטואלית מבודדת. ב‑Windows הבידוד עדיין מוגדר ניסיוני. צוותים שבודקים קוד לא מהימן או PoC מסוכן צריכים להעדיף VM ייעודית ולמנוע גישה לרשת ולסודות.

מגבלות שחשוב להכיר

  1. לא לייצור: גרסת ה‑Preview מיועדת להערכה בלבד.
  2. רק קוד מורשה: מותר לנתח קוד בבעלות הארגון, קוד שיש לו הרשאה להשתמש בו, או קוד פתוח ברישיון OSI.
  3. אישור אנושי נשאר חובה: Patch שעובר בדיקות אינו מבטיח התאמה ארכיטקטונית או היעדר Regression.
  4. ה‑PoC עצמו מסוכן: אימות ניצול צריך להתבצע בסביבה מבודדת, עם Logging ויכולת השמדה מהירה.
  5. אין תחליף ל‑SDLC: הכלי משלים Code Review, SAST/DAST, ניהול Dependencies ובדיקות חדירה — לא מחליף אותם.

המלצה לצוותי פיתוח

כדאי להתחיל במאגר שאינו קריטי, לחבר אותו ללא Secrets, להפעיל סריקה לקריאה בלבד ולבדוק בנפרד את איכות הממצאים, שיעור ה‑False Positives והתיקונים המוצעים. רק לאחר מכן ניתן לשקול שילוב מבוקר ב‑CI/CD — ובהתאם למגבלות ה‑Preview ולתנאי השירות.

מקורות

תמונה: Glenn Carstens-Peters / Unsplash, ברישיון Unsplash. פרטי המקור והרישיון מתועדים במדיה.

דילוג לתוכן