Signature de code après SolarWinds : 5 contrôles qui l'auraient stoppé

L'anatomie de SolarWinds en trois minutes

Le 13 décembre 2020, FireEye révélait qu'une mise à jour piégée de SolarWinds Orion, distribuée entre mars et juin 2020, avait compromis au moins dix-huit mille environnements clients et un sous-ensemble confirmé d'une centaine de cibles de haute valeur, parmi lesquelles les départements américains du Trésor, du Commerce, d'État, de l'Énergie et de la Justice. Le malware, identifié comme SUNBURST (UNC2452, attribué par la suite à APT29), n'exploitait pas une faiblesse cryptographique. Il exploitait la chaîne de build.

La DLL Orion SolarWinds.Orion.Core.BusinessLayer.dll livrée aux clients portait une signature Authenticode valide chaînée au certificat de code signing SolarWinds émis par Symantec. Chaque hôte Windows exécutant Orion validait cette signature et acceptait le binaire parce que, du point de vue de tous les indicateurs cryptographiques accessibles au vérificateur, il était authentique.

Les attaquants, présents dans le réseau de SolarWinds depuis au moins septembre 2019, ont modifié l'environnement de build plutôt que le dépôt source. Un implant dédié, SUNSPOT, surveillait les processus MsBuild.exe actifs pour la solution Orion, remplaçait InventoryManager.cs par une version malveillante pendant la compilation, puis restaurait le fichier d'origine une fois le build terminé pour que le système de gestion de versions n'affiche aucune différence. L'artefact compilé était signé par le serveur de build légitime à l'aide du certificat de signature de code de production, dans le cadre du workflow normal de release.

Il n'y a eu ni vol de certificat, ni extraction de clé. La clé de signature a fait exactement ce pour quoi elle avait été conçue : signer tout ce que le serveur de build lui présentait.

C'est ce schéma qui compte pour tout ce qui suit. La cryptographie fonctionnait. Les vérificateurs fonctionnaient. La confiance avait été placée au mauvais niveau — l'étape de build — alors que chaque contrôle en aval supposait qu'une signature valide signifiait un artefact valide.

Le même schéma s'est répété en mars 2023, lorsque l'application DesktopApp de 3CX a distribué un installeur piégé (CVE-2023-29059) signé avec un certificat 3CX valide après la compromission de l'environnement de build via une dépendance ffmpeg empoisonnée, attaque attribuée par Mandiant à UNC4736.

Il s'est répété en avril 2021, quand le Bash Uploader de Codecov a été modifié par des attaquants exploitant une faille de création d'image Docker pour extraire des identifiants et altérer le script que des milliers de pipelines CI téléchargeaient en toute confiance.

Il s'est répété de nouveau en mai 2023, quand Cl0p a exploité la CVE-2023-34362 dans MOVEit Transfer pour compromettre plus de deux mille organisations, en distribuant des charges utiles qui empruntaient fréquemment des canaux de mise à jour par ailleurs légitimes.

SolarWinds n'a pas été un événement aberrant. C'était la première manifestation largement médiatisée d'une classe d'attaque que le secteur n'a pas encore prise suffisamment au sérieux.

La remédiation ne peut pas se résumer à « signer plus fort ». La remédiation consiste à transformer l'événement de signature lui-même en une opération auditable, pilotée par politique, surveillée pour détecter les anomalies, avec une clé de signature physiquement incapable de produire des signatures pirates à la demande.

Cinq contrôles, appliqués conjointement, auraient relevé la barre suffisamment haut pour stopper SUNBURST à plusieurs points de la kill chain. Chacun d'eux est aujourd'hui réalisable avec des technologies sur étagère, recommandé par le NIST SP 800-218 (Secure Software Development Framework), aligné avec les Code Signing Baseline Requirements du CA/Browser Forum et de plus en plus exigé par le Cyber Resilience Act européen pour les produits comportant des éléments numériques mis sur le marché européen après décembre 2027.

Contrôle 1 : clés de signature adossées à un HSM, avec garde prouvable

Le premier contrôle est structurel. Les clés de signature de code de production doivent résider dans un module de sécurité matériel certifié FIPS 140-3 niveau 3 (ou supérieur), ne jamais exister en clair hors de cette frontière, et produire à la demande des attestations prouvant où l'opération de signature a eu lieu. Les Code Signing Baseline Requirements du CA/Browser Forum, dans la version entrée en vigueur le 1^er juin 2023, ont rendu la garde HSM obligatoire pour tous les certificats de signature de code publiquement reconnus, y compris les certificats à validation standard (anciennement OV).

Ce changement a été une réponse directe à une décennie de vols de clés de signature, d'Adobe (2012) à ASUS (2019, Operation ShadowHammer) en passant par Nvidia (2022, LAPSUS$).

Un HSM compte ici pour une raison précise : il supprime la possibilité d'exfiltrer la clé. Chaque opération cryptographique a lieu dans une frontière inviolable et résistante à l'intrusion, qui efface sa mémoire en cas d'intrusion. Pour un dispositif FIPS 140-3 niveau 3, cette frontière est validée contre la pénétration physique, la défaillance environnementale et les fuites par canaux auxiliaires. La clé est générée sur l'équipement, ne le quitte jamais et est référencée par handle. Un runner CI qui envoie une requête de signature reçoit en retour une signature ; il ne reçoit jamais la clé.

Consultez le guide HSM pour une architecture plus approfondie, et le primer sur les clés publiques et privées pour comprendre pourquoi l'asymétrie compte à ce stade.

La garde HSM seule ne stoppe pas SUNBURST, parce que SUNBURST n'a jamais essayé de voler la clé. Le serveur de build était un signataire légitime. Ce que la garde HSM permet, c'est la couche suivante : l'attestation.

Les HSM de signature modernes (Thales Luna 7, Entrust nShield 5, AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM) émettent des attestations signées qui lient l'événement de signature à l'identité demandeuse, au hash de l'artefact, à la politique qui l'a autorisé et à un horodatage inviolable. Lorsque vous pouvez prouver qu'une signature a été produite par le HSM série 12345, slot 3, handle de clé 0xABCD, sous la politique prod-orion-release-v2, demandée par l'identité workload build-runner-37 avec l'empreinte de certificat client mTLS 4F:9A:…, vous avez créé la piste de preuves que SUNBURST a tenté de contourner.

L'attestation n'a pas besoin d'être validée par le vérificateur — elle doit être ingérée par le SIEM et corrélée aux quatre contrôles suivants.

Contrôle 2 : builds reproductibles et attestations signées

SUNSPOT a inséré du code malveillant au moment du build et effacé la trace. Un build reproductible met cette classe d'attaque en échec à la source. La reproductibilité signifie qu'un arbre source donné, à un commit donné, avec une chaîne d'outils donnée, produit un artefact bit pour bit identique à chaque fois, quel que soit l'hôte de build, l'utilisateur de build, le fuseau horaire ou l'heure murale.

Si deux fermes de build indépendantes produisent le même SHA-256 de SolarWinds.Orion.Core.BusinessLayer.dll à partir du commit abc123, un attaquant qui a falsifié l'une des fermes produit un hash divergent, et cette divergence est détectable avant la signature.

Le cadre est désormais normalisé. SLSA v1.0 (Supply-chain Levels for Software Artifacts), publié par l'OpenSSF en avril 2023, définit un modèle de maturité en quatre niveaux pour l'intégrité des builds. Le niveau 1 exige un build automatisé avec provenance. Le niveau 2 ajoute une provenance source et build vérifiée par le consommateur. Le niveau 3 ajoute des builds renforcés avec des environnements de build isolés et éphémères, et une provenance non falsifiable signée par la plateforme de build. Le niveau 4, déprécié et réintégré dans le modèle en v1.0, exprimait les exigences de reproductibilité et de revue à deux personnes.

Dans un build de niveau 3, le schéma SUNSPOT est structurellement impossible parce que l'environnement de build est détruit après chaque exécution, la provenance est signée par la clé de la plateforme (et non par la clé du projet), et le mapping source-vers-artefact est lié cryptographiquement.

Les attestations in-toto, définies dans la spécification in-toto 1.0 et adoptées par Sigstore, SLSA et GitHub Artifact Attestations, en sont le format de communication. Chaque étape du pipeline de build (récupération du code source, résolution des dépendances, compilation, packaging, scan, signature) émet une déclaration signée indiquant ce qui a été consommé, ce qui a été produit et quelle politique a été appliquée.

L'artefact final est livré avec une chaîne d'attestations qu'un vérificateur peut rejouer face à la politique — non pas seulement « cette signature est-elle valide » mais « cet artefact a-t-il été produit par le bon pipeline, à partir du bon commit, avec les approbations des bons relecteurs, avec une chaîne d'outils non falsifiée ». Cosign et Rekor de Sigstore fournissent le journal de transparence public ; les déploiements privés utilisent le même modèle de données avec des journaux privés.

Pour qu'un vérificateur puisse agir sur cette base, il a besoin du type d'application de politique qui existe déjà pour la gestion automatisée des certificats : des règles déclaratives décrivant quelles provenances sont acceptables pour quelles classes d'artefacts. Kyverno, OPA Gatekeeper et Sigstore Policy Controller couvrent le chemin d'admission Kubernetes ; Windows AppLocker et la notarisation macOS gèrent le terminal. Le sujet n'est pas Sigstore contre Notary v2 contre un outillage interne. Le sujet est que l'étape de build n'est plus de confiance par défaut — elle doit faire ses preuves.

Contrôle 3 : approbation de signature par quorum

Une clé de signature qui signe tout ce que le runner CI lui envoie est une clé qui signera tout ce qu'un attaquant ayant atteint le runner CI lui enverra. Le troisième contrôle brise cette correspondance directe. Toute opération de signature de production doit exiger une approbation humaine M parmi N, appliquée au niveau de la politique HSM, avec un workflow d'approbation rattaché à un système de ticketing et à un canal d'identité hors bande.

Trois ingénieurs munis de clés de sécurité matérielles (FIDO2, carte à puce ou YubiHSM Auth) doivent chacun autoriser une signature de release candidate avant que le HSM ne déverrouille la clé pour cette seule opération, et uniquement pour le hash d'artefact spécifique soumis au workflow d'approbation.

La signature par quorum est une fonctionnalité mature, pas une idée de recherche. Thales Luna prend en charge m_of_n via le jeu de clés PED. Entrust nShield propose le quorum ACS (Administrator Card Set) et OCS (Operator Card Set). AWS CloudHSM et Azure Managed HSM exposent des politiques de quorum via leurs plans de contrôle respectifs. Google Cloud KMS prend en charge l'accès aux clés par quorum via l'approbation à deux facteurs.

La primitive cryptographique sous-jacente est typiquement le Shamir Secret Sharing ou la signature à seuil (FROST pour Schnorr, schémas ECDSA à seuil pour P-256), mais d'un point de vue opérationnel, le HSM expose une politique simple : require_approvals: 3, from_group: release_engineering, ticket_required: true, max_artifacts: 1, expiry: 30m.

Dans une attaque du type SolarWinds, la signature par quorum oblige l'attaquant soit à compromettre trois identités humaines indépendantes avec des tokens matériels dans une fenêtre de trente minutes, pendant qu'un véritable ticket de release est ouvert, soit à attendre une release légitime et à injecter l'artefact malveillant de telle sorte que le hash d'artefact soumis aux approbateurs corresponde à ce qui est effectivement signé. Cette seconde option est non triviale lorsque le portail d'approbation récupère indépendamment l'artefact et affiche son hash, l'identité du signataire, le commit source et la provenance de build issue de la chaîne d'attestations SLSA.

SUNSPOT n'aurait pas pu produire un flux d'approbation propre sans compromettre le portail d'approbation, les tokens des approbateurs et le vérificateur SLSA — trois systèmes indépendants avec trois frontières d'administration différentes.

La piste d'audit du ticketing compte autant que la piste cryptographique. Chaque opération de signature référence un ticket ; chaque ticket référence un hash d'artefact, un commit source, un identifiant d'exécution CI, le bundle de provenance SLSA et les identités des approbateurs ; chaque approbation est journalisée dans un stockage en append-only.

Quand un auditeur demande « qui a signé le build 2026.4.17.1 ? », la réponse tient en six lignes de preuves se terminant par trois noms d'approbateurs et un numéro de ticket. Quand l'investigation forensique pose la même question après un incident, les mêmes six lignes vous disent si l'approbation était légitime ou si les approbateurs ont été victimes d'ingénierie sociale. C'est la gouvernance qui passe du document papier au contrôle d'exécution appliqué.

Contrôle 4 : vérification horodatée et chemins de révocation opérationnels

Le quatrième contrôle porte sur ce qui se passe après qu'une signature a été produite et, plus important encore, après qu'une signature a été identifiée comme malveillante. Les autorités d'horodatage RFC 3161 lient une signature à un point dans le temps vérifiable. Sans horodatage, révoquer un certificat de signature de code casse chaque binaire qu'il a jamais signé, parce que les vérificateurs ne peuvent pas savoir si la signature précède la compromission. Avec un horodatage, un vérificateur peut demander « ce certificat était-il valide au moment horodaté de la signature » plutôt que « ce certificat est-il valide en ce moment » — la seule formulation qui permet la révocation sans casser les artefacts légitimes antérieurs à la compromission.

Microsoft Authenticode, Apple codesign, Java jarsigner et Sigstore Rekor prennent tous en charge les signatures horodatées ; la discipline opérationnelle consistant à toujours horodater est ce qui distingue les programmes matures des programmes immatures.

La révocation doit être un levier exploitable, et non un levier sur papier. Les mécanismes standard — révocation de certificats via les listes de révocation de certificats (CRL) et OCSP — ont été conçus pour la PKI Web et s'appliquent de manière inégale à la signature de code.

Microsoft a introduit disallowedcert.sst et le chemin de révocation Windows Defender Application Control (WDAC) précisément parce que le comportement soft-fail d'OCSP rendait la révocation de signature de code peu fiable. Apple utilise le service de notarisation comme canal de révocation. Sigstore utilise le journal de transparence Rekor pour que les signatures puissent être invalidées par référence, même quand la clé émettrice n'est pas formellement révoquée.

Chacun de ces mécanismes a une latence différente : un changement de CRL peut prendre vingt-quatre heures à se propager ; la révocation WDAC se diffuse plus vite mais nécessite une action de Microsoft ; les changements de politique Sigstore sont quasi instantanés pour les systèmes qui revalident à l'exécution.

Le correctif structurel qui lie tout cela est l'utilisation de certificats de signature à courte durée de vie. Si un certificat de signature de code est valide quinze minutes au lieu de trois ans, la révocation se réduit à l'expiration. Fulcio de Sigstore émet des certificats de dix minutes liés à des identités OIDC ; la signature persiste grâce à l'horodatage et à l'entrée du journal Rekor, mais le certificat de signature sous-jacent est déjà expiré au moment où quiconque pourrait songer à le voler.

Le même modèle s'applique dans une PKI privée : un équivalent interne de Fulcio émet un certificat de signature à courte durée de vie pour chaque release, limité à un hash d'artefact, après l'achèvement du workflow d'approbation par quorum. Compromettez la clé de signature et l'attaquant dispose de quinze minutes pour en faire quoi que ce soit — et toute signature qu'il produira échouera face à la politique, parce qu'il n'y aura ni ticket correspondant, ni chaîne d'approbation, ni provenance SLSA.

La réduction du rayon d'impact est d'environ six ordres de grandeur par rapport à un certificat de signature longue durée de trois ans.

La Certificate Transparency referme la dernière brèche. Chaque émission de certificat de signature de code se retrouve dans un journal public (ou un journal privé pour une PKI interne). Quand SolarWinds, Adobe ou 3CX renouvelle son certificat de signature de production, l'émission est publiquement observable.

Un certificat pirate émis à votre nom, par votre CA, à un imposteur, est détecté en quelques heures et non a posteriori. Les journaux CT ne sont pas une solution miracle — ils détectent l'émission, pas la signature — mais combinés aux trois contrôles précédents, ils donnent à une organisation une chance de remarquer qu'elle a été usurpée avant que les clients ne le fassent.

Contrôle 5 : détection d'anomalies sur les événements de signature

Le cinquième contrôle traite la signature comme un événement opérationnel pertinent pour la sécurité, au même titre qu'une authentification privilégiée ou un accès à une base de données de production. Chaque opération de signature émet un log structuré : horodatage, identifiant HSM, handle de clé, identité workload demandeuse, IP source, référence de ticket, hash d'artefact, taille d'artefact, chemin de déploiement cible, hash de provenance SLSA, identités des approbateurs, politique appliquée. Ces événements sont transmis en quasi temps réel à un SIEM (Splunk, Sentinel, Chronicle, Elastic) où des lignes de base sont calculées et où les anomalies déclenchent un appel hors bande.

Les lignes de base sont concrètes. Les releases de production ont lieu le mercredi entre 14 h 00 et 17 h 00 UTC, avec en moyenne trois opérations de signature par release, une taille d'artefact moyenne de quarante mégaoctets et une durée de build moyenne de vingt-deux minutes entre le déclencheur CI et la requête de signature.

Une opération de signature à 03 h 47 UTC un dimanche, avec un artefact de quatorze mégaoctets (sans ressources embarquées), provenant d'un runner CI dont le nom d'hôte ne correspond pas au pool de build de production, demandant un handle de clé réservé à la prochaine release majeure — cet événement doit déclencher un appel à l'astreinte en moins de soixante secondes.

L'injection de SUNBURST a eu lieu sur un véritable serveur de build pendant une véritable fenêtre de build, ce qui explique en partie pourquoi elle a échappé à la détection ; mais l'incohérence du hash de provenance SLSA, la taille inattendue de la DLL et l'absence de ticket de revue correspondant auraient fait échouer trois règles de corrélation au moment de la signature.

Règles SIEM raisonnables pour démarrer :

• volume de signatures par heure au-delà du p99 historique ;
• signature depuis une identité workload non vue depuis trente jours ;
• signature d'un artefact dont le hash n'est pas présent dans le magasin d'attestations de build ;
• opérations de signature non précédées d'un ticket d'approbation fermé dans les dix minutes ;
• opérations de signature ciblant un chemin de déploiement qui ne correspond pas à la liste de cibles enregistrée du projet ;
• opérations de signature depuis un runner CI dont l'empreinte de certificat client mTLS a changé au cours des vingt-quatre dernières heures.

Chaque règle est peu coûteuse. Chaque règle capte un mode de défaillance différent. Aucune n'exige un nouvel outillage qui n'existe pas déjà dans la stack moderne d'un SOC.

La raison pour laquelle ce contrôle est cinquième et non premier est qu'il dépend des quatre autres. Sans signature adossée à un HSM, il n'y a pas de source d'événements fiable. Sans provenance SLSA, il n'y a rien à corréler. Sans approbation par quorum, il n'y a pas de ticket à attendre. Sans horodatage et certificats à courte durée de vie, il n'y a pas de fenêtre étroite à borner. La détection d'anomalies est la couche qui convertit un pipeline structurellement renforcé en un contrôle de détection, et c'est ce qui transforme « nous faisons confiance au build » en « nous vérifions le build, et nous savons en quelques minutes quand quelque chose cloche ».

À quoi ressemble une SDLC « de bon niveau » en 2026

Une architecture de référence qui rassemble les cinq contrôles ressemble à ceci. Le code source réside dans un dépôt Git avec des commits signés (gitsign de Sigstore, ou commits signés GPG/SSH avec politique verified-committer) et une protection de branche imposant l'approbation par deux relecteurs.

Un merge vers main déclenche un build éphémère et hermétique dans un runner isolé (GitHub Actions avec des workflows réutilisables épinglés par SHA de commit, GitLab CI avec des runners renforcés, Tekton Chains, Buildkite hébergé, ou auto-hébergé sur Kata Containers). Le runner n'a aucun accès entrant, récupère les dépendances via un proxy à attestation vérifiée et produit un artefact accompagné d'un bundle de provenance in-toto/SLSA niveau 3 non signé.

L'artefact et le bundle sont publiés sur un registre de staging immuable. Un ticket de release est ouvert dans le système de workflow (Jira, ServiceNow, Linear) avec le hash de l'artefact et le bundle de provenance attachés.

Le responsable de release confie le ticket à un quorum de trois ingénieurs de release munis de tokens FIDO2. Chacun vérifie indépendamment le hash de l'artefact, le commit source et la chaîne SLSA via le portail d'approbation, puis signe l'approbation.

La troisième approbation déclenche le moteur de politique HSM pour émettre un certificat de signature à courte durée de vie (Fulcio ou équivalent interne), valide dix minutes, lié au hash de l'artefact, et signe l'artefact avec un horodatage RFC 3161. L'événement de signature, la provenance et les entrées Authenticode/Cosign/Rekor résultantes sont journalisés vers le SIEM et vers un journal de transparence.

Les vérificateurs en aval — contrôleurs d'admission Kubernetes en production, terminaux Windows avec WDAC, vérifications de notarisation macOS, gestionnaires de paquets — ne se contentent pas de valider la signature. Ils valident que la signature dispose d'une entrée correspondante dans un journal de transparence, que cette entrée référence un bundle de provenance SLSA, que la provenance liste un builder approuvé, que le hash de l'artefact correspond et que l'horodatage tombe dans la fenêtre de validité courte du certificat.

L'ensemble du pipeline, du commit au vérificateur, repose sur une PKI organisationnelle qui émet des identités workload à courte durée de vie, des certificats de signature et des identifiants client HSM, avec un cycle de vie automatisé plutôt que ticketé.

Aucun de ces composants n'est spéculatif. SLSA v1.0 est un standard publié. Sigstore est disponible en GA et a été adopté par Kubernetes, Python (PyPI), npm et le noyau Linux. L'exigence HSM du CA/Browser Forum est obligatoire depuis 2023. RFC 3161 a vingt-cinq ans. Les modules FIPS 140-3 sont livrés par tous les principaux fournisseurs de HSM.

L'écart entre un pipeline de signature typique de l'ère 2020 et l'architecture de référence 2026 est un travail d'ingénierie et de discipline de gouvernance, pas d'invention. C'est la partie encourageante. La partie décourageante est que la plupart des pipelines de signature en production aujourd'hui ressemblent plus à SolarWinds 2020 qu'à SLSA niveau 3 2026.

Le rôle d'Evertrust

Les cinq contrôles partagent un socle commun : chacun dépend d'un cycle de vie de certificats et de clés géré, automatisé et auditable. La clé de signature adossée au HSM a besoin d'une CA pour émettre et faire tourner son certificat. Les certificats de signature à courte durée de vie nécessitent une API d'émission capable de produire des milliers d'identifiants de dix minutes par jour. Les tickets de signature par quorum exigent des identités certificat pour chaque approbateur. Les règles de détection d'anomalies ont besoin d'un flux d'événements normalisé depuis chaque CA, HSM et point de signature. L'exigence de transparence nécessite l'intégration des journaux CT par défaut, et non en option.

Evertrust fournit ce socle. Diffusez les événements de vos HSM et CA de signature, automatisez l'émission de certificats à courte durée de vie pour les workloads de build et de release, gouvernez la politique qui lie les clés de signature aux workflows d'approbation, et exportez la piste d'audit exigée par le CRA, NIS2 et les futures exigences du sous-comité CSC sur la signature de code.

Les cinq contrôles ci-dessus, c'est ce qui permet de stopper le prochain SUNBURST. La gestion continue, automatisée et pilotée par politique du cycle de vie des certificats et des clés, c'est ce qui rend ces contrôles opérables à l'échelle d'une organisation d'ingénierie moderne.

Explorez Evertrust Certificate Lifecycle Management pour voir comment les pièces s'emboîtent.