Build Artifact Integrity
devsecopsDéfinition
La Build Artifact Integrity (intégrité des artefacts de build) désigne l'ensemble des pratiques garantissant que les artefacts logiciels produits par les pipelines de build — binaires compilés, images Docker, packages npm/pip/Maven, charts Helm — n'ont pas été modifiés ou compromis entre leur production et leur déploiement en production. L'intégrité des artefacts est un contrôle fondamental de la supply chain logicielle : un artefact compromis (code malveillant injecté post-build, image Docker substituée) peut avoir des conséquences catastrophiques lorsqu'il est déployé en production. Les vecteurs de compromission des artefacts de build incluent : la substitution dans les registres (un attaquant ayant accès au registre d'artefacts remplace une image légitime par une image malveillante portant le même tag), la compromission du pipeline de build (injection de code malveillant pendant la phase de compilation, modifiant le binaire produit sans trace dans le code source), les artefacts mis en cache compromis (les caches de build partagés peuvent contenir des artefacts modifiés), et les attaques de Man-in-the-Middle pendant le téléchargement des artefacts (le trafic n'est pas chiffré ou le certificat n'est pas vérifié). La vérification de l'intégrité des artefacts repose sur plusieurs mécanismes. Les checksums (SHA256) : chaque artefact est accompagné de son hash SHA256 ; les consommateurs vérifient ce hash avant utilisation, détectant toute modification. Les signatures cryptographiques (Cosign, GPG) : le producteur signe l'artefact avec sa clé privée ; les consommateurs vérifient la signature avec la clé publique correspondante, garantissant à la fois l'intégrité et l'authenticité (qui a signé ?). Les attestations SLSA : des déclarations signées sur le processus de production de l'artefact, permettant de vérifier non seulement que l'artefact n'a pas été modifié mais aussi qu'il a été produit par le pipeline attendu. L'enforcement de la vérification d'intégrité à l'admission (Kubernetes Admission Controllers, hook de déploiement) garantit que seuls les artefacts avec une intégrité vérifiée peuvent être déployés en production, créant un contrôle gate automatique.
Checksums et signatures : deux niveaux de garantie
Checksums (SHA256) vs signatures cryptographiques : un checksum SHA256 garantit l'intégrité (l'artefact n'a pas été modifié) mais pas l'authenticité (n'importe qui peut recalculer un checksum pour un artefact modifié et le mettre à jour). Une signature cryptographique garantit les deux : intégrité ET authenticité (seul le détenteur de la clé privée peut signer). Pour les artefacts distribués publiquement ou déployés en production, les signatures cryptographiques (Cosign/Sigstore, GPG) sont nécessaires. Les checksums seuls sont suffisants pour la vérification dans des contextes fermés et de confiance.
Workflow de vérification d'intégrité pré-déploiement
Workflow d'intégrité complet avant déploiement Kubernetes : 1) Build → image signée avec Cosign (cosign sign). 2) Scan de vulnérabilités (Trivy/Grype sur l'image). 3) Génération du SBOM + attestation SBOM (cosign attest). 4) Déploiement déclenché → admission controller Kubernetes (Kyverno/policy-controller) vérifie : signature Cosign valide ? Attestation SBOM présente ? Attestation SLSA L2+ présente ? Si toutes les vérifications passent → déploiement autorisé. Si échec → déploiement rejeté + alerte. Ce workflow garantit que seuls les artefacts du pipeline autorisé peuvent être déployés.
Immuabilité des registres et protection des tags
L'immuabilité des tags dans les registres d'images (ECR : image tag mutability IMMUTABLE, Harbor : immutable tags rule) empêche la substitution silencieuse d'une image existante : une fois l'image myapp:v1.0 poussée et signée, impossible de l'écraser avec une image différente sous le même tag. Cette protection structurelle, combinée avec la signature Cosign, garantit que la combinaison tag + signature référence toujours exactement la même image depuis le moment de sa publication initiale. Le référencement par digest (sha256) plutôt que par tag dans les manifestes Kubernetes offre une protection encore plus forte.
Ce terme vous interpelle ?
Nos experts interviennent sur toutes les thématiques de ce glossaire — pentest, conformité NIS 2 / ISO 27001, forensics, sécurité IA. Réponse sous 24h, devis gratuit et sans engagement.