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

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

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

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

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

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

הגדרת הסביבה

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

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

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

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

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

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

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

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

משתמש Vertex AI (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 CLI מתקשר עם מנוע החשיבה הרציונלית שמארח בענן באמצעות Interactions API, אתם צריכים להגדיר Google Cloud Application Default Credentials ‏ (ADC) בסביבה שלכם.

כדי לבצע אימות, מריצים את הפקודה הבאה ופועלים לפי ההנחיות לכניסה:

gcloud auth application-default login

אתחול סביבת העבודה

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

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

cm init

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

cm init --verify

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

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

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

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, הלקוח המקומי קורא את הקובץ הזה כדי להגדיר פרמטרים של בטיחות, להחיל עקפות מערכת ולציין אילו קבצים או ספריות להתעלם מהם.

הגדרות ברירת מחדל מרכזיות

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

‫human_confirmation: true (או require_confirmation: true)
- מה זה אומר: כברירת מחדל, CodeMender לא יכול לשנות קובץ בדיסק או להריץ פקודות של מעטפת בלי לבקש מכם במפורש [Y/n] אישור במסוף.
- למה זו הגדרת ברירת המחדל: יכול להיות ש-CodeMender ייצור תיקונים ספקולטיביים או ינסה להריץ סקריפטים של ניצול לרעה כדי לאמת פגיעות. הצורך באישור אנושי עוזר למנוע שינויים מקריים במערכת או הפעלת קוד לא מורשית בסביבה המקומית.
- מעקף: בצינורות עיבוד נתונים של CI/CD לא אינטראקטיביים, אפשר להגדיר את הערך הזה ל-false.
confirm_writes: false
- מה זה אומר: השבתה של הנחיות אינטראקטיביות לשינויים בקבצים, שמאפשרת לסוכן CodeMender לכתוב תיקוני אבטחה ולשנות קובצי מקור ישירות בדיסק המקומי בלי לחכות לאישור אנושי.
- למה זו ברירת המחדל: כברירת מחדל, CodeMender מגדיר את אמצעי הבטיחות הזה ל-true כדי לאכוף תהליך עבודה של "מעורבות אנושית". מכיוון ש-CodeMender פועל על בסיס הקוד המקומי, הוא דורש אישור ידני (לדוגמה, Write? [Y/n]) כדי למנוע מהסוכן לבצע שינויים ספקולטיביים, שגויים או הרסניים בקובצי המקור. מומלץ להשתמש באפשרות false רק כשמריצים את התוסף בארגזי חול מבודדים וחד-פעמיים או בצינורות 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 ידלג עליהם באופן אוטומטי.
- למה זו ברירת המחדל: רשימת ברירת המחדל כוללת שפות תכנות עיקריות כדי למקסם את יעילות הסריקה ולמנוע מהסוכן לבזבז זמן ואסימונים על קובצי טקסט, ארטיפקטים של בנייה או קבצים בינאריים לא רלוונטיים. עם זאת, מכיוון שאפליקציות מודרניות לרוב מטמיעות פגיעויות בקובצי תצורה של פריסה או בכלי אוטומציה, אתם יכולים להרחיב ידנית את רשימת ברירת המחדל הזו ב-config.yaml כדי לכלול קובצי תצורה, פורמטים של סקריפטים וקובצי IaC (לדוגמה, סקריפטים של Shell, קובצי XML,‏ YAML, מאפיינים ו-JSON) כדי ש-CodeMender לא יתעלם מהם בשקט.
exclude_dirs: ["node_modules", "vendor", "dist", "bin", "target", "obj", "build", ".gradle"]
- מה זה אומר: CodeMender ידלג לחלוטין על הספריות האלה במהלך סריקת סביבת העבודה וניתוח הקוד.
- למה זו ברירת המחדל: תיקיות גדולות של תלות או של בנייה מפעילות זמן אחזור עצום וקנס על טוקנים. ההחרגה שלהם כברירת מחדל מבטיחה ביצועים גבוהים וזמני תגובה מהירים. אפשר להתאים אישית את הרשימה הזו ב-config.yaml כדי לכלול או להחריג ספריות ספציפיות בהתאם למבנה הפרויקט.
project_paths: []
- הסבר: רשימה של נתיבי ספריות של-CodeMender יש גישה אליהם (קריאה/כתיבה) במהלך הפעלת הכלי.
- למה זו ברירת המחדל: כברירת מחדל, היא ריקה, מה שמגביל את הסוכן לספריית יעד הסריקה. אם תהליך הבנייה או הבדיקה שלכם דורש גישה לקבצים מחוץ לספריית היעד של הסריקה, אתם צריכים להוסיף את הנתיבים האלה כאן.
- ספריית ארטיפקטים: הסוכן יכול גם לכתוב לספריית ארטיפקטים לכל סשן (~/.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"
- מה זה אומר: מנוע ברירת המחדל של ה-AI שמפעיל את לולאות הנימוקים של הקצה העורפי.
- למה זו ברירת המחדל: gemini-3.8-flash מציע את האיזון האופטימלי בין מהירות, עלות וחשיבה אנליטית שנדרשים להצעת תיקונים. (המשתמשים יכולים לשנות את ההגדרה ל-gemini-3.1-pro כדי לקבל ניתוח מעמיק ומורכב יותר כשצריך).
vcs: { type: "git" }
- המשמעות: מגדיר את סוג מערכת לניהול גרסאות שבה נעשה שימוש בפרויקט באמצעות המפתח vcs. אם לא מגדירים את האפשרות הזו, הכלי מנסה לזהות באופן אוטומטי מאגרי Git או Mercurial. אם מגדירים את vcs ל-none, כלי ה-CLI מציג אזהרה אבל ממשיך את ההפעלה בלי פונקציונליות של VCS. הכלי CodeMender מסתמך על ההגדרה הזו כדי לנהל תיקוני אבטחה ספקולטיביים, לעקוב אחרי שינויים בבסיס הקוד ולהשתלב עם המאגר המקומי.
- למה זו הגדרת ברירת המחדל: CodeMender תומך ב-Git, ב-Mercurial או בהגדרות מותאמות אישית של מערכת בקרת גרסאות (VCS). ‫Git היא ברירת המחדל כי היא התקן בתעשייה למעקב אחר ניהול גרסאות, והיא מבטיחה שילוב חלק של השוואות בין גרסאות וביטול שינויים בטוח.
build: { command: "make build && make test" }
- מה זה אומר: מגדיר את פקודת השורת הפקודה המדויקת ש-CodeMender מריץ כדי לקמפל ולבנות את הפרויקט, וגם כדי להריץ את בדיקות היחידה והרגרסיה.
- למה זו ברירת המחדל: הגדרת פקודה לבנייה ולבדיקה היא קריטית לתהליך העבודה של האימות. הכלי מאפשר ל-CodeMender לקמפל את הפרויקט ולהריץ את חבילת הבדיקות הקיימת בסביבת ארגז החול המבודדת, כדי להוכיח שהטלאי שנוצר לתיקון פרצת האבטחה מצליח לצמצם את הסיכון לניצול הפרצה בלי לשבש את הלוגיקה הקיימת של האפליקציה.

הרצה בארגז חול

כדי להגן על תחנת העבודה מפני שינויים לא מכוונים בקבצים או תופעות לוואי לא צפויות של כלי, ה-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 ינסה לגשת לשירותי אינטרנט חיצוניים, הוא ייכשל.

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

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

טעינה מראש של רכיבים תלויים: התקנה של כל הרכיבים התלויים הנדרשים במערכת המארחת לפני הפעלת פקודות 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. הבידוד מתבצע באמצעות תכונות מובנות של מערכת ההפעלה (namespaces/seccomp, ‏ `sandbox-exec`, ‏ `AppContainer` (ניסיוני)).	קל משקל; אין תקורה של הפעלה; גישה ישירה לכלים של סביבת העבודה המקומית עם שליטה מדויקת. מומלץ לשימוש בפיתוח מקומי יומיומי.	האבטחה מתבססת על תכונות של ליבת מערכת ההפעלה; היא פחות מבודדת מ-VM מלא; התמיכה ב-Windows היא ניסיונית ויכול להיות שיידרשו הרשאות אדמין או שהיא לא תהיה תואמת לחלק מההגדרות.
קונטיינרים	הפעלת הסוכן בקונטיינר (לדוגמה, Docker).	בידוד טוב; סביבה סטנדרטית.	נדרשת סביבת זמן ריצה של קונטיינר; יכול להיות כבד; לא מאפשר אינטראקציה ישירה עם כלים במחשב המקומי.
מכונות וירטואליות מלאות	הפעלת הסוכן במכונה וירטואלית ייעודית.	אבטחה מקסימלית; בידוד מלא.	תקורה גבוהה של משאבים, הפעלה איטית, לא מאפשרת אינטראקציה ישירה עם כלים במחשב המקומי.

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`)

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

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

הגדרות ברירת מחדל מרכזיות

הרצה בארגז חול

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

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

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

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

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

Telemetry

עדכון ה-CLI

בדיקות עדכון אוטומטיות

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

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

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

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