סקירה כללית של CodeMender

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

‫CodeMender הוא סוכן אבטחת קוד מבוסס-AI שיכול למצוא, לאמת ולתקן פרצות אבטחה עמוקות בבסיס הקוד. ‫CodeMender עוטף מודל LLM במערכת בדיקה שעברה כוונון עדין, ומשתמש בהנחיות, במיומנויות ובלוגיקת תזמור שפותחו על ידי Google DeepMind כדי להפוך את המודל למערכת אקטיבית שמתמחה באבטחת קוד.

איך זה עובד

‫CodeMender מיועד לטפל בקנה מידה ובמגוון של סביבות ארגוניות מודרניות, שבהן הקוד משתרע על שפות וסוגי מערכות רבים:

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

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

ארכיטקטורת המערכת

מנקודת המבט של המשתמש, מערכת CodeMender מורכבת משני רכיבים:

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

שפות ו-frameworks נתמכים

‫CodeMender תומך בסוגי הפגיעות המובילים בכל שפות התכנות העיקריות: C/C++‎,‏ Go,‏ Java,‏ Python,‏ TypeScript / JavaScript,‏ Rust ו-Ruby. בנוסף, הוא תומך באופן נרחב בספריות סטנדרטיות בשפות האלה, וגם במסגרות נפוצות לארגונים (כמו HTML/CSS,‏ Django,‏ Flask,‏ React,‏ Spring Boot ו-Express).

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

מודלים נתמכים

‫CodeMender תומך במודלים הבאים:

לחצו כדי להרחיב את רשימת המודלים הנתמכים

כדי לציין מודל כשמריצים פקודות של CodeMender CLI, אפשר לעיין במאמר בנושא ציון המודל.

אזורים נתמכים

‫CodeMender זמין בכל העולם.

מעקב אחר השימוש בטוקנים

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

שורת סטטוס בזמן אמת

בזמן שהפקודה cm find,‏ cm fix,‏ cm verify או cm session resume פועלת, מעבירים את הדגל --compact כדי להציג שורת סטטוס מתגלגלת שמתעדכנת בזמן שהסוכן פועל:

cm find ./src/auth/ --compact

בשורת הסטטוס מופיעים סכומים מצטברים של סשנים:

Tokens: 40k in / 12k out / 60k total

הספירה של סשנים שהופסקו והופעלו מחדש ממשיכה מהמקום שבו היא נעצרה בהפעלה הקודמת. הספירה של total עשויה לכלול את הטוקנים של הנימוקים הפנימיים של המודל, ולכן היא יכולה להיות גבוהה מ-total.in + out

יציאה מהסיכום

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

✅ Completed 14 tool steps in 3m 42s | Tokens: 40k in / 12k out / 60k total

השימוש בטוקנים שחויב

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

תחילת העבודה עם ה-CLI

כדי להתחיל בסריקה, צריך להגדיר את כלי ה-CLI ולאתחל את סביבת העבודה.

דרישות מוקדמות

לפני שמפעילים את CodeMender CLI, צריך לוודא שהסביבה מוכנה בצורה נכונה:

  • הגדרת פרויקט Google Cloud: מגדירים את הפרויקט עם ממשקי ה-API ותפקידי ה-IAM הנדרשים. Google Cloud
  • מורידים את CodeMender CLI: מורידים ומתקינים את הקובץ הבינארי של CodeMender CLI למערכת ההפעלה שלכם.
  • הגדרת פרטי כניסה ל-Google Cloud: מגדירים את Google Cloud Application Default Credentials ‏ (ADC) כדי לאמת את ה-CLI.
  • הקצאת קוד המקור: משכפלים או מעתיקים את קוד המקור של הפרויקט שרוצים לסרוק אל סביבת העבודה.
  • הגדרת ארגז החול: מגדירים את נקודות הגישה לספריות, את פרופילי הגישה לרשת ואת חריגי האבטחה לסביבת ארגז החול.

ציון המודל

כברירת מחדל, CodeMender משתמש ב-Gemini 3.5 Flash. כדי לבטל את מודל ברירת המחדל, מעבירים את הדגל --model עם מזהה המודל המתאים:

  • ‫Gemini 3.5 Flash (ברירת מחדל): --model gemini-3.5-flash
  • ‫Gemini 3.1 Pro Preview: --model gemini-3.1-pro-preview
  • תצוגה מקדימה של Gemini 3 Flash: --model gemini-3-flash-preview

הדגל --model נתמך בפקודות הבאות:

  • cm find
  • cm verify
  • cm fix

כדי לציין מודל כשמריצים אחת מהפקודות האלה, משתמשים בתחביר הבא:

cm COMMAND TARGET --model MODEL_NAME

אבטחה ופרטיות נתונים

בקטעים הבאים מפורטים מודל האבטחה, מדיניות שמירת הנתונים ואמצעי בקרת הגישה של CodeMender:

אילו נתונים נשלחים לענן?

כשמשתמשים ב-CodeMender, כלי ה-CLI המקומי מתווך את הגישה לקוד, כדי להבטיח שמאגרי קוד המקור המלאים לא יועלו לשרתים של Google ולא ישוכפלו באופן עצמאי על ידי הסוכן המתארח.

במקום זאת, הנתונים שנשלחים לסוכן המתארח ב-Google הם מקומיים בלבד וכוללים:

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

קוד המקור של הלקוחות אף פעם לא משמש לאימון המשקלים של המודל הבסיסי.

מהי מדיניות שמירת הנתונים?

ל-CodeMender יש מדיניות קפדנית לשמירת נתונים לטווח קצר:

  • שמירה למשך 7 ימים לכל היותר: נתוני סשנים, כולל קטעי קוד ומצבי מעקב, נשמרים למשך 7 ימים לכל היותר באחסון של פלטפורמת הסוכנים של Gemini Enterprise, כדי לאפשר למשתמשים להמשיך בצורה חלקה סריקות שהופסקו. אחרי 7 ימים, הוא נמחק באופן אוטומטי (ראו שמירת נתונים אפסית).
  • מחיקה מפורשת: הלקוחות לא צריכים לחכות 7 ימים, הם יכולים להפעיל ניקוי מיידי של כל נתוני הסשן על ידי קריאה ל-DeleteInteraction.
  • ממצאים ארעיים: ממצאים של נקודות חולשה ותיקונים לא מאוחסנים במסדי נתונים לטווח ארוך, אלא מצטברים בזיכרון במהלך הפייפליין.

למי יש גישה לנתונים?

העיצוב של CodeMender מבוסס על גישה של 'אפס גישה לנתונים' בכל הנוגע לשקיפות בפני בני אדם:

  • ללא גישה אנושית: לקבוצות של בני אדם או למהנדסי Google אין גישה לקריאת נתוני לקוחות בסביבת הייצור.
  • אין חשיפה לאופרטורים: גם לצורך ניפוי באגים בייצור ומעקב אחר שגיאות, האופרטורים של Google מוגבלים ואין להם חשיפה להקשר של קוד המקור של הלקוח או למצבי סשן זמניים.
  • בידוד קפדני: כל הנתונים מבודדים באופן לוגי והגישה אליהם מבוקרת לפי ארגון ופרויקט לחיוב של לקוח, כדי להגן על פרטיות הדיירים בתשתית המשותפת שלנו.
  • ‫VPC Service Controls (VPC-SC): כדי להגן על הסביבה שלכם בצורה טובה יותר, הארכיטקטורה של CodeMender תומכת באופן מלא ב-VPC Service Controls (VPC-SC). כך תוכלו להגדיר מתחם אבטחה היקפית מאובטח מסביב למשאבים שלכם ב-Google Cloud, ולצמצם את הסיכונים לזליגת נתונים בזמן שהנתונים המקומיים נשלחים למנוע ההסקה בענן.

המאמרים הבאים

במדריכים הבאים יש הוראות מפורטות: