La provenance logicielle est l'enregistrement vérifié de l'origine d'un artefact logiciel, c'est-à-dire la preuve que l'artefact a été produit par le processus de build déclaré à partir du code source déclaré, et non une version modifiée insérée dans la chaîne de distribution après la fin du build légitime. La vérification de la signature du code confirme que l'artefact a été signé par le détenteur de la clé privée. La vérification de la provenance logicielle confirme que l'artefact a été construit à partir du code source attendu, par le système de build attendu, au moment attendu. Ce sont deux assurances distinctes : la première porte sur qui a signé, la seconde sur ce qui a été construit.
La compromission de l'infrastructure de distribution est le vecteur d'attaque en cause. Les éditeurs de logiciels distribuent leurs mises à jour par des serveurs web, des réseaux de diffusion de contenu et une infrastructure de mise à jour. Un attaquant qui accède à cette infrastructure de distribution peut remplacer des artefacts logiciels légitimes par des artefacts malveillants, en utilisant les propres mécanismes de livraison de l'éditeur, ses certificats HTTPS et, dans certains cas, même son infrastructure de signature si elle est accessible depuis l'environnement compromis. Le consommateur qui télécharge le logiciel depuis l'URL légitime, vérifie la connexion HTTPS et contrôle la signature avec la clé publique connue de l'éditeur peut recevoir et déployer le logiciel de l'attaquant si celui-ci avait accès à l'environnement de distribution et à l'infrastructure de signature.
Le lien avec les builds reproductibles constitue le mécanisme de vérification de la provenance. Un artefact logiciel a une provenance vérifiable si : il existe une attestation de provenance (créée par le système de build, et non par le développeur) qui enregistre le commit du code source, les entrées du build et l'environnement de build ; l'artefact peut être reconstruit de manière indépendante à partir de ce commit et produit un binaire identique ; et l'attestation de provenance est signée par le système de build et consignée dans un journal de transparence immuable. Lorsque ces conditions sont réunies, un consommateur peut vérifier que l'artefact reçu correspond à celui que le processus de build déclaré a produit à partir du code source déclaré, ce qui permet de détecter les compromissions de l'infrastructure de distribution qui produisent des artefacts différents.
Pourquoi c’est important
La vérification de la provenance logicielle est importante pour la TPRM, car les compromissions de l'infrastructure de distribution sont un vecteur d'attaque documenté : c'est le mécanisme utilisé lors de l'attaque NotPetya (via l'infrastructure de mise à jour de M.E.Doc), de l'attaque ASUS Live Update et d'incidents similaires de la chaîne d'approvisionnement. L'entreprise qui vérifie les signatures sans vérifier la provenance a confirmé que la clé de signature a été utilisée, et non que le processus de build légitime a produit ce que la clé a signé.
- Vérification de la signature acceptée comme confirmation de la provenance
- Compromission de l'infrastructure de distribution non prise en compte dans le modèle de sécurité de la livraison logicielle
- Attestation de provenance ni demandée ni vérifiée pour les mises à jour logicielles
- Reproductibilité non évaluée pour les logiciels critiques
- Vérification dans le journal de transparence absente du processus de déploiement logiciel
À quoi ressemblent les bonnes pratiques
Les programmes matures de provenance logicielle demandent des attestations de provenance SLSA pour les mises à jour logicielles critiques, vérifient les attestations dans les journaux de transparence avant le déploiement et, lorsque la criticité du logiciel le justifie, valident la reproductibilité des versions critiques à partir du code source publié.
- Attestation de provenance SLSA demandée pour les mises à jour logicielles critiques
- Vérification dans un journal de transparence avant le déploiement : Sigstore Rekor ou équivalent
- Validation de la reproductibilité pour les logiciels les plus critiques : confirmation du déterminisme des builds
- Sécurité de l'infrastructure de distribution évaluée lors de l'examen de la sécurité des builds du fournisseur
- Notification hors bande des mises à jour : vérification des mises à jour par un canal distinct de l'infrastructure de livraison
Outils
Provenance : cosign pour la vérification des attestations de provenance SLSA ; Rekor pour les requêtes dans le journal de transparence
L'outil cosign de Sigstore vérifie les attestations de provenance SLSA auprès du journal de transparence Rekor, en confirmant que l'attestation de provenance d'un artefact logiciel est valide et qu'elle a été consignée au moment attendu avec les identifiants du système de build attendu. Pour les mises à jour logicielles critiques, exécuter une vérification cosign avant le déploiement est le contrôle de provenance précis qu'exige la détection des compromissions de l'infrastructure de distribution.
Reproductibilité : infrastructure du projet Reproducible Builds ; rebuilderd pour la vérification automatisée par reconstruction
Le projet Reproducible Builds fournit des outils et une infrastructure communautaire pour vérifier que les builds logiciels sont déterministes, c'est-à-dire que le même code source produit le même binaire. Pour les logiciels d'infrastructures critiques, participer à la vérification des builds reproductibles apporte la confirmation indépendante que l'artefact distribué correspond au code source publié.
Enjeux de gouvernance
Le défi de gouvernance de la vérification de la provenance logicielle est le retard d'adoption. Les attestations de provenance SLSA, la vérification dans les journaux de transparence et les builds reproductibles sont des pratiques émergentes que de nombreux éditeurs de logiciels n'ont pas encore mises en œuvre. La solution de gouvernance consiste à imposer des exigences progressives : demander des attestations de provenance aux éditeurs de logiciels critiques et accepter la communication de leur feuille de route SLSA comme preuve de progression, tout en exigeant une vérification de provenance plus stricte pour les logiciels les plus critiques.
- Demander des attestations de provenance SLSA pour les mises à jour logicielles critiques
- Vérifier les attestations avec cosign avant de déployer les mises à jour critiques
- Évaluer la sécurité de l'infrastructure de distribution lors de l'examen de la sécurité des builds du fournisseur
- Exiger la journalisation des événements de signature dans un journal de transparence
- Mettre en place une vérification hors bande des mises à jour pour les logiciels critiques
Si vous êtes une petite équipe
Pour vos trois produits logiciels les plus critiques en matière de sécurité, ceux pour lesquels une compromission de l'infrastructure de distribution serait la plus dommageable, posez une question avant la prochaine mise à jour : produisez-vous des attestations de provenance SLSA pour vos versions, et puis-je vérifier l'attestation de cette version précise avant de la déployer ? Si la réponse est oui, utilisez cosign pour la vérifier. Si la réponse est non, il s'agit d'une lacune de provenance pour un logiciel du niveau de criticité le plus élevé. L'impossibilité de vérifier la provenance est la même exposition que celle subie par l'organisation de l'exemple d'ouverture.
- Demander une attestation de provenance SLSA avant de déployer les mises à jour critiques
- Vérifier les attestations avec cosign avant le déploiement
- Évaluer la sécurité de l'infrastructure de distribution lors de l'examen du fournisseur
- Mettre en place une vérification hors bande des mises à jour pour les logiciels critiques
Ce qu’il faut exiger
Demandez directement :
« Produisez-vous des attestations de provenance SLSA pour vos versions logicielles, et puis-je vérifier l'attestation d'une version précise avec cosign auprès du journal de transparence Sigstore Rekor pour confirmer que l'artefact distribué correspond à ce que votre système de build a produit ? »
Preuves attendues
- Attestation de provenance SLSA pour des versions précises
- Processus de vérification des entrées du journal de transparence
- Niveau SLSA et feuille de route
- Description de la sécurité de l'infrastructure de distribution
Il faut interroger un fournisseur qui confirme signer ses versions sur la vérification des attestations de provenance. La signature confirme que la clé a signé l'artefact. L'attestation de provenance confirme que le système de build a produit ce que la clé a signé. La compromission de l'infrastructure de distribution contourne la signature si l'attaquant avait aussi accès à la signature. Une attestation de provenance consignée dans un journal de transparence immuable avant la compromission est la preuve que la compromission ne peut pas effacer.
Comment le prouver
- Registres de vérification des attestations de provenance pour les mises à jour critiques
- Mise en œuvre de la vérification par journal de transparence
- Évaluation de la sécurité de l'infrastructure de distribution
- Exigence de provenance SLSA pour le niveau des logiciels critiques
À retenir
Signature : valide. Livraison : HTTPS. URL : légitime. Infrastructure de distribution : compromise 3 semaines plus tôt. Logiciel : la version de l'attaquant. L'entreprise avait vérifié tout ce que le canal de distribution légitime permet de vérifier. L'attaquant avait compromis ce canal de distribution légitime. Une attestation de provenance consignée dans un journal de transparence immuable avant la compromission est la preuve que la compromission ne peut pas falsifier après coup : elle existe avant que l'attaquant n'ait obtenu l'accès et confirme ce que le système de build a produit. La vérification de la provenance SLSA avant le déploiement est le contrôle qui détecte la compromission de l'infrastructure de distribution. La vérification de la signature ne le fait pas.