What DevSecOps actually changes
It does not make your developers responsible for security, and any programme sold on that premise will fail in the first quarter. It does not remove the need for people who understand attacks, and it does not replace penetration testing, threat modelling or incident response. What it changes is narrower and more useful: security work stops being a separate phase with its own calendar and becomes an output of the delivery pipeline you already run.
What does DevSecOps not change?
It does not change who is accountable for security decisions, and this is the most common misreading. Deciding that an unauthenticated administrative endpoint is acceptable for a fortnight is a risk decision, and moving a scanner into a pipeline does not qualify the developer who sees the alert to make it. Accountability stays where it was. What moves is the point at which the information arrives.
It also does not remove specialist work. Threat modelling a new payments flow, testing business logic that no tool understands, reviewing cryptographic choices and running an incident all still need people who do this for a living. Automation covers the classes of defect that can be described as patterns, which is a large and worthwhile set and not the whole set.
And it does not make delivery faster on its own. Adding four scanners to a pipeline adds minutes to every build and a queue of findings to every team. Programmes that improve delivery speed do so because they replaced a manual pre-release security review that took three weeks, not because scanning is inherently quick.
What actually changes, then?
Four things, and they are mechanical rather than cultural. Security checks run on every change instead of before a release, so the feedback arrives while the author still remembers the code. Findings enter the same backlog as bugs rather than a separate register nobody reads. Controls are expressed as code in version control, so a change to a control is reviewable. And the evidence an auditor wants is produced as a by-product of the pipeline rather than assembled by hand at the end of a quarter.
The fourth is underrated and often pays for the programme. If your pipeline signs artefacts, records what was scanned and stores the result against the commit, you can answer questions like which version of a library was in production in March without a forensic exercise. That capability is what turns an audit from a project into a query.
The cultural claims tend to follow from the mechanics rather than causing them. Teams get less hostile to security when security stops arriving as a late veto with no context, and that change is produced by timing and specificity, not by a workshop.
What moves, and what stays where it is?
Sorting activities into those three columns is the most useful hour you can spend before buying anything. The pattern below is what a working programme usually settles into, and the third column is the part that stops teams over-promising.
Two rows are worth reading closely. Accepting a known risk stays a named human decision, because automation can record an exception but cannot own one, and an exception with no owner is how a temporary allowance becomes permanent. And threat modelling stays human but gains a trigger: rather than happening for every project or none, it fires on defined change types such as a new external interface, a new data category or a change to an authentication path.
| Activity | Where it was | Where it goes | Who decides |
|---|---|---|---|
| Dependency and container scanning | Pre-release review | Every build, results attached to the commit | Platform team sets it, service team acts |
| Secrets detection | Nowhere, or found after a leak | Pre-commit hook plus a CI backstop | Platform team, no exceptions |
| Infrastructure configuration checks | Manual review of a change ticket | Policy evaluated against the plan | Platform and security jointly |
| Threat modelling | Design phase, if at all | Stays a human activity, triggered by change type | Security, with the service team |
| Penetration testing | Annual | Stays external and periodic, scope informed by pipeline data | Security |
| Accepting a known risk | Security sign-off | Stays a named human decision with an expiry date | Service owner, recorded |
Does it mean developers do security work now?
They do a specific and bounded amount, which is fixing defects in code they wrote when a tool identifies one and a human has confirmed it matters. That is not new work in kind. It is the same activity as fixing a bug, arriving through a different channel.
What does not transfer is judgement about exploitability, severity in your context, and whether a finding can be dismissed. Asking a developer to make those calls in the middle of a sprint produces one of two outcomes: everything gets suppressed, or everything gets escalated. Both are failures of the operating model rather than of the individuals.
The practical division is that tooling decides what to report, security decides what is worth acting on and by when, and the team that owns the code does the fixing. When one group holds two of those three roles the programme drifts, usually towards a security team writing patches for services they do not understand.
What does the tooling actually consist of?
Six categories, and most estates need fewer than they are sold. Static analysis of your own source, software composition analysis of your dependencies, secrets detection, configuration checks on infrastructure definitions, image scanning for what you build into containers, and some form of dynamic testing against a running instance. Signing and provenance sit alongside these as a separate concern about what you ship rather than what is in it.
Container scanning deserves particular attention because it produces the largest volume of findings and the least signal per finding. A scanner enumerates every package in the image against vulnerability databases regardless of whether your code can reach it, so a first scan of a mainstream base image commonly returns hundreds of results you did not cause. Planning for that before you enable it is the difference between a control and an ignored channel.
Overlap is normal and mostly harmless, with one exception: two tools reporting the same dependency finding with different identifiers will double your apparent backlog and destroy any trend you try to measure. Deduplication is a requirement, not a refinement.
How do you tell whether a programme is real?
Run this test this week. Pick a finding raised by a pipeline tool more than a month ago and trace it. Who saw it, who decided what to do, what is the current state, and if it was dismissed, when does that dismissal expire. If nobody can answer within an hour, you have scanning rather than DevSecOps, whatever the dashboard reports.
The second test is to ask for the last time a build was stopped by a security check and what happened next. A healthy answer is specific and slightly annoyed: a named service, a real defect, a fix in hours. An unhealthy answer is that it never happens, which means the gates are advisory, or that it happens constantly, which means someone has already built a bypass.
The third is to look at whether any control has been removed. Programmes that only accumulate tools are not being managed. A team that switched off a check because it produced nothing actionable, and recorded why, is exercising the judgement the whole approach depends on.
Common questions
- What is DevSecOps in simple terms?
- It is the practice of running security checks as part of the delivery pipeline rather than as a separate phase before release, and of tracking the resulting findings in the same backlog as ordinary defects. The checks are automated, the controls live in version control so changes to them are reviewable, and the evidence an auditor asks for is produced by the pipeline instead of assembled by hand later.
- Does DevSecOps replace the security team?
- No. Automation covers defect classes that can be described as patterns, which is useful but partial. Threat modelling a new flow, testing business logic that no scanner understands, reviewing cryptographic choices, deciding what a finding means in your context and running incidents all remain specialist work. What changes is that the security team spends less time gathering information and more time on decisions.
- Does DevSecOps slow down releases?
- Adding scanners adds minutes to each build and a queue of findings to each team, so in isolation it costs time. Programmes that end up faster do so because they removed a manual pre-release security review measured in weeks. If nothing manual was removed, expect delivery to get slightly slower and plan triage capacity accordingly. The way to keep the cost small is to scope each check to the change and move the slow ones to a scheduled run where nobody is waiting on the result.
- Do developers become responsible for security under DevSecOps?
- They become responsible for fixing confirmed defects in code they own, which is the same activity as fixing a bug through a different channel. They should not be asked to judge exploitability, set severity for your environment or decide whether a finding can be dismissed. When those judgements are pushed into a sprint, teams either suppress everything or escalate everything.
- How many security tools does a pipeline need?
- Six categories exist: static analysis, dependency composition analysis, secrets detection, infrastructure configuration checks, container image scanning and dynamic testing. Most estates need fewer than they buy, and adding a category with no owner for its output is worse than leaving it out. The one hard requirement when tools overlap is deduplication, because two scanners reporting the same dependency issue under different identifiers doubles the apparent backlog and makes any trend meaningless.
- How do you know if a DevSecOps programme is working?
- Trace one finding from a month ago end to end: who saw it, who decided, what state it is in now and when any dismissal expires. If that takes more than an hour to answer, the programme is scanning rather than functioning. Then ask when a build was last stopped by a security check. Never means the gates are advisory, constantly means someone has built a bypass.
