# DevSecOps : 10 bonnes pratiques pour intégrer la sécurité dès le départ > Dix bonnes pratiques DevSecOps pour intégrer la sécurité dans la CI/CD : SAST, DAST, supply chain logicielle, conteneurs durcis et culture partagée en 2026. - Date : 2021-10-11 - Lecture : 9 min - Catégorie : devsecops - Tags : DevSecOps, Sécurité applicative, CI/CD, SAST, DAST, Supply chain logicielle, SBOM, Infrastructure as code, Sécurité des conteneurs - URL : https://www.adservio.fr/insights/articles/devsecops-10-bonnes-pratiques ## L'essentiel - Le DevSecOps intègre la sécurité tout au long du cycle de vie applicatif : chaque commit, chaque image et chaque configuration devient un point de contrôle automatisé. - Les fondations techniques : contrôles automatisés dans la CI/CD, analyse statique (SAST), analyse dynamique (DAST) et analyse de composition logicielle avec atteignabilité. - La chaîne d'approvisionnement logicielle est devenue un front majeur : SBOM à chaque build, signatures Sigstore, attestations SLSA et vérification à l'admission. - Côté exécution : infrastructure as code gouvernée par des politiques, conteneurs durcis (images minimales, non-root, lecture seule) et détection runtime via eBPF. - Les pratiques d'organisation : déploiements progressifs avec rollback automatique, exercices red team et purple team, gestion unifiée des vulnérabilités et des incidents. - C'est la culture, security champions, threat modeling, post-mortems sans blâme et indicateurs suivis, qui fait tenir les neuf autres pratiques dans la durée. ## Pourquoi le DevSecOps s'impose dans les organisations en 2026 Le DevSecOps comble le fossé entre les développeurs, la sécurité et les opérations en intégrant la sécurité tout au long du cycle de vie applicatif, au lieu d'en faire une réflexion de dernière minute. La sécurité cesse d'être une étape isolée, confiée à une équipe distante qui intervient après coup, pour devenir une responsabilité partagée à chaque phase : conception, développement, build, déploiement et exploitation. Chaque commit, chaque image de conteneur et chaque configuration d'infrastructure devient un point de contrôle automatisé plutôt qu'un angle mort. Le contexte de 2026 rend cette approche incontournable. Les attaques contre la chaîne d'approvisionnement logicielle se sont multipliées, au point que l'OWASP a introduit une catégorie dédiée, Software Supply Chain Failures, dans l'édition 2025 de son Top 10. Le code généré par les assistants IA accélère les livraisons mais augmente mécaniquement le volume à vérifier. Et la pression réglementaire s'intensifie : le Cyber Resilience Act européen impose dès septembre 2026 le signalement des vulnérabilités activement exploitées, tandis que NIS2 et DORA étendent les exigences de sécurité opérationnelle à des pans entiers de l'économie. Greffer la sécurité en fin de cycle n'est donc plus tenable, ni techniquement ni réglementairement. Les dix bonnes pratiques qui suivent s'organisent en trois blocs complémentaires : automatiser les contrôles dans la chaîne de livraison, sécuriser les artefacts et les environnements d'exécution, et ancrer durablement la sécurité dans l'organisation elle-même. ## Automatiser les contrôles de sécurité dans la CI/CD La première pratique consiste à faire du pipeline CI/CD le point de passage obligé de tous les contrôles : analyse à chaque commit, retour au développeur en quelques minutes, blocage des fusions en cas de vulnérabilité critique. Les hooks de pre-commit et les extensions d'IDE détectent les secrets exposés et les motifs dangereux avant même que le code n'atteigne le dépôt, là où la correction coûte le moins cher. Un contrôle qui arrive une semaine après l'écriture du code arrive toujours trop tard. L'objectif est une boucle de retour courte : un développeur qui voit l'alerte pendant que le contexte est encore frais la corrige en quelques minutes, pas dans un sprint planifié trois semaines plus tard. ### SAST : analyser le code au plus près du développeur La deuxième pratique est l'analyse statique (SAST), qui examine le code source sans l'exécuter. Les outils modernes comme Semgrep ou CodeQL privilégient des règles précises et personnalisables plutôt que des centaines d'alertes génériques, et les assistants IA aident désormais à trier les résultats puis à proposer des correctifs contextualisés. L'enjeu n'est plus de détecter, mais de conserver un signal exploitable : un scanner que les équipes ignorent parce qu'il crie trop fort ne protège personne. ### DAST et analyse des dépendances : tester l'application vivante La troisième pratique combine l'analyse dynamique (DAST), qui éprouve l'application en cours d'exécution face aux risques du Top 10 OWASP, dont le contrôle d'accès défaillant, toujours en tête du classement 2025, et l'analyse de composition logicielle (SCA), qui inventorie les dépendances vulnérables. Les outils de SCA récents intègrent une analyse d'atteignabilité : ils distinguent les vulnérabilités réellement exploitables depuis votre code de celles présentes dans une bibliothèque jamais appelée, ce qui divise le bruit par dix. La chaîne de livraison est elle-même une cible de choix : des identifiants CI volés ou un runner compromis suffisent à injecter du code malveillant en production sans toucher au dépôt. Les mêmes exigences s'appliquent donc au pipeline : runners éphémères détruits après chaque exécution, permissions minimales et de courte durée obtenues via des jetons OIDC plutôt que des secrets statiques stockés dans la configuration, et journalisation complète des exécutions pour pouvoir reconstituer, en cas de doute, qui a construit quoi, quand et à partir de quel commit. > À lire aussi : [Shift left testing : bénéfices et types](https://www.adservio.fr/insights/articles/shift-left-testing-benefices): Le shift left testing déplace les tests vers l'amont du développement pour détecter les défauts moins cher : quatre approches, outillage IA et lien DevSecOps en 2026. ## Sécuriser la chaîne d'approvisionnement logicielle et l'infrastructure as code La quatrième pratique répond à la menace la plus dynamique de la décennie : la compromission de la chaîne d'approvisionnement. Chaque build doit produire un SBOM, l'inventaire de ses composants, au format CycloneDX ou SPDX, signer ses artefacts avec Sigstore et générer des attestations de provenance conformes au cadre SLSA. Ces preuves cryptographiques permettent de vérifier, au moment du déploiement, qu'une image provient bien de votre chaîne de build et non d'un dépôt compromis ou d'un poste de développeur détourné. ### Vérifier la provenance au moment du déploiement La signature ne vaut que si elle est vérifiée : des contrôleurs d'admission Kubernetes refusent les images non signées ou dépourvues d'attestations, fermant la porte aux artefacts injectés hors pipeline. Côté dépendances, l'épinglage des versions, les registres internes en proxy et la mise en quarantaine des paquets récemment publiés limitent les attaques par confusion de dépendances et par typosquatting, devenues monnaie courante sur les écosystèmes npm et PyPI. La cinquième pratique automatise l'infrastructure via l'infrastructure as code, avec Terraform ou OpenTofu, et la soumet aux mêmes exigences que le code applicatif : analyse des configurations avant application, politiques exprimées en policy as code avec Open Policy Agent ou Kyverno, et détection de dérive entre l'état déclaré et l'état réel du cloud. Une mauvaise configuration reste l'une des premières causes d'incident : l'OWASP a d'ailleurs hissé la Security Misconfiguration au deuxième rang de son classement 2025. > À lire aussi : [Sécurité du cloud : défis et solutions](https://www.adservio.fr/insights/articles/securite-cloud-defis-et-solutions): Les grands défis de la sécurité du cloud et les pratiques qui rendent le contrôle à vos équipes, à mesure que les données quittent vos murs. ## Durcir les conteneurs et maîtriser les déploiements progressifs La sixième pratique modernise le déploiement des correctifs. Au-delà du blue/green, qui maintient deux environnements de production pour basculer le trafic sans interruption, les déploiements canari exposent d'abord un correctif à une fraction du trafic, avec rollback automatique si les métriques d'erreur ou de latence franchissent le seuil défini. Corriger vite sans casser la production devient un processus outillé et répétable, pas un pari tenté un vendredi soir. ### Des conteneurs durcis par défaut La septième pratique durcit les environnements conteneurisés : images minimales ou distroless pour réduire la surface d'attaque, exécution sans privilèges root, systèmes de fichiers en lecture seule, scans de vulnérabilités continus avec des outils comme Trivy ou Grype, et politiques d'admission qui rejettent tout conteneur non conforme avant qu'il n'atteigne le cluster. Ce socle transforme chaque déploiement en état connu et vérifiable. En production, la détection s'appuie de plus en plus sur eBPF : des outils comme Falco ou Tetragon observent les appels système au niveau du noyau et repèrent les comportements suspects, processus inattendu, élévation de privilèges, connexion sortante anormale, sans instrumenter les applications ni dégrader leurs performances. Le durcissement statique et la détection à l'exécution se complètent : l'un réduit la surface d'attaque, l'autre surveille ce qui reste. La gestion des secrets complète ce durcissement : plus aucun mot de passe ni clé d'API dans le code ou dans des variables d'environnement en clair, mais un coffre centralisé comme Vault ou les gestionnaires natifs des fournisseurs cloud, des identités de charge de travail éphémères et une rotation automatique des identifiants. La détection des secrets exposés dans les dépôts, suivie de leur révocation immédiate, pas seulement de leur suppression de l'historique, reste l'un des contrôles au meilleur rapport effort/impact de toute la chaîne. ## Éprouver ses défenses : red team, purple team et incidents unifiés La huitième pratique confronte les défenses à des attaques réalistes : exercices opposant une red team offensive à une blue team défensive, complétés par des séances de purple teaming où les deux collaborent pour améliorer concrètement les règles de détection, et par des programmes de bug bounty qui mobilisent des chercheurs externes en continu. Ces exercices révèlent ce que les scanners ne voient pas : les chaînes d'exploitation qui combinent plusieurs faiblesses mineures en une compromission majeure. La neuvième pratique unifie la gestion des incidents et des vulnérabilités : les défauts de sécurité vivent dans le même backlog que les défauts fonctionnels, avec des SLA de remédiation par niveau de sévérité et des métriques suivies dans la durée, délai moyen de correction, taux de vulnérabilités traitées dans les délais, dette de sécurité résiduelle. Ce qui n'entre pas dans le flux de travail normal des équipes finit toujours par être ignoré ; ce qui y entre se corrige comme n'importe quel bug. Ces deux pratiques se renforcent mutuellement : les enseignements des exercices offensifs alimentent le backlog unifié avec des scénarios concrets, et les métriques de remédiation mesurent si l'organisation progresse réellement d'un exercice à l'autre. Une red team qui retrouve la même faille deux ans de suite ne révèle pas un problème technique, mais un défaut de gouvernance, et c'est précisément ce genre de signal que la direction doit voir. ## Faire vivre une culture sécurité partagée au quotidien La dixième pratique, la plus structurante, est culturelle : diffuser un état d'esprit où la sécurité est une priorité quotidienne plutôt qu'une contrainte subie. Concrètement, cela passe par un réseau de security champions au sein des équipes produit, des ateliers de threat modeling organisés dès la conception des fonctionnalités sensibles, et des post-mortems sans recherche de coupable qui traitent chaque incident de sécurité comme une occasion d'apprendre plutôt que de sanctionner. Ces relais de proximité désamorcent la vieille opposition entre l'équipe sécurité qui dit non et les équipes produit qui contournent : la décision se prend là où le code s'écrit. ### Mesurer la culture autant que l'outillage Une culture se pilote avec des indicateurs : part des équipes disposant d'un champion formé, couverture des pipelines par les contrôles automatisés, temps de remédiation par sévérité, taux de récurrence des mêmes classes de vulnérabilités. C'est cette culture, plus que n'importe quel outil, qui fait tenir les neuf autres pratiques dans la durée, un scanner s'achète en une semaine, une habitude se construit sur des trimestres. > À lire aussi : [DevOps vs DevSecOps : différences, outils et bonnes pratiques](https://www.adservio.fr/insights/articles/devops-vs-devsecops-differences): DevOps vs DevSecOps : différences concrètes, shift-left, sécurité de la supply chain logicielle et impact de l'IA générative sur le cycle de vie applicatif. ## L'approche Adservio : la sécurité comme valeur par défaut Chez Adservio, le DevSecOps n'est pas un empilement d'outils mais une discipline d'ingénierie : contrôles automatisés dans la CI/CD, analyse statique et dynamique calibrée pour rester exploitable, chaîne d'approvisionnement signée et vérifiée, infrastructure as code gouvernée et conteneurs durcis, le tout tracé, mesuré et défendable devant un auditeur ou un régulateur. Notre conviction : la sécurité gagne à être une valeur par défaut, pas une couche ajoutée en fin de projet. Nous aidons les organisations à prioriser ces dix pratiques selon leur maturité réelle, à les outiller sans multiplier les consoles, puis nous transférons la maîtrise aux équipes internes pour que la culture de sécurité vive en autonomie, bien après la fin de la mission. ## FAQ ### Qu'est-ce que le DevSecOps ? Le DevSecOps comble le fossé entre développeurs, sécurité et opérations en intégrant la sécurité tout au long du cycle de vie applicatif, conception, build, déploiement, exploitation, plutôt que de la traiter comme une étape finale ajoutée après coup. ### Quelle différence entre SAST, DAST et SCA ? Le SAST analyse le code source sans l'exécuter, le DAST teste l'application en cours d'exécution face aux risques du Top 10 OWASP, et la SCA inventorie les dépendances vulnérables, idéalement avec une analyse d'atteignabilité pour ne remonter que les failles réellement exploitables. ### Comment sécuriser la chaîne d'approvisionnement logicielle ? En produisant un SBOM à chaque build, en signant les artefacts avec Sigstore, en générant des attestations de provenance conformes au cadre SLSA, puis en vérifiant ces preuves à l'admission dans le cluster pour bloquer tout artefact issu d'une chaîne compromise. ### Que change le Cyber Resilience Act pour les équipes DevSecOps ? Le règlement européen impose dès septembre 2026 le signalement des vulnérabilités activement exploitées, puis des exigences complètes de sécurité par conception. Les organisations doivent donc tracer leurs composants, leurs correctifs et leurs processus de remédiation. ### Pourquoi la culture est-elle la pratique la plus importante ? Parce que les outils ne tiennent que si les équipes les utilisent : security champions, threat modeling, post-mortems sans blâme et indicateurs suivis transforment la sécurité en réflexe quotidien, ce qui fait durer les neuf autres pratiques.