DevSecOps: 10 best practices for building security in from the start

SECTION 1

Why DevSecOps has become essential for organisations in 2026

DevSecOps bridges the gap between developers, security and operations by integrating security throughout the application lifecycle, instead of treating it as a last-minute afterthought. Security stops being an isolated step, handed to a distant team that intervenes after the fact, and becomes a shared responsibility at every phase: design, development, build, deployment and operations. Every commit, every container image and every infrastructure configuration becomes an automated control point rather than a blind spot.

The 2026 context makes this approach unavoidable. Attacks against the software supply chain have multiplied, to the point that OWASP introduced a dedicated category, Software Supply Chain Failures, in the 2025 edition of its Top 10. Code generated by AI assistants speeds up delivery but mechanically increases the volume to verify. And regulatory pressure keeps rising: the European Cyber Resilience Act mandates the reporting of actively exploited vulnerabilities from September 2026, while NIS2 and DORA extend operational security requirements to entire sectors of the economy.

Bolting security onto the end of the cycle is therefore no longer tenable, technically or legally. The ten best practices that follow are organised into three complementary blocks: automating controls in the delivery pipeline, securing artifacts and runtime environments, and anchoring security durably in the organisation itself.

SECTION 2

Automate security controls in the CI/CD pipeline

The first practice is to make the CI/CD pipeline the mandatory checkpoint for every control: analysis on every commit, feedback to the developer within minutes, and merges blocked whenever a critical vulnerability appears. Pre-commit hooks and IDE extensions catch exposed secrets and dangerous patterns before the code even reaches the repository, where fixing is cheapest. A control that arrives a week after the code was written always arrives too late. The goal is a short feedback loop: a developer who sees the finding while the context is still fresh fixes it within minutes, not in a sprint planned three weeks later.

### SAST: analysing code as close to the developer as possible

The second practice is static analysis (SAST), which examines source code without executing it. Modern tools such as Semgrep or CodeQL favour precise, customisable rules over hundreds of generic alerts, and AI assistants now help triage the findings and propose contextualised fixes. The challenge is no longer detection but keeping the signal actionable: a scanner that teams ignore because it shouts too loudly protects no one.

### DAST and dependency analysis: testing the living application

The third practice combines dynamic analysis (DAST), which exercises the running application against the OWASP Top 10 risks, including broken access control, still at the top of the 2025 ranking, with software composition analysis (SCA), which inventories vulnerable dependencies. Recent SCA tools include reachability analysis: they distinguish vulnerabilities actually exploitable from your code from those sitting in a library that is never called, cutting the noise tenfold.

The delivery chain is itself a prime target: stolen CI credentials or a compromised runner are enough to inject malicious code into production without ever touching the repository. The same requirements therefore apply to the pipeline itself: ephemeral runners destroyed after every execution, minimal and short-lived permissions obtained through OIDC tokens rather than static secrets stored in the configuration, and complete logging of executions so you can reconstruct, whenever in doubt, who built what, when and from which commit.

@cite:shift-left-testing-benefices

SECTION 3

Secure the software supply chain and infrastructure as code

The fourth practice addresses the most dynamic threat of the decade: supply chain compromise. Every build should produce an SBOM, the inventory of its components, in CycloneDX or SPDX format, sign its artifacts with Sigstore and generate provenance attestations aligned with the SLSA framework. These cryptographic proofs make it possible to verify, at deployment time, that an image genuinely comes from your build chain and not from a compromised repository or a hijacked developer workstation.

### Verifying provenance at deployment time

A signature is only worth what its verification enforces: Kubernetes admission controllers reject unsigned images or images without attestations, closing the door to artifacts injected outside the pipeline. On the dependency side, version pinning, proxied internal registries and quarantining freshly published packages limit dependency confusion and typosquatting attacks, which have become commonplace across the npm and PyPI ecosystems.

The fifth practice automates infrastructure through infrastructure as code, with Terraform or OpenTofu, and holds it to the same standards as application code: configuration scanning before apply, policies expressed as policy as code with Open Policy Agent or Kyverno, and drift detection between the declared state and the actual state of the cloud. Misconfiguration remains one of the leading causes of incidents: OWASP moved Security Misconfiguration up to second place in its 2025 ranking.

@cite:securite-cloud-defis-et-solutions

SECTION 4

Harden containers and master progressive deployments

The sixth practice modernises how patches are shipped. Beyond blue/green, which maintains two production environments to switch traffic without downtime, canary deployments first expose a fix to a fraction of traffic, with automatic rollback if error or latency metrics cross the defined threshold. Fixing fast without breaking production becomes a tooled, repeatable process, not a bet taken on a Friday evening.

### Containers hardened by default

The seventh practice hardens containerised environments: minimal or distroless images to shrink the attack surface, execution without root privileges, read-only filesystems, continuous vulnerability scanning with tools such as Trivy or Grype, and admission policies that reject any non-compliant container before it reaches the cluster. This baseline turns every deployment into a known, verifiable state.

In production, detection increasingly relies on eBPF: tools such as Falco or Tetragon observe system calls at the kernel level and spot suspicious behaviour, an unexpected process, privilege escalation, an abnormal outbound connection, without instrumenting applications or degrading their performance. Static hardening and runtime detection complement each other: one reduces the attack surface, the other watches what remains.

Secret management completes this hardening: no more passwords or API keys in code or in plaintext environment variables, but a centralised vault such as Vault or the cloud providers' native managers, ephemeral workload identities and automatic credential rotation. Detecting secrets exposed in repositories, followed by their immediate revocation, not just their removal from history, remains one of the highest effort-to-impact controls in the entire chain.

SECTION 5

Test your defences: red team, purple team and unified incidents

The eighth practice pits defences against realistic attacks: exercises opposing an offensive red team and a defensive blue team, complemented by purple teaming sessions where both collaborate to concretely improve detection rules, and by bug bounty programmes that engage external researchers continuously. These exercises reveal what scanners cannot see: exploitation chains that combine several minor weaknesses into a major compromise.

The ninth practice unifies incident and vulnerability management: security defects live in the same backlog as functional defects, with remediation SLAs per severity level and metrics tracked over time, mean time to remediate, share of vulnerabilities fixed within SLA, residual security debt. What does not enter the teams' normal workflow always ends up ignored; what does gets fixed like any other bug.

These two practices reinforce each other: the lessons from offensive exercises feed the unified backlog with concrete scenarios, and remediation metrics measure whether the organisation actually improves from one exercise to the next. A red team that finds the same flaw two years in a row is not revealing a technical problem but a governance failure, and that is exactly the kind of signal leadership needs to see.

SECTION 6

Keep a shared security culture alive day to day

The tenth practice, the most structuring one, is cultural: spreading a mindset where security is a daily priority rather than a constraint endured. Concretely, this means a network of security champions inside product teams, threat modeling workshops held at the design stage of sensitive features, and blameless post-mortems that treat every security incident as an opportunity to learn rather than to punish. These local relays defuse the old opposition between a security team that says no and product teams that work around it: decisions are made where the code is written.

### Measuring culture as much as tooling

A culture is steered with indicators: the share of teams with a trained champion, pipeline coverage by automated controls, remediation time per severity, recurrence rate of the same vulnerability classes. It is this culture, more than any tool, that keeps the other nine practices alive over time, a scanner can be bought in a week, a habit is built over quarters.

@cite:devops-vs-devsecops-differences

SECTION 7

The Adservio approach: security as a default value

At Adservio, DevSecOps is not a pile of tools but an engineering discipline: automated controls in the CI/CD pipeline, static and dynamic analysis calibrated to stay actionable, a signed and verified supply chain, governed infrastructure as code and hardened containers, all of it traced, measured and defensible before an auditor or a regulator.

Our conviction: security works best as a default value, not as a layer added at the end of a project. We help organisations prioritise these ten practices according to their actual maturity, equip them without multiplying consoles, then transfer ownership to internal teams so the security culture takes root for the long run, and we stay alongside them on the projects that follow.

FAQ

Frequently asked questions