Provenance SLSA : vérifier la supply chain logicielle

Savoir qu’un artefact est signé ne répond qu’à une partie du risque supply chain. Il faut aussi connaître la source, le système de build et la conformité de ces faits à la politique. La provenance SLSA fournit des métadonnées vérifiables pour cette décision.

Elle n’est utile que si un consommateur la vérifie. Accumuler des attestations sans enforcement produit de la documentation, pas une frontière de sécurité.

Ce que décrit la provenance SLSA

La spécification SLSA 1.2 définit des tracks et des garanties croissantes. Son modèle de provenance relie l’artefact au processus qui l’a produit.

Une attestation peut décrire :

• digest de l’artefact ;
• dépôt source et révision ;
• identité du builder ;
• paramètres et environnement ;
• horodatages et invocation ;
• dépendances ou materials déclarés.

Le contenu exact dépend du format et de la plateforme. La provenance reste une déclaration d’un émetteur dont il faut évaluer l’identité et la sécurité.

Les menaces couvertes

La vérification peut détecter un artefact qui :

• ne correspond pas au digest attesté ;
• vient d’un dépôt ou commit inattendu ;
• a été construit par un système non approuvé ;
• utilise des paramètres hors politique ;
• ne possède pas le niveau ou l’attestation exigés ;
• a été substitué après le build.

Elle ne prouve pas que le code est bénin, que les dépendances sont sûres ou que le builder n’a pas d’initié malveillant. Elle rend la frontière de confiance explicite.

Définir les attentes avant la vérification

Pour chaque artefact de production, documentez :

• dépôt et branche protégée autorisés ;
• identité du builder ;
• revues et tests requis ;
• workflow ou pipeline permis ;
• nom et registre de l’artefact ;
• politique minimale de provenance et signature ;
• propriétaire et expiration des exceptions.

La vérification compare l’attestation à ces attentes. « Signature valide » ne suffit pas si n’importe quel dépôt ou builder peut satisfaire la cryptographie.

Intégrer la provenance au CI/CD

Générez-la dans un service de build de confiance, pas après coup sur un poste. Liez-la au digest immuable et distribuez-la avec l’artefact.

Vérifiez :

1. à la publication dans le registre ;
2. à la promotion entre environnements ;
3. à l’admission en déploiement ;
4. lors de revues d’inventaire ;
5. pendant la réponse à incident.

Fermez par défaut les chemins matures et sensibles. En phase de déploiement, commencez en observation, comprenez les variantes puis réduisez les exceptions.

Relier la provenance aux autres preuves

Le SBOM liste les composants ; la provenance explique le build ; la signature lie identité et contenu ; la threat intelligence de vulnérabilité évalue le risque connu. Aucun ne remplace les autres.

Lorsqu’un composant est suspect, utilisez l’analyse SBOM pour retrouver les artefacts. Ajoutez la réputation des hashes et le réseau lorsqu’une compromission runtime est possible.

Le guide de vérification SLSA insiste sur digest, predicate type, builder et attentes. Journalisez ces contrôles pour expliquer chaque rejet.

Réponse à incident

Si la vérification échoue, placez l’artefact en quarantaine et préservez binaire, attestation, signature, logs du registre et du build. Déterminez s’il s’agit d’une dérive de politique, d’un pipeline cassé, d’une compromission ou d’une substitution.

Recherchez les déploiements du même digest et les autres artefacts du builder suspect. Ne reconstruisez depuis une source et un builder sains qu’après avoir compris le chemin d’échec.

Métriques

Suivez artefacts de production à provenance vérifiée, causes d’échec, exceptions sans propriétaire, builders autorisés, délai de traçage vers la source et déploiements bloqués. Mesurez la vérification, pas seulement la génération.

Conclusion

SLSA transforme « cet artefact vient probablement de notre pipeline » en affirmation vérifiable. Définissez les attentes, générez dans un builder de confiance et imposez le contrôle aux points de passage. Associez provenance et réponse SBOM aux vulnérabilités pour couvrir origine et risque.