Son objectif est de prévenir les changements non autorisés, le vol d'identifiants, l'exécution non fiable, la substitution d'artefacts et la mauvaise utilisation de l'accès souvent puissant du pipeline aux dépôts de source et aux environnements de production.
Le pipeline doit être traité comme un plan de contrôle de production. La sécurité couvre les règles de dépôt, les services d'automatisation, les runners, les plug-ins, les secrets, les entrées de build, les magasins d'artefacts, les services de signature ou d'attestation, les approbations de publication, les identifiants de déploiement, la journalisation et la récupération — pas seulement les contrôles insérés dans un build.
Points clés
Identité et contrôle du fluxSéparer identités humaines et de workload, appliquer le moindre privilège, protéger les changements administratifs, exiger une revue ou une approbation adaptée, et restreindre quels événements, branches et acteurs peuvent déclencher des jobs privilégiés.
Exécution et dépendancesIsoler les jobs, préférer des workers éphémères, épingler ou vérifier les actions et outils externes, contraindre l'accès réseau et empêcher les contributions non fiables de recevoir des identifiants sensibles.
Intégrité des artefactsLier les sorties au source revu et aux instructions de build, consigner la provenance, protéger le matériel de signature, vérifier les artefacts avant promotion et conserver des indices inviolables pour l'investigation.
Limite importanteUn pipeline protégé n'établit pas que le logiciel qu'il publie est exempt de défauts de sécurité. Inversement, ajouter des scanners applicatifs ne sécurise ni les identités, ni les runners, ni le plan de contrôle, ni le chemin des artefacts du pipeline qui pourrait altérer ou contourner leurs résultats.