DevSecOps : du « Shift Left » au « Secure by Design »DevSecOps: From "Shift Left" to "Secure by Design"

« Shift left » est devenu le mantra DevSecOps des débuts des années 2020 — déplacer la sécurité plus tôt dans le cycle de développement, détecter les vulnérabilités avant qu'elles n'atteignent la production. C'était la bonne direction. Mais pour la plupart des organisations, notamment dans les industries régulées, c'est resté un slogan plutôt qu'une pratique."Shift left" became the defining DevSecOps mantra of the early 2020s — move security earlier in the development lifecycle, catch vulnerabilities before they reach production. It was the right direction. But for most organisations, especially in regulated industries, it has remained a slogan rather than a practice.

Les organisations véritablement en avance ne parlent plus de déplacer la sécurité à gauche. Elles l'intègrent dans l'architecture elle-même — ce que j'appelle le Secure by Design. Ce n'est pas une distinction subtile. Cela représente une relation fondamentalement différente entre sécurité, développement et opérations.The organisations that are genuinely ahead are no longer talking about shifting left. They are building security into the architecture itself — what I call Secure by Design. This is not a subtle distinction. It represents a fundamentally different relationship between security, development, and operations.

Pourquoi le « Shift Left » seul ne suffit pasWhy "Shift Left" Alone Is Not Enough

Le shift left consiste généralement à ajouter des outils de scan de sécurité à votre pipeline CI/CD — SAST, DAST, vérification des dépendances, scan de conteneurs. Ces outils sont précieux. Mais ils sont réactifs : ils trouvent des problèmes qui existent déjà dans le code. Ils génèrent également d'énormes volumes d'alertes, que la plupart des équipes de développement ne sont pas équipées pour trier ou corriger rapidement. La fatigue aux alertes devient un risque réel.Shift left typically means adding security scanning tools to your CI/CD pipeline — SAST, DAST, dependency checking, container scanning. These are valuable. But they are reactive: they find problems that already exist in the code. They also generate enormous volumes of alerts, most of which development teams are not equipped to triage or remediate quickly. Alert fatigue becomes a real risk.

Dans les industries régulées — énergie, finance, santé — les conséquences d'un incident de sécurité en production ne sont pas seulement techniques. Elles incluent les notifications réglementaires sous GDPR (exigence de 72 heures), les obligations de déclaration d'incidents NIS2, des amendes potentielles, et dans les contextes d'infrastructures critiques, des implications pour la sécurité physique. L'approche standard « trouver dans le CI/CD » est insuffisante.In regulated industries — energy, finance, healthcare — the consequences of a production security incident are not just technical. They include regulatory notifications under GDPR (72-hour requirement), NIS2 incident reporting obligations, potential fines, and in critical infrastructure contexts, physical safety implications. The standard "find it in CI/CD" approach is insufficient.

Le pipeline Secure by DesignThe Secure by Design Pipeline

Les portes de sécurité surlignées en or ci-dessous représentent les ajouts clés au-delà du shift-left de base :Security gates highlighted in gold below represent the key additions beyond basic shift-left:

Quatre pratiques qui distinguent les leaders des retardatairesFour Practices That Separate Leaders from Laggards

1. Modélisation des menaces dès la conception1. Threat Modelling at Design Time

Avant qu'une ligne de code soit écrite, les équipes de développement devraient se demander : qu'est-ce qui pourrait mal tourner ? Qui pourrait attaquer cette fonctionnalité ? Quelles données traite-t-elle ? La modélisation des menaces (STRIDE, PASTA ou des référentiels similaires) à la phase de conception identifie les failles de sécurité architecturales qu'aucune quantité de scanning ne détectera après coup. Chez ENGIE, nous avons fait de la modélisation des menaces une porte obligatoire avant que tout nouveau composant de plateforme ne puisse entrer en développement.Before a line of code is written, development teams should be asking: what could go wrong? Who might attack this feature? What data does it handle? Threat modelling (STRIDE, PASTA, or similar frameworks) at the design phase identifies architectural security flaws that no amount of scanning will catch after the fact. At ENGIE, we made threat modelling a mandatory gate before any new platform component could enter development.

2. Security as Code

Les politiques de sécurité, les règles de pare-feu, les permissions IAM et les configurations réseau doivent être définies en code et gérées via les mêmes processus de contrôle de version et de révision que le code applicatif. Les outils de scan Infrastructure as Code (IaC) — Checkov, tfsec, KICS — détectent les mauvaises configurations avant leur déploiement. C'est particulièrement critique pour les environnements cloud où un bucket S3 mal configuré ou un rôle IAM sur-permissif peut exposer toute une organisation.Security policies, firewall rules, IAM permissions, and network configurations should be defined in code and managed through the same version control and review processes as application code. Infrastructure as Code (IaC) scanning tools — Checkov, tfsec, KICS — catch misconfigurations before they are deployed. This is particularly critical for cloud environments where a misconfigured S3 bucket or over-permissioned IAM role can expose an entire organisation.

3. Gestion des secrets3. Secrets Management

Les identifiants codés en dur dans le code source restent l'une des vulnérabilités de sécurité les plus courantes — et les plus évitables. Implémentez une solution de gestion des secrets (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) et appliquez des hooks pre-commit qui détectent et bloquent les commits d'identifiants. Faites tourner les secrets régulièrement et auditez les journaux d'accès.Hardcoded credentials in source code remain one of the most common — and most avoidable — security vulnerabilities. Implement a secrets management solution (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) and enforce pre-commit hooks that detect and block credential commits. Rotate secrets regularly and audit access logs.

4. Security Champions au sein des équipes de développement4. Security Champions Within Development Teams

Le modèle traditionnel — une équipe sécurité séparée qui révise le code comme une porte — ne passe pas à l'échelle avec la vélocité de livraison moderne. Le modèle DevSecOps exige que la connaissance de la sécurité soit distribuée au sein des équipes de développement. Les Security Champions sont des développeurs qui reçoivent une formation sécurité supplémentaire et agissent comme premier point de contact pour les questions de sécurité au sein de leur squad. Ils ne remplacent pas l'équipe sécurité ; ils étendent sa portée.The traditional model — a separate security team that reviews code as a gate — does not scale with modern delivery velocity. The DevSecOps model requires security knowledge to be distributed within development teams. Security champions are developers who receive additional security training and act as the first point of contact for security questions within their squad. They do not replace the security team; they extend its reach.

Considérations particulières pour les industries réguléesSpecial Considerations for Regulated Industries

L'énergie, les utilities et les services financiers font face à des référentiels de conformité qui interagissent directement avec la pratique DevSecOps :Energy, utilities, and financial services face compliance frameworks that interact directly with DevSecOps practice:

• NIS2 — exige des processus de sécurité documentés pour les logiciels affectant les infrastructures critiques. Votre pipeline DevSecOps est une preuve d'audit de conformité.NIS2 — requires documented security processes for software affecting critical infrastructure. Your DevSecOps pipeline is auditable evidence of compliance.
• ISO 27001 — A.14 (acquisition, développement et maintenance des systèmes) se mappe directement aux pratiques Secure by Design.ISO 27001 — A.14 (system acquisition, development and maintenance) maps directly to Secure by Design practices.
• PCI DSS (le cas échéant) — impose des normes spécifiques de codage sécurisé et des processus de gestion des vulnérabilités.PCI DSS (where applicable) — mandates specific secure coding standards and vulnerability management processes.

Implémenter correctement le DevSecOps n'est pas seulement une amélioration de la sécurité — c'est un investissement dans la conformité qui fournit des preuves d'audit démontrables.Implementing DevSecOps well is not just a security improvement — it is a compliance investment that delivers demonstrable audit evidence.

Par où commencerWhere to Start

Si votre organisation débute dans cette démarche, je recommande cette séquence : d'abord, acquérir de la visibilité (instrumenter votre pipeline avec le scan SAST et SCA de base) ; ensuite, prioriser (trier les résultats par exploitabilité et impact métier, pas seulement par score CVSS) ; puis, créer des habitudes (modélisation des menaces régulière, programme de Security Champions) ; enfin, automatiser et appliquer (policy-as-code, portes obligatoires pour les résultats critiques). C'est un parcours de 12 à 18 mois pour la plupart des organisations, pas un projet avec une date de fin fixe.If your organisation is early in this journey, I recommend this sequence: first, get visibility (instrument your pipeline with basic SAST and SCA scanning); second, prioritise (triage findings by exploitability and business impact, not just CVSS score); third, build habits (regular threat modelling, security champions programme); fourth, automate and enforce (policy-as-code, mandatory gates for critical findings). This is a 12–18 month journey for most organisations, not a project with a fixed end date.