Intrusions et données
Particuliers et entreprisesCompromission de la chaîne d’approvisionnement
Supply-chain attack
Un produit, une dépendance ou un prestataire de confiance devient le relais.
Je pense être concerné : que faire ?
Comprendre et agir
À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.
Une situation concrète
Une entreprise installe la mise à jour habituelle d’un outil de confiance. Cette fois, un composant a été modifié en amont. L’organisation reçoit donc l’attaque par une voie qu’elle utilise normalement pour se protéger.
Comment cela fonctionne
Une attaque de la chaîne d’approvisionnement vise un fournisseur, un composant ou un processus dont dépendent d’autres utilisateurs. Le maillon compromis peut être un logiciel, une bibliothèque, une plateforme de fabrication ou une mise à jour. Ce n’est pas toute panne chez un fournisseur : il faut un détournement malveillant. La confiance accordée à l’origine du produit peut aider l’attaque à franchir les contrôles habituels.
- Un maillon de confiance est compromis
Fournisseur, composant ou mise à jour.
- Le produit circule normalement
La confiance facilite son installation.
- Plusieurs utilisateurs sont atteints
Selon leurs versions et leurs droits.
Les signes qui doivent attirer l’attention
- Un fournisseur annonce une version ou un composant compromis.
- Une mise à jour déclenche des connexions ou permissions inattendues.
- Les informations de provenance ou les empreintes d’un artefact ne correspondent plus.
Ces signes invitent à vérifier la situation. Pris isolément, ils ne prouvent pas tous qu’une attaque a réussi.
Ce que vous pouvez faire
Vos premiers réflexes
Continuez les mises à jour officielles. Si l’éditeur annonce une version compromise, vérifiez la version installée et suivez ses consignes de récupération.
Si vous êtes responsable du service ou de l’organisation
Inventoriez les dépendances et prestataires. Limitez leurs droits et déployez progressivement les changements ; en cas d’alerte, retrouvez les versions réellement installées.
Une signature numérique valide n’exclut pas qu’un processus de fabrication ou une clé de signature ait été compromis.
À vous de décider
Une mise à jour est correctement signée. Peut-elle malgré tout contenir du code malveillant ?
Choisissez votre réponse et expliquez pourquoi avant de lire la correction.
Voir la réponse expliquée
Oui, si le processus de fabrication ou la clé de signature a été compromis. La signature atteste une provenance technique, pas l’innocuité du produit.
Analyser un cas technique
Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.
Étude de cas fictive
Un paquet possède une attestation valide, mais vient d’une construction non autorisée
L’artefact présente un hachage cohérent et une attestation dont la signature est valide. Pourtant, il a été produit depuis une branche de test par un constructeur non approuvé pour la publication. La vérification cryptographique a réussi ; la politique d’acceptation a laissé passer une provenance qui ne devait pas être utilisée.
Il faut vérifier ensemble le contenu identifié par le hachage, l’identité qui atteste, le dépôt, la révision, la branche et le processus de construction. Une attestation décrit une provenance selon le système qui l’a produite. Elle ne garantit pas, à elle seule, que ce système ou le code source sont dignes de confiance.
La nomenclature logicielle, ou SBOM, aide à savoir quelles dépendances sont présentes. Elle ne remplace pas les contrôles de publication et d’intégrité. En cas d’incident, retrouver les versions consommées, les environnements déployés et les accès disponibles pendant la construction. Remplacer le paquet ne suffit pas si des secrets de signature, publication ou déploiement ont aussi été exposés.
Le déroulement en schéma
Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.
- Action
Sources et dépendances
Source / dépendances vers Plateforme CI
Trace références résolues
- Action sur place
Construction isolée
Plateforme CI
Trace builder et paramètres
- Action
Artefact et provenance
Plateforme CI vers Registre
Trace digest ARTIFACT9
- Action
Candidat à promotion
Registre vers Déploiement
Trace attestation signée
- Action sur place
Vérification signature + politique
Déploiement
Trace branche et builder
- Refus / blocage
Promotion refusée
Déploiement vers Registre
Trace constructeur non approuvé
- Action
Reconstruction fiable
Plateforme CI vers Déploiement
Trace nouveau digest vérifié
Comment repérer cette attaque
Indices à rechercher
Rechercher les écarts de dépôt, de branche, de constructeur ou d’identité de publication par rapport aux règles de provenance approuvées, même pour un artefact signé.
Éléments à croiser
Vérifier d’abord l’attestation et sa chaîne de confiance, puis suivre commit → construction → empreinte de l’artefact → empreinte réellement déployée. Une étiquette de version identique n’établit pas cette égalité.
Limites de l’interprétation
Une attestation correctement signée peut provenir d’un constructeur non autorisé. Le contenu JSON seul ne prouve pas qui l’a émis et une empreinte correcte ne garantit pas que le code est sans défaut.
Comment réagir
Arrêter la publication des versions concernées et retrouver les environnements qui les utilisent. Révoquer les accès de construction ou publication compromis, puis reconstruire depuis des sources vérifiées. Contrôler les dépendances, caches et empreintes des remplacements avant de les accepter en déploiement.
Vérifier la correction
Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.
- Présenter une attestation signée avec un builder non approuvé et vérifier son refus.
- Tester qu’un digest différent ne peut être associé à une preuve valide d’un autre artefact.
- Vérifier la séparation des secrets et caches entre contribution non fiable et publication.
À vous de raisonner
L’attestation est correctement signée, mais la construction vient d’une branche de test et d’un constructeur non approuvé. Peut-on publier l’artefact sur cette seule signature ?
Formulez votre décision et l’élément qui la justifie avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Non : la politique doit vérifier l’identité du constructeur, le dépôt, la révision et la branche autorisés, en lien avec le hachage de l’artefact. La validité cryptographique atteste une provenance déclarée ; elle ne décide pas que cette provenance est acceptable pour la publication.
Consulter les détails techniques
Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.
Lire les extraits commentés — reconstitution fictive
Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-les dans les extraits.
subject- Artefact auquel la déclaration se rapporte ; son digest doit être comparé aux octets effectivement reçus.
builder- Identité déclarée du constructeur, à vérifier contre une politique de confiance et une signature, pas à croire parce qu’elle figure dans le JSON.
Provenance à comparer à la politique
JSONLes valeurs sont fictives ; la vérification de signature intervient avant l’interprétation de ces assertions.
{
"subject":[{"name":"service","digest":{"sha256":"ARTIFACT9"}}],
"predicateType":"https://slsa.dev/provenance/v1",
"predicate":{
"buildDefinition":{"buildType":"https://build.example/workflow/v1",
"externalParameters":{"repository":"org/service","ref":"refs/heads/test"}} ,
"runDetails":{"builder":{"id":"https://ci.example/untrusted-runner"}}
}
}Préparer une collecte dans votre environnement
Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des secrets.
GitHub Actions — journaux d’exécution
- Où les trouver
- Dépôt → Actions → exécution concernée → job et étapes ; télécharger les logs encore disponibles et conserver séparément les attestations et artefacts de cette exécution.
- Quoi relever
- Conserver l’exécution qui a construit l’artefact : dépôt, commit, workflow, dépendances résolues et étapes. Comparer les changements de workflow aux approbations, sans se limiter au voyant de succès.
- Accès et prérequis
- Accès au dépôt et historique non expiré. Le succès d’un job ne garantit ni l’identité de l’artefact déployé ni la légitimité de la modification qui l’a produit.
SLSA — attestation de provenance de l’artefact
- Où les trouver
- Dans l’attestation fournie avec l’artefact par la chaîne de construction. Ce document signé, quand il l’est, est une pièce de provenance, pas un journal d’exécution.
- Quoi relever
- Dans une provenance SLSA v1, comparer subject.digest à l’artefact reçu, puis buildDefinition et runDetails.builder.id à la politique attendue. Les paramètres de dépôt et de référence dépendent du buildType.
- Accès et prérequis
- Vérifier la signature, l’identité du signataire et la politique de confiance avant d’utiliser ses déclarations. Le schéma seul ne rend pas fiables le dépôt, le constructeur ou l’empreinte annoncés.
Dans l’histoire des cyberattaques
Groupes et campagnes documentés
Des faits réels pour situer ce mécanisme. Les années sont celles des faits ; chaque notice précise qui établit le lien avec le groupe ou la campagne.
- GroupeAPT29 / SVR
Repères de nommage : NOBELIUM
SolarWinds : une mise à jour qui transporte l’intrusion
Une modification malveillante des produits SolarWinds Orion ouvre un accès aux installations de clients. La confiance accordée au fournisseur devient le moyen d’atteindre d’autres organisations, ce qui caractérise une attaque de la chaîne d’approvisionnement.
Ce qu’établit la source. En avril 2021, le NCSC et ses partenaires attribuent avec une forte probabilité l’opération au SVR russe. Mandiant a ensuite rattaché l’activité SolarWinds à APT29 en 2022.
Consulter le rapport Assembling the Russian Nesting Doll: UNC2452 Merged into APT29Mandiant / Google Cloud · Publié le
Sélection de cas documentés, non exhaustive. Une technique peut être utilisée par de nombreux acteurs. Les cas fictifs de la fiche ne sont attribués à aucun de ces groupes.
Si vous pensez être concerné
- Identifiez précisément les versions et périodes concernées.
- Suivez les consignes vérifiées du fournisseur et de votre équipe de sécurité.
- Recherchez les effets sur les systèmes et secrets auxquels le composant avait accès.
Pour qualifier votre situation et être orienté : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.
Sources et repères pour approfondir
- MITRE ATT&CK — Supply Chain Compromise — attack.mitre.org
- SLSA — Supply-chain Levels for Software Artifacts — slsa.dev
- SLSA — vérification des artefacts — slsa.dev
- SLSA — menaces et protections — slsa.dev
