« La sécurité du développement n’est plus un sujet émergent. Elle est devenue une condition d’existence du système d’information. »
L’étude de marché publiée par l’ANSSI sur le Secure SDLC et les approches DevSecOps vient confirmer une tendance déjà perceptible sur le terrain : les organisations ont largement intégré le principe d’une sécurité “by design”, mais peinent encore à en maîtriser l’exécution opérationnelle. Derrière une offre structurée et un discours désormais bien installé, la réalité reste contrastée, parfois fragmentée, souvent incomplète.
Le concept de Secure Software Development Life Cycle (Secure SDLC) repose sur une idée simple : intégrer la sécurité à chaque étape du cycle de développement, depuis la conception jusqu’au déploiement et à la maintenance. Dans sa déclinaison DevSecOps, cette logique s’inscrit dans des chaînes d’intégration et de livraison continues (CI/CD), où les contrôles de sécurité sont automatisés et intégrés aux pipelines. Sur le papier, le modèle est cohérent. Dans les faits, sa mise en œuvre révèle des écarts significatifs.
L’étude met en évidence un marché désormais structuré, avec une diversité d’acteurs couvrant l’ensemble du cycle de développement. Les outils de SAST, DAST, SCA, les plateformes de gestion des dépendances ou encore les solutions de gestion des secrets s’inscrivent dans un écosystème dense. Cette richesse technologique peut donner l’impression d’une maturité avancée. Elle masque pourtant une difficulté récurrente : l’intégration cohérente de ces briques dans une gouvernance globale du système d’information.
« Accumuler des outils ne construit pas une posture de sécurité. »
Dans de nombreuses organisations, l’adoption du DevSecOps se traduit encore par une juxtaposition de solutions techniques, souvent pilotées par les équipes de développement elles-mêmes. La sécurité devient alors un ensemble de contrôles ajoutés en périphérie, plutôt qu’un cadre structurant intégré dès l’amont. Cette approche limite mécaniquement l’efficacité des dispositifs, en particulier lorsqu’elle ne s’accompagne pas d’une définition claire des responsabilités entre équipes développement, sécurité et exploitation.
La question des dépendances logicielles illustre parfaitement cette limite. L’étude souligne l’importance croissante des outils de Software Composition Analysis (SCA) dans la détection de vulnérabilités au sein des composants tiers. Pourtant, la capacité à maintenir une cartographie fiable des dépendances, à suivre leur cycle de vie et à gérer les mises à jour reste très inégale. Dans un contexte où une part significative du code repose sur des bibliothèques open source, cette faiblesse constitue un point de fragilité structurel.
La gestion des secrets constitue un autre angle mort fréquemment observé. Clés API, tokens d’accès, certificats : ces éléments circulent souvent dans les pipelines CI/CD avec des niveaux de contrôle hétérogènes. Leur exposition, volontaire ou accidentelle, reste une source d’incidents régulière. Là encore, l’outillage existe, mais son intégration dans les pratiques quotidiennes dépend fortement du niveau de maturité des équipes et de l’existence d’un cadre de gouvernance clair.
« Le DevSecOps n’est pas une chaîne d’outils, c’est une discipline organisationnelle. »
L’un des enseignements majeurs de l’étude réside dans cette dimension organisationnelle. L’efficacité d’une démarche Secure SDLC ne repose pas uniquement sur la qualité des solutions déployées, mais sur la capacité de l’organisation à aligner ses processus, ses rôles et ses objectifs. Cela implique notamment une implication forte des équipes de sécurité dès les phases de conception, une acculturation des développeurs aux enjeux de sécurité, et une intégration des exigences de sécurité dans les critères de validation des projets.
Dans ce contexte, la notion de “shift left” – déplacer les contrôles de sécurité le plus tôt possible dans le cycle de développement – reste encore partiellement appliquée. Elle suppose non seulement des outils adaptés, mais aussi une évolution des pratiques et des compétences. Or, cette transformation est loin d’être homogène. Elle se heurte à des contraintes opérationnelles, à des arbitrages de priorités, et parfois à une perception encore trop restrictive de la sécurité comme un facteur de ralentissement.
La montée en puissance des architectures cloud et des modèles SaaS vient complexifier davantage l’équation. Les environnements deviennent plus dynamiques, les chaînes de déploiement plus distribuées, et les responsabilités plus diffuses. Dans ce contexte, le Secure SDLC ne peut plus être envisagé comme un périmètre limité au développement applicatif. Il s’étend désormais à l’ensemble de la chaîne de valeur logicielle, incluant les infrastructures, les configurations et les services tiers.
Cette extension du périmètre renforce le besoin de pilotage. La sécurité du développement ne peut plus être traitée comme un sujet technique isolé. Elle relève d’une logique de gouvernance du système d’information, au même titre que la gestion des identités, des accès ou des vulnérabilités. Elle implique des indicateurs, des arbitrages et une vision transverse.
L’étude ANSSI met ainsi en lumière un paradoxe : alors que les pratiques DevSecOps sont largement diffusées dans les discours et les référentiels, leur mise en œuvre reste hétérogène et parfois superficielle. Le marché est prêt, les outils sont disponibles, les concepts sont compris. Ce sont désormais les capacités d’intégration, de pilotage et d’appropriation qui font la différence.
Dans cette perspective, les organisations les plus avancées ne sont pas nécessairement celles qui disposent du plus grand nombre d’outils, mais celles qui parviennent à structurer une démarche cohérente, alignée sur leurs enjeux métiers et intégrée à leur gouvernance. Le Secure SDLC devient alors un levier de maîtrise du risque, et non un simple ensemble de bonnes pratiques.
La sécurité du développement s’impose progressivement comme un marqueur de maturité du système d’information. Elle révèle la capacité d’une organisation à dépasser une approche réactive pour inscrire la sécurité dans ses processus fondamentaux. À ce titre, le DevSecOps ne constitue pas une finalité, mais un cadre. Sa valeur dépend entièrement de la manière dont il est intégré, piloté et vécu au quotidien.
source : ANSSI, S-SDLC et DevSecOps en Europe : Enjeux actuels et perspectives d’avenir
