Comment la signature d'artefacts et la provenance protègent-elles la chaîne d'approvisionnement logicielle ?
Réponse courte
La signature lie cryptographiquement un artefact à son producteur, afin que les consommateurs puissent vérifier qu'il n'a pas été altéré ou substitué. La provenance est une métadonnée signée décrivant comment, où et à partir de quelle source l'artefact a été construit. Ensemble — via des outils comme Sigstore pour la signature sans clé et le framework SLSA pour les niveaux de provenance — ils permettent à un déployeur de vérifier qu'une image provient du pipeline et de la source attendus, déjouant l'altération et les attaques par substitution de dépendances.
Les attaques de la chaîne d'approvisionnement fonctionnent en vous faisant exécuter quelque chose en quoi vous avez confiance mais que vous ne devriez pas — un binaire altéré, un build malveillant, une dépendance substituée. La signature et la provenance vous permettent de vérifier la confiance au lieu de la présumer.
Signature : qui a fait ceci ?
La signature d'artefacts produit une signature cryptographique sur un artefact (une image conteneur, un paquet, un binaire). Un consommateur vérifie la signature pour confirmer deux choses : l'artefact provient du producteur attendu, et il n'a pas été altéré depuis la signature. La signature traditionnelle peine avec la gestion des clés — les clés privées à longue durée de vie sont perdues ou volées. Sigstore répond à cela avec la signature sans clé : il utilise des certificats à courte durée de vie liés à une identité OIDC (par ex. l'identité d'un workflow CI) et enregistre les signatures dans un journal de transparence public (Rekor), donc il n'y a pas de clé à long terme à protéger et chaque signature est auditable.
Provenance : comment cela a-t-il été fait ?
Une signature seule ne vous dit pas comment un artefact a été construit. La provenance est une métadonnée signée et inviolable qui atteste du build : quel commit source, quel builder, quelles entrées et paramètres. Le framework SLSA définit des niveaux croissants de provenance et d'intégrité du build, vous pouvez donc dire « cet artefact a une provenance vérifiable issue d'un pipeline de build durci et infalsifiable ».
Mise en pratique
Les deux se combinent au moment du déploiement/de l'admission : une politique vérifie que l'image est signée par l'identité attendue et porte une provenance pointant vers le dépôt source et le builder attendus. Un attaquant qui substitue une image malveillante ne peut pas falsifier cela, donc le déploiement est bloqué. C'est ce qui déjoue des incidents comme un artefact de build empoisonné se glissant en production.
Ce que recherchent les recruteurs
Ils veulent que la signature (intégrité + identité) et la provenance (origine du build) soient clairement distinguées, la connaissance du modèle sans clé de Sigstore et des niveaux SLSA, et le point d'application « vérifier à l'admission ».
Questions de suivi probables
- Quel problème résout la signature sans clé de Sigstore ?
- Que représentent réellement les niveaux SLSA ?
- À quel endroit du flux de déploiement vérifie-t-on les signatures et la provenance ?