Sécurité de la chaîne logistique logicielle défense : SLSA, provenance, signature

Un binaire de défense déployé est l'aboutissement d'une longue chaîne de confiance. Il a commencé comme du code source écrit par un développeur, a traversé des dizaines de dépendances open source, a été compilé sur un serveur de build, empaqueté, signé et promu vers un registre de publication avant même d'atteindre un réseau opérationnel. Chaque maillon de cette chaîne est une cible. Des adversaires étatiques ont démontré à maintes reprises que le moyen le moins coûteux d'entrer dans un réseau de défense durci n'est pas la porte d'entrée — c'est le système de build ou une dépendance de confiance, compromis en amont de sorte que le code malveillant soit livré, signé et béni, par le propre pipeline de la victime. La sécurité de la chaîne logistique logicielle est la discipline qui rend chaque maillon de cette chaîne vérifiable, afin qu'un artefact déployé puisse être tracé cryptographiquement jusqu'à un code source revu, à travers un build inviolable.

Le modèle de menace de la chaîne logistique de défense

La sécurité de la chaîne logistique commerciale et la sécurité de la chaîne logistique de défense partagent le même vocabulaire mais un adversaire différent. Une équipe commerciale s'inquiète d'une dépendance vulnérable ou d'une fuite accidentelle de secret. Une équipe de défense doit présumer un acteur bien doté qui passera des mois à pré-positionner une charge implantée : empoisonner un paquet open source populaire, compromettre un runner de build ou substituer un compilateur altéré. L'intrusion SolarWinds — où une charge implantée dans le système de build a inséré une porte dérobée dans une mise à jour de produit légitimement signée — en est l'exemple canonique, et elle a remodelé la manière dont les marchés de défense traitent l'origine des logiciels.

La surface de menace se décompose en quatre zones. La zone source couvre le système de gestion de versions et les personnes ayant accès en commit. La zone dépendances couvre chaque paquet tiers tiré dans le build, direct et transitif. La zone build couvre le service de build, ses runners et la chaîne d'outils. La zone distribution couvre la signature, le registre de publication et le déploiement. Un cadre de contrôle de chaîne logistique de défense doit traiter les quatre — durcir l'une tout en laissant une autre ouverte ne fait que déplacer le point d'entrée de l'adversaire.

Ce qui rend cela plus difficile pour la défense que pour les logiciels commerciaux, c'est le modèle de conséquences. Une mise à jour SaaS commerciale compromise peut être annulée ; une charge de firmware compromise sur une radio déployée ou une charge utile de guerre électronique peut être inatteignable, persistante et catastrophique sur le plan opérationnel. Le coût d'un seul artefact altéré est asymétrique, c'est pourquoi le cadre doit être préventif plutôt que réactif — l'objectif est de rendre un artefact malveillant incapable de franchir le pipeline tout court, et non de le détecter après déploiement. Les contrôles ci-dessous sont séquencés de la source au terrain précisément pour que chaque zone soit fermée avant que la suivante n'hérite de ses sorties.

SLSA : un modèle de maturité pour l'intégrité du build

SLSA — Supply-chain Levels for Software Artifacts — est le cadre le plus largement adopté pour raisonner sur l'intégrité du build. Il est délibérément incrémental, définissant des niveaux progressifs afin qu'une organisation puisse mesurer où elle se situe et quelle est la prochaine amélioration concrète.

Le niveau 1 exige seulement que le processus de build produise une provenance : une description de la manière dont l'artefact a été fabriqué. Cela seul détecte les erreurs et fournit une base d'analyse, mais la provenance n'est pas encore protégée contre l'altération.

Le niveau 2 exige un service de build hébergé qui génère et signe la provenance. Parce qu'un service plutôt qu'un poste de développeur produit l'attestation, l'altération par une machine individuelle compromise devient détectable.

Le niveau 3 durcit la plateforme de build elle-même : la provenance devient infalsifiable, et les builds s'exécutent dans des environnements isolés et éphémères qui ne conservent aucun état entre les exécutions. C'est le niveau auquel une dépendance compromise ou un script de build malveillant ne peut plus réécrire silencieusement ce que rapporte la provenance. Pour les logiciels de mission, le niveau SLSA 3 doit être traité comme la référence, pas comme l'aspiration.

La posture la plus exigeante — historiquement décrite comme le niveau 4 et désormais exprimée à travers des exigences de track supplémentaires — ajoute une revue à deux personnes de chaque changement et des builds hermétiques et reproductibles. Un build reproductible permet à une partie indépendante de reconstruire la même source et de confirmer, bit pour bit, qu'elle obtient le même artefact. Pour les composants proches des armes ou cryptographiques, la reproductibilité est la défense la plus forte disponible contre une chaîne d'outils altérée.

Provenance de build : comment l'artefact a été fabriqué

La provenance est le cœur de l'assurance de la chaîne logistique, et elle est fréquemment confondue avec la signature. Une signature sur un binaire prouve qui l'a publié et qu'il n'a pas changé depuis l'application de la signature. Elle ne dit rien sur la fiabilité du build qui a produit le binaire. Si un adversaire compromet le runner de build, il peut produire un artefact malveillant qui est ensuite signé de manière parfaitement légitime — la signature est valide, l'artefact est empoisonné.

La provenance comble cette lacune. Une attestation de provenance est un enregistrement signé et lisible par machine décrivant le commit source, l'identité du constructeur, les paramètres de build et les empreintes cryptographiques de chaque entrée et sortie. Le format largement utilisé est l'attestation in-toto, qui capture cela sous forme d'énoncé structuré que la plateforme de build — et non le développeur — signe. Lorsqu'un vérificateur contrôle ultérieurement l'artefact, il confirme non seulement la signature mais aussi que la provenance nomme le dépôt source attendu, le constructeur attendu et un commit qui a passé la revue.

Ce que vérifie un vérificateur

Une vérification de provenance au moment du déploiement répond à une question précise : cet artefact exact a-t-il été construit à partir de la source et du processus que nous attendons ? Le vérificateur compare l'empreinte de l'artefact à l'empreinte enregistrée dans la provenance, confirme que la provenance a été signée par la clé de la plateforme de build de confiance, et affirme que l'identité du constructeur et l'URI source correspondent à une liste d'autorisation. Une incohérence — un artefact dont la provenance nomme un constructeur inconnu, ou dont l'empreinte ne correspond pas — est rejetée avant d'atteindre un environnement opérationnel. C'est le contrôle qui aurait signalé une substitution de type SolarWinds.

La provenance permet aussi une réponse aux incidents qui serait autrement impossible. Lorsqu'une nouvelle vulnérabilité est divulguée dans un outil de build ou une dépendance, une organisation disposant d'une provenance complète peut interroger exactement quels artefacts déployés ont été produits avec le composant affecté, par quel constructeur et à partir de quel commit — transformant une estimation frénétique en une réponse précise sur le rayon d'impact. La provenance conservée pendant toute la vie opérationnelle d'un artefact n'est donc pas seulement une porte de pré-déploiement mais un actif d'audit qui porte ses fruits des années après le build.

Signature des artefacts dans les pipelines de défense

La signature reste essentielle ; elle n'est simplement pas suffisante à elle seule. La pratique moderne est la signature sans clé adossée à un journal de transparence : une clé éphémère est émise contre une identité de charge de travail vérifiée, utilisée pour signer l'artefact et ses attestations, et l'événement de signature est enregistré dans un journal de transparence public ou privé en ajout seul. Cela élimine la charge et le risque opérationnels des clés de signature à longue durée de vie résidant sur les serveurs de build.

Pour les composants les plus critiques — modules cryptographiques, chargeurs d'amorçage, tout ce qui est lié à une racine matérielle de confiance — les programmes de défense utilisent des clés matérielles conservées dans un module de sécurité matériel (HSM). La clé privée ne quitte jamais le HSM ; les opérations de signature sont effectuées à l'intérieur. Cela s'associe naturellement au démarrage sécurisé, où le firmware de l'appareil vérifie la signature de chaque étape avant de l'exécuter, étendant la chaîne de confiance de la chaîne logistique jusqu'au silicium.

Vérification des dépendances et le SBOM

La majorité du code de toute application de défense moderne n'est pas écrite par le programme — il est tiré sous forme de dépendances open source. Vérifier ces dépendances est donc le contrôle au plus fort effet de levier de toute la chaîne. Plusieurs pratiques se cumulent ici.

Épinglage et hachage. Chaque dépendance est épinglée à une version et à un hachage cryptographique précis, de sorte que l'arbre de dépendances résolu soit déterministe. Un build ne peut pas dériver silencieusement vers une version nouvelle et malveillante d'un paquet, car le hachage ne correspondrait plus.

Mise en miroir interne. Les paquets approuvés sont mis en miroir dans un registre interne, et les builds ne tirent que de ce miroir — jamais directement d'un registre public au moment du build. Cela donne au programme un point de contrôle de validation maîtrisé et brise la dépendance du build à l'accès internet, ce qui est obligatoire pour les environnements isolés (air-gapped) et classifiés.

Analyse des vulnérabilités. Chaque dépendance est analysée par rapport à des données de vulnérabilité telles que la base d'avis OSV, et les résultats conditionnent la promotion. Le produit de l'énumération de chaque composant transitif est une nomenclature logicielle (software bill of materials). Pour les exigences pilotées par les marchés désormais attachées à cet artefact, voir notre analyse de la nomenclature logicielle (SBOM) pour la défense. Le SBOM est généré dans un format standard — CycloneDX ou SPDX — et attaché à l'artefact comme attestation signée afin qu'il voyage avec le binaire.

Application des politiques : la porte d'admission

Aucun de ces contrôles n'a d'importance s'il ne bloque pas le déploiement d'un artefact non conforme. Le point d'application est la porte d'admission — l'instant situé immédiatement avant qu'un artefact ne soit promu vers un registre de publication ou déployé dans un environnement opérationnel. À cette porte, un moteur de politique effectue un ensemble de contrôles obligatoires : il vérifie la signature de l'artefact, valide la provenance par rapport aux identités de source et de constructeur attendues, contrôle le SBOM par rapport aux données de vulnérabilité et à une liste de composants interdits, et confirme que le changement a passé la revue obligatoire à deux personnes.

La règle de conception critique est que la politique doit bloquer, et non simplement signaler. Un échec courant consiste à exécuter des analyseurs plus tôt dans le pipeline qui émettent des avertissements, tandis que l'étape de promotion n'a pas de porte stricte — de sorte qu'un artefact signalé est tout de même livré lorsqu'un ingénieur passe outre sous la pression des délais. La porte d'admission doit échouer en mode fermé : si la provenance ne peut pas être vérifiée, l'artefact ne se déploie pas. Intégrer ces portes sous forme de code, revues et versionnées comme toute autre étape de pipeline, est l'extension naturelle d'une pratique DevSecOps pour la défense, où les contrôles de sécurité font partie de chaque sprint plutôt que d'un audit de pré-publication.

Exploiter la chaîne dans des environnements classifiés

Dans une enclave isolée (air-gapped) ou classifiée, toute la chaîne doit fonctionner sans accès internet. Les miroirs internes hébergent les dépendances validées, le service de build et le journal de transparence s'exécutent à l'intérieur de l'enclave, et les clés de vérification sont distribuées par des canaux approuvés. Les mises à jour du miroir de dépendances arrivent par des transferts inter-domaines contrôlés, chacune portant sa propre provenance afin que l'enclave puisse revérifier l'origine avant d'admettre un paquet. Concevoir la chaîne logistique pour un fonctionnement hors ligne dès le premier sprint — plutôt que de l'adapter après coup — fait toute la différence entre un cadre de contrôle qui survit à l'accréditation et un qui s'effondre au contact d'un déploiement classifié réel.