"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.
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.
Why "Shift Left" Alone Is Not Enough
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.
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.
The Secure by Design Pipeline
Security gates highlighted in gold below represent the key additions beyond basic shift-left:
Four Practices That Separate Leaders from Laggards
1. Threat Modelling at Design Time
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
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. Secrets Management
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 Within Development Teams
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.
Special Considerations for Regulated Industries
Energy, utilities, and financial services face compliance frameworks that interact directly with DevSecOps practice:
- NIS2 — requires documented security processes for software affecting critical infrastructure. Your DevSecOps pipeline is auditable evidence of compliance.
- ISO 27001 — A.14 (system acquisition, development and maintenance) maps directly to Secure by Design practices.
- PCI DSS (where applicable) — mandates specific secure coding standards and vulnerability management processes.
Implementing DevSecOps well is not just a security improvement — it is a compliance investment that delivers demonstrable audit evidence.
Where to Start
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.