‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

התקנה והגדרה של ה-CLI

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

מודל הארכיטקטורה והאבטחה

‫CodeMender משתמש במודל הרצה מקומי:

מנוע חשיבה רציונלית באירוח: חשיבה רציונלית אג'נטית, מידול איומים ולוגיקת תזמור פועלים באופן מאובטח ב-Gemini Enterprise Agent Platform. Google Cloud
ממשק שורת הפקודה (CLI) להפעלה מקומית: קוד המקור אף פעם לא יוצא מתחנת העבודה או מהקונטיינר של ה-CI/CD בכמות גדולה. כלי ה-CLI המקומי של cm מבצע קריאת קבצים, בדיקות build מקומיות ואימותי ניצול של הוכחת היתכנות (PoC) בארגז החול המקומי, ושולח רק קטעי קוד ספציפיים ותוצאות של הפעלת הכלים לקצה העורפי בענן דרך Interactions API ב-Gemini Enterprise Agent Platform.

הגדרת הסביבה

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

הגדרת הפרויקט והרשאות IAM

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

ממשקי ה-API הנדרשים

מוודאים שממשקי ה-API הבאים של Google Cloud מופעלים בפרויקט:

‫Agent Platform API ‏(aiplatform.googleapis.com) – משמש לסטרימינג ולניהול של סשנים פעילים.
‫Cloud Resource Manager API ‏(cloudresourcemanager.googleapis.com) – מאמת את מצבי האימות של המשתמשים ואת המטא-נתונים של הפרויקט.

תפקיד IAM מומלץ שמוגדר מראש

כדי להריץ את פקודות ה-CLI, צריך להקצות למשתמשים את תפקיד ה-IAM הבא:

משתמש בפלטפורמת הסוכנים (roles/aiplatform.user) – מאפשר למשתמשים ליצור, להפעיל ולנהל סשנים פעילים.

הורדה והתקנה של CodeMender CLI

הקבצים הבינאריים של CodeMender CLI מתארחים ב-Artifact Registry. בוחרים את הכרטיסייה של מערכת ההפעלה כדי להוריד ולהתקין את ה-CLI.

Linux x86_64

כדי להוריד ולהתקין את CodeMender CLI ל-Linux‏ (x86_64):

מורידים את החבילה באחת מהשיטות הבאות:

‫ה-CLI של gcloud: מריצים את הפקודה הבאה:

gcloud artifacts generic download \
  --project=cmoc-prod \
  --location=us \
  --repository=codemender-cli-production \
  --package=cm \
  --version=stable \
  --name=cm-linux-amd64.zip \
  --destination=./

‫curl: מריצים את הפקודה הבאה:

curl -L -o cm-linux-amd64.zip "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-linux-amd64.zip:download?alt=media"

מתקינים את ה-CLI:

unzip cm-linux-amd64.zip
chmod +x cm
sudo mv cm /usr/local/bin/cm

‫Linux ARM64

כדי להוריד ולהתקין את CodeMender CLI ל-Linux (ARM64):

מורידים את החבילה באחת מהשיטות הבאות:

‫ה-CLI של gcloud: מריצים את הפקודה הבאה:

gcloud artifacts generic download \
  --project=cmoc-prod \
  --location=us \
  --repository=codemender-cli-production \
  --package=cm \
  --version=stable \
  --name=cm-linux-arm64.zip \
  --destination=./

‫curl: מריצים את הפקודה הבאה:

curl -L -o cm-linux-arm64.zip "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-linux-arm64.zip:download?alt=media"

מתקינים את ה-CLI:

unzip cm-linux-arm64.zip
chmod +x cm
sudo mv cm /usr/local/bin/cm

macOS Intel

כדי להוריד ולהתקין את CodeMender CLI ל-macOS (Intel):

מורידים את החבילה באחת מהשיטות הבאות:

‫ה-CLI של gcloud: מריצים את הפקודה הבאה:

gcloud artifacts generic download \
  --project=cmoc-prod \
  --location=us \
  --repository=codemender-cli-production \
  --package=cm \
  --version=stable \
  --name=cm-darwin-amd64.zip \
  --destination=./

‫curl: מריצים את הפקודה הבאה:

curl -L -o cm-darwin-amd64.zip "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-darwin-amd64.zip:download?alt=media"

מתקינים את ה-CLI:

unzip cm-darwin-amd64.zip
chmod +x cm
mv cm /usr/local/bin/cm

‫macOS Apple silicon

כדי להוריד ולהתקין את CodeMender CLI ל-macOS (Apple silicon):

מורידים את החבילה באחת מהשיטות הבאות:

‫ה-CLI של gcloud: מריצים את הפקודה הבאה:

gcloud artifacts generic download \
  --project=cmoc-prod \
  --location=us \
  --repository=codemender-cli-production \
  --package=cm \
  --version=stable \
  --name=cm-darwin-arm64.zip \
  --destination=./

‫curl: מריצים את הפקודה הבאה:

curl -L -o cm-darwin-arm64.zip "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-darwin-arm64.zip:download?alt=media"

מתקינים את ה-CLI:

unzip cm-darwin-arm64.zip
chmod +x cm
mv cm /usr/local/bin/cm

Windows x86_64

כדי להוריד ולהתקין את CodeMender CLI ל-Windows‏ (x86_64):

מורידים את החבילה באחת מהשיטות הבאות:

ה-CLI של gcloud: מריצים את הפקודה הבאה ב-PowerShell:

gcloud artifacts generic download `
  --project=cmoc-prod `
  --location=us `
  --repository=codemender-cli-production `
  --package=cm `
  --version=stable `
  --name=cm-windows-amd64.zip `
  --destination=./

‫PowerShell: מריצים את הפקודה הבאה:

Invoke-WebRequest -Uri "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-windows-amd64.zip:download?alt=media" -OutFile cm-windows-amd64.zip

מתקינים את ה-CLI:

Expand-Archive -Path cm-windows-amd64.zip -DestinationPath ./
# Move cm.exe to a permanent folder and add it to your system PATH (e.g. Environmental Variables)

Windows ARM64

כדי להוריד ולהתקין את CodeMender CLI ל-Windows (ARM64):

מורידים את החבילה באחת מהשיטות הבאות:

ה-CLI של gcloud: מריצים את הפקודה הבאה ב-PowerShell:

gcloud artifacts generic download `
  --project=cmoc-prod `
  --location=us `
  --repository=codemender-cli-production `
  --package=cm `
  --version=stable `
  --name=cm-windows-arm64.zip `
  --destination=./

‫PowerShell: מריצים את הפקודה הבאה:

Invoke-WebRequest -Uri "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-windows-arm64.zip:download?alt=media" -OutFile cm-windows-arm64.zip

מתקינים את ה-CLI:

Expand-Archive -Path cm-windows-arm64.zip -DestinationPath ./
# Move cm.exe to a permanent folder and add it to your system PATH (e.g. Environmental Variables)

הגדרת פרטי הכניסה והפרויקט ב- Google Cloud

ממשק שורת הפקודה של CodeMender מתקשר עם מנוע החשיבה הרציונלית שמתארח בענן דרך Interactions API, לכן צריך להגדיר Google Cloud Application Default Credentials (ADC) ולציין את פרויקט היעד בסביבה.

כדי לבצע אימות, מריצים את הפקודה הבאה ופועלים לפי ההנחיות להתחברות:
```
gcloud auth application-default login
```
מגדירים את משתנה הסביבה GOOGLE_CLOUD_PROJECT למזהה הפרויקט ב- Google Cloud :
```
export GOOGLE_CLOUD_PROJECT="PROJECT_ID"
```
לחלופין, מגדירים את הפרויקט הפעיל ב-CLI של gcloud:
```
gcloud config set project PROJECT_ID
```
מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud .

הפעלת סביבת העבודה

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

מריצים את cm init מתיקיית השורש של בסיס הקוד כדי ליצור קובצי מעקב אחרי מצב מקומי ולקבוע הגדרות בסיסיות:

cm init

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

cm init --verify

בדיקת הקישוריות וההרשאות של השירות

כדי לאמת את פרטי הכניסה, ההגדרות, הגישה לרשת והרשאות ה-IAM בלי להתחיל סריקה או לשנות את סביבת העבודה, מריצים את cm health:

cm health

הפקודה cm health מריצה ארבע בדיקות ברצף, ועוצרת בשכבה הראשונה שנכשלת. אפשר להריץ את cm health מכל ספרייה, אפילו לפני שמריצים את cm init. הוא לא כותב בדיסק ולא צורך מכסת מודלים.

כדי לבצע בדיקות מקדימות אוטומטיות של CI/CD או מעקב סינתטי מתוזמן, משתמשים ב---strict כדי להיכשל כשמדלגים על בדיקות IAM ברמת הפרויקט, וב---json כדי להפיק דוח JSON בפורמט קריא למכונה:

cm health --strict --json

בטבלה הבאה מתוארים קודי היציאה של cm health:

קוד יציאה	שכבה	תיאור
`0`	—	כל בדיקות התקינות עברו בהצלחה.
`10`	`credentials`	ה-CLI לא הצליח לקבל אסימון OAuth או Application Default Credentials תקין, או שהשרת דחה את האסימון (`401 Unauthorized`).
`20`	`config`	קובץ `config.yaml` המקומי, הדגל `--team-id` או משתנה הסביבה `CM_TEAM_ID` לא תקינים.
`30`	`reachability`	ה-CLI לא הצליח להגיע לנקודת קצה ל-API של Agent Platform (לדוגמה, בגלל מגבלות של DNS,‏ TLS, שרת proxy או VPC Service Controls).
`40`	`authorization`	השרת הגיב, אבל למבצע הקריאה או לפרויקט אין הרשאה להריץ סריקות של CodeMender (לדוגמה, חסרות הרשאות `roles/aiplatform.user`).
`50`	—	בדיקת התקינות חרגה ממשך הזמן של `--timeout` (ברירת המחדל היא `30s`).

הדגלים הבאים נתמכים על ידי cm health:

דגל	ברירת מחדל	תיאור
`--json`	`false`	הפלט הוא אובייקט JSON יחיד לפלט סטנדרטי (stdout), כולל `status`,‏ `exit_code`,‏ `backend`,‏ `endpoint`,‏ `location`,‏ `project_id`,‏ `agent_id`,‏ `duration_ms`,‏ `layers`, וגם (אם קיימים) `warnings` ו-`error`.
`--strict`	`false`	התייחסות לאזהרות של בדיקת תקינות (כמו בדיקות של הרשאות IAM ברמת הפרויקט שלא אומתו או שדילגו עליהן) ככשלים של קוד יציאה `40`.
`--timeout`	`30s`	מגדירה את הזמן הקצוב הכולל לבדיקת התקינות.

פרמטרים להגדרה (`config.yaml`)

המטרה העיקרית של config.yaml היא להתאים את ההתנהגות של הסוכן של CodeMender לאבטחה, למגבלות הסביבה ולצורכי הביצועים של המערכת המקומית.

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

Usage

מיקום: כברירת מחדל, ה-CLI קורא את הקובץ הזה מ-~/.codemender/config.yaml. כדי לשנות את סביבת העבודה ואת ספריית ההגדרות, מגדירים את משתנה הסביבה CM_HOME (לדוגמה, CM_HOME=/path/to/custom/dir, שקורא את /path/to/custom/dir/config.yaml).
הפעלה: כשמריצים פקודות כמו cm find,‏ cm verify או cm fix, הלקוח המקומי קורא את הקובץ הזה כדי להגדיר פרמטרים של בטיחות, להחיל מעקפים של המערכת ולציין אילו קבצים או ספריות להתעלם מהם.

הגדרות ברירת המחדל של Core

הנה הסבר על הפרמטרים העיקריים שמוגדרים כברירת מחדל:

human_confirmation: true (או require_confirmation: true)
- מה זה אומר: כברירת מחדל, CodeMender לא יכול לשנות קבצים בדיסק או להריץ פקודות מעטפת בלי לבקש מכם אישור מפורש ב-[Y/n] בטרמינל.
- למה זו ברירת המחדל: יכול להיות ש-CodeMender ייצור תיקונים משוערים או ינסה להריץ סקריפטים של ניצול לרעה כדי לאמת נקודת חולשה. הדרישה לאישור אנושי עוזרת למנוע שינויים מקריים במערכת או הרצת קוד לא מורשית בסביבה המקומית.
- מעקף: בצינורות עיבוד נתונים של CI/CD לא אינטראקטיביים, אפשר להגדיר את הערך ל-false.
confirm_writes: false
- מה זה אומר: ההגדרה הזו משביתה את ההנחיות האינטראקטיביות לשינוי קבצים, ומאפשרת לסוכן CodeMender לכתוב תיקוני אבטחה ולשנות קובצי מקור ישירות בדיסק המקומי בלי לחכות לאישור אנושי.
- למה זו ברירת המחדל: כברירת מחדל, CodeMender מגדיר את מעקה הבטיחות הזה לערך true כדי לאכוף תהליך עבודה של "האדם שבתהליך". ‫CodeMender פועל על בסיס הקוד המקומי שלכם, ולכן דרישה לאישור ידני (לדוגמה, Write? [Y/n]) מונעת מהסוכן לבצע שינויים ספקולטיביים, שגויים או הרסניים בקובצי המקור. צריך להחליף את זה ל-false רק כשמריצים בסביבות sandbox מבודדות וחד-פעמיות או בצינורות עיבוד נתונים אוטומטיים של CI/CD ללא ממשק משתמש.
include: [".py", ".java", ".go", ".js", ".jsx", ".mjs", ".cjs", ".ts", ".tsx", ".c", ".cc", ".cpp", ".cxx", ".h", ".hpp", ".cs", ".rs", ".kt", ".kts", ".rb", ".php"]
- מה זה אומר: הגדרת הרשימה המפורשת של סיומות הקבצים שאתם מאשרים ל-CodeMender להטמיע ולנתח כשהוא סורק את סביבת העבודה שלכם. ‫CodeMender מדלג באופן אוטומטי על כל קובץ במאגר עם סיומת שלא צוינה ברשימה הזו.
- למה זו ברירת המחדל: הרשימה הזו כוללת כברירת מחדל את שפות התכנות העיקריות כדי למקסם את יעילות הסריקה ולמנוע מהנציג לבזבז זמן ואסימונים על קובצי טקסט לא רלוונטיים, פריטי build או קבצים בינאריים. עם זאת, מכיוון שאפליקציות מודרניות מטמיעות לעיתים קרובות נקודות חולשה בהגדרות הפריסה או בכלי האוטומציה, אתם יכולים להרחיב באופן ידני את רשימת ברירת המחדל הזו ב-config.yaml כך שתכלול קובצי תצורה, פורמטים של סקריפטים וקובצי IaC (לדוגמה, סקריפטים של מעטפת, XML,‏ YAML, מאפיינים וקובצי JSON) כדי ש-CodeMender לא יתעלם מהם בלי להודיע.
exclude_dirs: ["node_modules", "vendor", "dist", "bin", "target", "obj", "build", ".gradle"]
- מה זה אומר: CodeMender ידלג לגמרי על הספריות האלה במהלך סריקת סביבת העבודה וניתוח הקוד.
- למה זו ברירת המחדל: תיקיות גדולות של יחסי תלות או גרסאות build גורמות לעיכוב משמעותי ולצריכה מוגברת של טוקנים. כדי לשמור על ביצועים גבוהים וזמני תגובה מהירים, כדאי להשאיר את ההחרגה הזו כברירת מחדל. אפשר להתאים אישית את הרשימה הזו ב-config.yaml כדי לכלול או להחריג ספריות ספציפיות בהתאם למבנה הפרויקט.
project_paths: []
- המשמעות: רשימה של נתיבי ספריות ש-CodeMender יכול לגשת אליהם (לקרוא/לכתוב) במהלך הפעלת הכלי.
- למה זו ברירת המחדל: כברירת מחדל, הספרייה ריקה, מה שמגביל את הסוכן לספריית היעד לסריקה. אם תהליך ה-build או הבדיקה דורש גישה לקבצים מחוץ לספריית היעד של הסריקה, צריך להוסיף את הנתיבים האלה כאן.
- ספריית פריטי מידע שנוצרו בתהליך: הנציג יכול גם לכתוב לספריית פריטי מידע שנוצרו בתהליך לכל סשן (~/.codemender/artifacts/<session_id>/, או המקבילה ב-$CM_HOME).
- קבצים זמניים: כשהארגז החול מופעל, הספרייה המארחת /tmp תמיד חסומה, גם אם מוסיפים את /tmp אל project_paths. כלים שתומכים ב-TMPDIR משתמשים במקום זאת בספרייה זמנית בתוך ספריית פריטי המידע שנוצרו בתהליך.
sandbox:
- מה זה אומר: בלוק הגדרות לסביבת ארגז החול ברמת התהליך.
- פרמטרי משנה:
  - ‫enabled: true: (ערך בוליאני) מפעיל או משבית את ארגז החול. אם מגדירים את הערך true (ברירת המחדל), הנציג מפעיל כלים בתוך ארגז החול המקומי. אם מגדירים את הערך false, הנציג מפעיל כלים ישירות במערכת המארחת בלי בידוד.
  - mounts: (אובייקט)
    - ‫target_dir: ".": (מחרוזת) הספרייה שצריך לטעון כסביבת העבודה הפעילה בתוך ארגז החול. ה-CLI פותר נתיבים יחסיים מול השורש של סביבת העבודה.
  - network: (אובייקט)
    - ‫profile: "permissive-closed": (מחרוזת) פרופיל הגישה לרשת היוצאת בתוך ארגז החול. עדיין אין תמיכה בהוספה לרשימת ההיתרים של דומיינים ספציפיים או תבניות URL ספציפיות. פרופילים נתמכים:
      - ‫permissive-closed (ברירת המחדל): בידוד רשת מלא. ארגז החול חוסם את כל החיבורים היוצאים.
      - ‫permissive-open: מאפשרת גישה מלאה לרשת יוצאת.
security:
- מה זה אומר: בלוק הגדרות למדיניות אבטחה.
- פרמטרי משנה:
  - ‫protected_files: []: (רשימת מחרוזות) קבצים או ספריות במערכת המארחת שרוצים לטעון כלקריאה בלבד בתוך ארגז החול כדי להגן עליהם מפני שינויים (לדוגמה, ["~/.ssh/*"]). תומך בהרחבת נתיב (~) ובתווים כלליים לחיפוש (*).
model: "gemini-3.8-flash"
- מה זה אומר: מנוע הבינה המלאכותית שמוגדר כברירת מחדל ומפעיל את לולאות החשיבה הרציונלית בקצה העורפי.
- למה זו ברירת המחדל: gemini-3.8-flash מציע את האיזון האופטימלי בין מהירות, עלות וחשיבה אנליטית שנדרשת כדי להציע תיקונים. (המשתמשים יכולים לשנות את ההגדרה הזו ל-gemini-4-argon (Gemini 4 Argon) כדי לקבל חשיבה מעמיקה ומורכבת יותר, לפי הצורך).
vcs: { type: "git" }
- מה זה אומר: מגדיר את סוג מערכת לניהול גרסאות שבה הפרויקט משתמש באמצעות המפתח vcs. אם לא מגדירים את המדיניות הזו, הכלי מנסה לזהות באופן אוטומטי מאגרי Git או Mercurial. אם מגדירים את vcs לערך none, ה-CLI מציג אזהרה אבל ממשיך לפעול בלי פונקציונליות של VCS. ‫CodeMender מסתמך על ההגדרה הזו כדי לנהל תיקוני אבטחה משוערים, לעקוב אחרי שינויים בבסיס הקוד ולשלב את המאגר המקומי שלכם.
- למה זו ברירת המחדל: CodeMender תומך ב-Git, ב-Mercurial או בהגדרות VCS בהתאמה אישית. ‫Git היא ברירת המחדל כי היא הסטנדרט בתחום למעקב אחרי ניהול גרסאות, והיא מבטיחה שילוב חלק של diff ובטיחות החזרה למצב קודם.
build: { command: "make build && make test" }
- מה זה אומר: מגדיר את פקודת המעטפת המדויקת ש-CodeMender מריץ כדי לקמפל ולבנות את הפרויקט, וגם להריץ את בדיקות היחידה והרגרסיה.
- למה זו ברירת המחדל: הגדרת פקודת build ובדיקה היא קריטית לתהליך העבודה של האימות. היא מאפשרת ל-CodeMender לקמפל את הפרויקט ולהריץ את חבילת המקרים לבדיקה בסביבת ארגז החול המבודדת, כדי להוכיח שהתיקון שנוצר אכן מצמצם את נקודת החולשה בלי לשבש את הלוגיקה הקיימת של האפליקציה.

הרצה בארגז חול (sandbox)

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

למרות שארגז החול הזה מספק שכבת הגנה ראשונית בתחנת העבודה, הוא מספק הגנת אבטחה חלשה יותר מאשר הפעלת הנציג במכונה וירטואלית (VM) מבודדת לחלוטין:

Linux: משתמש במרחבי שמות של ליבה (CLONE_NEWNS, CLONE_NEWUSER וכו') ובמסנני seccomp כדי לבודד נקודות טעינה ולהגביל קריאות מערכת.
‫macOS: משתמש במנגנון sandbox-exec (Seatbelt) המובנה.
‫Windows (ניסיוני): משתמש בבידוד של AppContainer וברשימות של בקרת גישה (ACL). ארגז החול ב-Windows הוא ניסיוני ויכול להיות שיידרשו הרשאות אדמין או שהוא לא יתאים לחלק מהגדרות המערכת.

התנהגות ארגז החול

כשהארגז החול פעיל:

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

גישה לרשת במהלך הבנייה והאימות

בגלל שארגז החול מפעיל בידוד רשת כברירת מחדל (sandbox.network.profile מוגדר כברירת מחדל ל-permissive-closed), הנציג לא יכול לגשת לאינטרנט בזמן הפעלת הכלי.

זה יוצר מגבלות לפרויקטים שדורשים אחזור של יחסי תלות חיצוניים במהלך שלבי ה-build או האימות (לדוגמה, הפעלת npm install,‏ pip install או go get כחלק מ-build.command). אם תהליך ה-build ינסה לגשת לשירותי אינטרנט חיצוניים, הוא ייכשל.

טיפול ביחסי תלות ברשת

אם הפרויקט שלכם דורש גישה לרשת לצורך גרסאות build או בדיקות, יש לכם את האפשרויות הבאות:

אחזור מראש של יחסי תלות: מתקינים את כל יחסי התלות הנדרשים במערכת המארחת לפני שמריצים פקודות cm, כדי שפקודת ה-build לא תצטרך גישה לרשת.
הפעלת גישה לרשת בארגז החול: משנים את פרופיל הרשת ב-config.yaml כדי לאפשר חיבורים יוצאים:
```
sandbox:
  network:
    profile: "permissive-open"
```
הערה: עדיין אין תמיכה בהוספה מפורטת לרשימת ההיתרים של דומיינים או תבניות URL ספציפיים (כמו הוספה לרשימת ההיתרים של npmjs.org בלבד). permissive-open מעניק גישה מלאה לארגז החול.
לעקוף את ארגז החול: מריצים את הפקודה עם הדגל --unrestricted כדי להשבית לגמרי את ארגז החול ואת הגבולות של מערכת הקבצים בהרצה הזו.

הגדרת ארגז החול

אתם יכולים להגדיר את ארגז החול ולשלוט בו באמצעות האפשרויות הבאות:

הגדרות קבועות (config.yaml): אתם יכולים להתאים אישית את ההתנהגות של ארגז החול, את נקודות העגינה של מערכת הקבצים, את הגישה לרשת ואת מדיניות האבטחה. כדי לעשות את זה, אתם צריכים להוסיף את הבלוקים sandbox,‏ execution ו-security לקובץ config.yaml. פרטים נוספים זמינים במאמר פרמטרים של הגדרה.
שליטה בארגז החול באמצעות ה-CLI‏ (--sandbox): אתם יכולים להפעיל או להשבית את ארגז החול באופן מפורש להרצה אחת, על ידי העברת --sandbox=true או --sandbox=false אל cm find,‏ cm verify או cm fix.
עקיפת הבידוד באמצעות ה-CLI‏ (--unrestricted): אתם יכולים לעקוף באופן זמני את כל אמצעי ההגנה של ארגז החול להרצה אחת, על ידי העברת הדגל --unrestricted. הפעולה הזו משביתה את הגבולות של נתיב מערכת הקבצים (ומאפשרת לסוכן לגשת לכל נתיב במארח) ומשביתה לחלוטין את הבידוד של הקונטיינר ברמת מערכת ההפעלה (כולל בידוד הרשת).

בחירת רמת בידוד

בהתאם לדרישות האבטחה ולסביבת הפיתוח שלכם, אתם יכולים לבחור את רמת הבידוד המתאימה להפעלת ה-CLI של CodeMender.

‏Method	תיאור	יתרונות	חסרונות
ארגז חול מובנה (ברמת מערכת ההפעלה)	התכונה מופעלת כברירת מחדל. אפשר להשבית אותה בקובץ `config.yaml` או לעקוף אותה באמצעות דגלים של CLI. שימוש בתכונות מובנות של מערכת ההפעלה (מרחבי שמות/seccomp,‏ `sandbox-exec`,‏ `AppContainer` (ניסיוני)) כדי לבודד את ההפעלה.	קל משקל, ללא תקורה בהפעלה, גישה ישירה לכלי סביבת העבודה המקומית עם שליטה מפורטת. מומלץ לפיתוח מקומי יומיומי.	האבטחה מסתמכת על תכונות של ליבת מערכת ההפעלה; פחות מבודד ממכונה וירטואלית מלאה; התמיכה ב-Windows היא ניסיונית ויכול להיות שתידרש הרשאת אדמין או שהיא לא תהיה תואמת להגדרות מסוימות.
קונטיינרים	הפעלת הסוכן בקונטיינר (לדוגמה, Docker).	בידוד טוב, סביבה סטנדרטית.	נדרשת סביבת זמן ריצה של קונטיינר, יכול להיות כבד, לא מאפשר אינטראקציה ישירה עם כלים במחשב המקומי.
מכונות וירטואליות מלאות	הפעלת הסוכן ב-VM ייעודי.	אבטחה מקסימלית ובידוד מלא.	תקורה גבוהה של משאבים, הפעלה איטית, לא מאפשר אינטראקציה ישירה עם כלים במכונה המקומית.

Telemetry

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

כברירת מחדל, הטלמטריה מופעלת. כדי להשבית את הטלמטריה, מגדירים את משתנה הסביבה CM_TELEMETRY_OPT_OUT לערך 1 או true.

עדכון ה-CLI

ל-CodeMender יש מנגנון עדכון מובנה שמוודא שאתם משתמשים בגרסה העדכנית של ה-CLI.

בדיקות עדכונים אוטומטיות

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

ויסות נתונים: כדי לצמצם את התקורה, הבדיקה האוטומטית פועלת לכל היותר פעם אחת בכל 24 שעות.
נדרש מסוף אינטראקטיבי (TTY): ה-CLI בודק אם יש עדכונים ומציג הודעות רק כשמריצים אותו במסוף אינטראקטיבי. בסביבות לא אינטראקטיביות (כמו סקריפטים או צינורות עיבוד נתונים של CI/CD), המערכת מדלגת על הבדיקה ורושמת אזהרה ב-stderr פעם ביום לכל היותר.
הנחיה: אם יש גרסה חדשה, תופיע הנחיה ב-stderr: none 🆕 A new CodeMender release is available: 1.1.0 Update now? (y/N): אם בוחרים "כן" (y או yes), CodeMender מוריד את העדכון, מחליף את הקובץ הבינארי ויוצא. כדי להריץ את הפקודה בגרסה החדשה, צריך להפעיל אותה שוב. אם תבחרו באפשרות "לא", העדכון לא יתבצע והפקודה המקורית תופעל.
סבילות למצב אופליין: אם אתם במצב אופליין או שאי אפשר להגיע למאגר הגרסאות, הבדיקה נכשלת בלי להציג הודעה ו-CodeMender ממשיך להריץ את הפקודה.
מעקף: אפשר לעקוף את בדיקת העדכונים האוטומטית על ידי העברת הדגל --yes או -y לכל פקודה.

עדכונים ידניים (`cm update`)

כדי לאלץ את CodeMender לבדוק אם יש עדכונים ולהחיל אותם מיד, אפשר להריץ את הפקודה update:

cm update

הפקודה cm update:

המערכת מתעלמת מההגבלה של 24 שעות.
הורדה והחלה של העדכון באופן מיידי בלי להציג בקשה (לא אינטראקטיבי).
לא נדרש מסוף אינטראקטיבי (בטוח לסקריפטים ולניהול הגדרות).

אם ה-CLI מותקן בספריית מערכת שדורשת הרשאות מוגברות, מריצים את העדכון באמצעות sudo:

sudo cm update

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

מודל הארכיטקטורה והאבטחה

הגדרת הסביבה

הגדרת הפרויקט והרשאות IAM

ממשקי ה-API הנדרשים

תפקיד IAM מומלץ שמוגדר מראש

הורדה והתקנה של CodeMender CLI

Linux x86_64

‫Linux ARM64

macOS Intel

‫macOS Apple silicon

Windows x86_64

Windows ARM64

הגדרת פרטי הכניסה והפרויקט ב- Google Cloud

הפעלת סביבת העבודה

בדיקת הקישוריות וההרשאות של השירות

פרמטרים להגדרה (config.yaml)

Usage

הגדרות ברירת המחדל של Core

הרצה בארגז חול (sandbox)

התנהגות ארגז החול

גישה לרשת במהלך הבנייה והאימות

טיפול ביחסי תלות ברשת

הגדרת ארגז החול

בחירת רמת בידוד

Telemetry

עדכון ה-CLI

בדיקות עדכונים אוטומטיות

עדכונים ידניים (cm update)

התקנה והגדרה של ה-CLI

פרמטרים להגדרה (`config.yaml`)

עדכונים ידניים (`cm update`)