APP / APP-03
Sécurité CI/CD et intégration DevSecOps
Intégrer des contrôles de sécurité dans le développement et le déploiement avec des règles de blocage et d'exception compréhensibles. Le projet protège également la chaîne de livraison des logiciels elle-même : comptes, exécuteurs, secrets et autorisations.
QUAND C'EST UTILE
Une réponse ciblée
à un besoin défini.
Des mises à jour fréquentes sans vérifications systématiques, des secrets dans les pipelines, des exécutants sur-privilégiés ou une sécurité impliquée uniquement à l’issue du projet.
EN UN COUP D'ŒIL
Famille
Sécurité des applications
Engagement
Conseil et mise en œuvre
Référence
APP-03
PORTÉE ET RÉSULTATS
Ce que couvre la mission.
Portée
- Répertoires
- branches protégées
- Identités
- Permissions des coureurs
- secrets
- analyse du code/de la dépendance/de l’image
- règles d'approbation
- Artéfacts
- Promotion de l'environnement
- exceptions
Livrables
- Architecture de pipeline
- Configurations versionnées
- Critères de blocage
- procédure d'exception
- résultats pilotes
- guide pour les développeurs
- Responsabilités et indicateurs
Preuve de réception
Un contrôle d’essai est déclenché ; les secrets sont protégés ; les droits de déploiement sont limités ; la livraison autorisée est reproductible ; le blocage et les exceptions sont vérifiables ; le temps de vie du pipeline est mesuré.
LIVRAISON
Comment le travail est structuré.
Approche
Comprendre l’architecture ; sélectionner les risques et les exigences ; intégrer ou vérifier les contrôles ; tester ; les transmettre aux équipes et planifier des contrôles de régression.
Prérequis et responsabilités
Client : code, architecture, développeurs, environnement de test et accès au pipeline. Fournisseur : expertise et contrôles ; correction du code uniquement lorsqu'elle est incluse.
Facteurs de portée
Applications, langages, référentiels, dépendances, rôles, pipelines, volume et profondeur. Séparer les licences d'outils, le développement de remédiation et la maintenance.
Questions à clarifier
Qui peut modifier et gérer un pipeline ? Quels secrets permettent l’accès à la production ? Quels défauts doivent bloquer un déploiement et qui peut autoriser une exception ?
LIMITES IMPORTANTES
Installer un scanner seul n’est pas du DevSecOps. Les règles doivent être maintenues et les exceptions ne doivent pas devenir des contournements permanents.
Les contrôles s'appliquent aux versions et au périmètre convenus. Aucun scanner, SBOM ou framework ne garantit à lui seul la sécurité du logiciel livré.
EN PRATIQUE
Situations illustratives.
Ces exemples décrivent des engagements possibles et des résultats cibles. Il ne s'agit pas de références clients ni de résultats obtenus.
Scénario 01
Une équipe publie des mises à jour hebdomadaires sans vérification de dépendances. Projet : ajouter des contrôles progressivement et prioriser les résultats exploitables. Objectif : une sécurité intégrée sans un backlog de faux positifs incontrôlable.
Scénario 02
Un pipeline dispose d’un compte administrateur global. Projet : identités distinctes et restrictions des autorisations par environnement. Résultats escomptés : un test runner compromis est moins susceptible d’exposer la production, grâce à des limites vérifiées par des tests.
Contexte technologique et de référence
Exemples : les plateformes CI/CD existantes et les gestionnaires de secrets, la SAST/SCA et les vérifications d’images, selon les technologies et les licences.
L'ensemble final des technologies est convenu lors du cadrage, sur la base de l'interopérabilité, des licences, des droits d'accès et des exigences opérationnelles.
SERVICES CONNECTÉS
Construisez l'étape suivante.
Ces services peuvent compléter la mission. Ils ne sont pas inclus automatiquement.
Commencer une conversation
Clarifiez la portée.
Nous clarifierons l'objectif, les dépendances et les responsabilités de ce service avant de proposer la livraison.