Un artefact est tout fichier produit par votre chaîne de build (binaire, image de conteneur, paquet, bibliothèque) et destiné à être déployé ou réutilisé. Cette page explique comment le construire, le stocker, le sécuriser et le distribuer proprement en DevSecOps. Public visé : développeurs et équipes plateforme qui montent une chaîne de livraison fiable. Vous y trouverez le cycle de vie complet, le choix d'un gestionnaire de dépôts (avec le paysage des licences à jour), et les contrôles de sécurité indispensables (SBOM, signature, scan).
La gestion des artefacts n'est pas un simple stockage. Un artefact mal maîtrisé, c'est une faille ouverte : code malveillant introduit par une dépendance compromise, vulnérabilité non détectée, secret oublié dans une image. Traçabilité, intégrité et contrôle d'accès sont donc au cœur de la démarche.
Guides de cette section
Section intitulée « Guides de cette section »Cette section approfondit chaque brique. Commencez par le gestionnaire de dépôts adapté à votre contexte.
Qu'est-ce qu'un artefact ?
Section intitulée « Qu'est-ce qu'un artefact ? »Un artefact est un fichier généré et consommé au cours du cycle de construction d'une application ou d'une infrastructure. Selon le contexte, ce sera :
- un binaire exécutable (ELF, EXE, JAR) ;
- une image de conteneur Docker ou Podman ;
- une bibliothèque ou un module (
.jar,.whl,.so,.dll) ; - un paquet système (
.deb,.rpm,.apk) ; - un fichier de configuration livrable (chart Helm, manifeste Kubernetes).
Le point commun : ces fichiers doivent être reproductibles, tracés et vérifiables avant d'atteindre la production. C'est ce qui distingue une chaîne de livraison DevSecOps d'un simple scp de binaires.
Le cycle de vie d'un artefact
Section intitulée « Le cycle de vie d'un artefact »Un artefact fiable ne s'improvise pas au moment du déploiement. Il se construit à travers cinq phases, chacune posant des garanties de sécurité et de qualité.
1. Planifier les exigences
Section intitulée « 1. Planifier les exigences »Le cycle commence avant la première ligne de code. Il faut identifier les contraintes de sécurité et de conformité applicables selon le secteur : ISO 27001 (management de la sécurité), RGPD (données personnelles), PCI-DSS (transactions bancaires), CIS Benchmarks et NIST (bonnes pratiques). Intégrer ces règles dès la conception coûte bien moins cher que de les rajouter en fin de cycle, et évite un blocage de mise en production pour non-conformité.
C'est aussi le moment de figer une politique de gestion des dépendances (interdiction des bibliothèques non vérifiées), des environnements sans secret en dur, et des scans en amont.
2. Développer et maîtriser le code source
Section intitulée « 2. Développer et maîtriser le code source »Les premiers artefacts naissent ici, sous forme de sources et de configurations. Un gestionnaire de code source (Git, via GitHub, GitLab ou une forge auto-hébergée) est incontournable, avec quelques réflexes non négociables :
- des branches claires et des merge requests avec revue et approbation obligatoires ;
- des scans automatiques sur chaque MR (dépendances, secrets, qualité) ;
- des messages de commit normalisés pour une traçabilité totale.
La gestion des dépendances mérite une attention particulière : c'est la première surface d'attaque de la supply chain. On y branche des scanners de vulnérabilités comme Trivy ou OWASP Dependency-Track, et des détecteurs de secrets comme Gitleaks ou TruffleHog. Vérifiez systématiquement la licence des bibliothèques et bannissez les paquets non maintenus.
Côté qualité, l'analyse statique (SonarQube, CodeQL) et le linting alimentent la boucle de rétroaction avant même l'exécution du code.
3. Construire des artefacts fiables
Section intitulée « 3. Construire des artefacts fiables »La construction transforme le code en artefacts, via un processus automatisé et reproductible. Chaque modification déclenche un pipeline CI/CD qui enchaîne test, build, analyse de sécurité et publication.
stages: [test, build, security, deploy]
build: stage: build script: - IMAGE_VERSION=$(git describe --tags) - docker build -t "$IMAGE_NAME:$IMAGE_VERSION" .
sbom: stage: build image: aquasec/trivy script: - trivy image --format cyclonedx --output sbom.json "$IMAGE_NAME:$IMAGE_VERSION" artifacts: paths: [sbom.json]
security: stage: security image: aquasec/trivy script: - trivy image --exit-code 1 --severity HIGH,CRITICAL "$IMAGE_NAME:$IMAGE_VERSION"# Signer l'image après un scan réussicosign sign --key cosign.key "$IMAGE_NAME:$IMAGE_VERSION"Dès qu'un scan révèle une vulnérabilité critique, l'artefact ne doit ni être stocké ni promu. Ceux qui passent sont signés pour prouver leur intégrité (voir plus bas).
4. Stocker et versionner
Section intitulée « 4. Stocker et versionner »Un artefact validé doit être stocké de façon sécurisée pour garantir sa disponibilité et sa traçabilité. C'est le rôle d'un gestionnaire de dépôts (repository manager), le cœur de cette section.
Chaque version reçoit un tag unique (v1.2.0, myapp:1.2), une politique de rétention supprime les artefacts obsolètes, et des scans continus rejouent l'analyse : une CVE peut apparaître des semaines après le stockage. Des outils comme Trivy ou Grype réévaluent en continu les artefacts au repos.
5. Déployer sous contrôle
Section intitulée « 5. Déployer sous contrôle »Une fois testés et validés, les artefacts sont déployés par des processus automatisés. Avant tout déploiement, on vérifie la provenance et la signature de l'artefact pour s'assurer qu'il vient d'un dépôt de confiance et n'a pas été altéré. Les stratégies rolling update, blue/green ou canary limitent l'impact d'une mauvaise version, et la configuration reste séparée du code (variables d'environnement, ConfigMaps, secrets injectés depuis un coffre-fort).
Choisir un gestionnaire de dépôts
Section intitulée « Choisir un gestionnaire de dépôts »Le repository manager centralise vos artefacts, met en cache les dépôts publics et sert de point unique à la CI/CD. Le choix se joue sur trois axes : les formats gérés, le modèle de sécurité, et désormais la licence.
| Outil | Portée | Licence |
|---|---|---|
| Pulp | Multi-formats (RPM, DEB, Python, npm, conteneurs) | GPL (100% libre) |
| Nexus | Multi-formats | Community Edition (EULA + quotas) |
| Artifactory | Multi-formats + JFrog Platform | Propriétaire (gratuit bridé) |
| Harbor | Registre d'images de conteneurs | Apache-2.0 (libre) |
Le modèle de licence est devenu un critère de décision à part entière. Depuis 2025, la version gratuite de Nexus n'est plus l'« OSS » illimité d'autrefois : elle s'appelle Community Edition, encadrée par un EULA et des quotas d'usage. Artifactory reste propriétaire avec une version gratuite bridée. Face à eux, Pulp est le seul gestionnaire multi-formats 100% open source, sans licence à accepter ni limite de composants : un argument décisif pour les contextes de souveraineté, de budget contraint ou de homelab. Pour les images de conteneurs uniquement, Harbor offre une alternative libre spécialisée.
Sécuriser l'accès et l'intégrité
Section intitulée « Sécuriser l'accès et l'intégrité »Un dépôt mal protégé devient une faille critique. Trois familles de contrôles s'imposent.
Contrôle d'accès
Section intitulée « Contrôle d'accès »Appliquez le moindre privilège avec des rôles distincts : lecture seule pour les consommateurs (serveurs de déploiement), écriture pour les équipes, administration pour la gouvernance. Bannissez les identifiants en dur et stockez les jetons dans un coffre-fort comme HashiCorp Vault, avec une rotation régulière des clés.
Signature et provenance
Section intitulée « Signature et provenance »La signature numérique prouve qu'un artefact n'a pas été altéré depuis sa production. L'outil de référence aujourd'hui est Cosign (projet Sigstore), qui remplace l'ancien Notary. On signe après un scan réussi, et on vérifie la signature avant tout déploiement.
SBOM et traçabilité
Section intitulée « SBOM et traçabilité »Un SBOM (Software Bill of Materials, l'inventaire de tous les composants d'un artefact) rend la supply chain auditable : en cas de CVE sur une bibliothèque, vous savez immédiatement quels artefacts sont concernés. Générez-le avec Syft ou Trivy, au format CycloneDX ou SPDX, et stockez-le à côté de l'artefact.
À retenir
Section intitulée « À retenir »- Un artefact (binaire, image, paquet) doit être reproductible, tracé et vérifiable avant la production.
- Son cycle de vie couvre cinq phases : planifier, développer, construire, stocker, déployer, chacune avec ses contrôles.
- Le gestionnaire de dépôts est le point central : choisissez selon les formats, la sécurité et la licence.
- Côté licence, Pulp est 100% libre (GPL), là où Nexus impose un EULA et des quotas, et Artifactory reste propriétaire.
- La sécurité repose sur trois piliers : contrôle d'accès (moindre privilège), signature (Cosign) et SBOM (Syft), avec des scans continus.