Intrusions et données
Particuliers et entreprisesCompromission de la chaîne d’approvisionnement
Supply-chain attack
L’attaque vous atteint par un produit, un composant ou un prestataire de confiance.
Je pense être concerné : que faire ?
Comprendre et agir
Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.
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 passe par un fournisseur, un composant ou une étape de fabrication dont dépendent d’autres utilisateurs. L’attaquant peut détourner un logiciel, une bibliothèque de code, une plateforme de fabrication ou une mise à jour. Une panne chez un fournisseur ne suffit pas à caractériser cette attaque : il doit y avoir un acte malveillant. La confiance accordée au produit peut faciliter le passage à travers 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.
Si vous remarquez l’un de ces signes, vérifiez la situation. Un indice isolé ne suffit pas à prouver 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.
Un produit peut porter une signature numérique valide alors que sa fabrication ou sa clé de signature a été piratée.
À vous de décider
Une mise à jour est correctement signée. Peut-elle malgré tout contenir du code malveillant ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Oui. Le processus de fabrication ou la clé de signature peut avoir été piraté. Une signature aide à vérifier la provenance technique du produit ; elle ne garantit pas qu’il soit sans danger.
Analyser un cas technique
Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».
Étude de cas fictive
Un paquet possède une attestation valide, mais vient d’une construction non autorisée
Le fichier produit a une empreinte cohérente et une attestation signée valide. Pourtant, il vient d’une branche de test et d’un constructeur non approuvé pour publier. Les contrôles cryptographiques ont fonctionné, mais les règles d’acceptation ont autorisé une provenance qui aurait dû être refusé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é.
Quelles informations comparer
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é.
Ce que ces indices ne permettent pas de conclure
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
L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.
- 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 ?
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez 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
Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.
Lire les extraits commentés (reconstitution fictive)
Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-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
Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les 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
Ces cas réels montrent où ce mécanisme a été observé. Les années indiquent quand les faits ont eu lieu. Chaque notice précise la source qui les relie à un groupe ou à une campagne.
- GroupeAPT29 / SVR
Noms et appellations : NOBELIUM
SolarWinds : une mise à jour qui transporte l’intrusion
Les attaquants modifient les produits SolarWinds Orion pour ouvrir un accès aux installations de clients. Ils passent par le fournisseur de confiance pour atteindre d’autres organisations : c’est 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
Cette sélection ne couvre pas tous les incidents. Plusieurs acteurs peuvent utiliser une même technique. Les exemples fictifs de la fiche ne décrivent les actions d’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 comprendre votre situation et trouver de l’aide : 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
