From DevOps to DevSecOps: Turning 312 Findings Into Four

Most descriptions of this move say "shift security left" and stop there, which tells you the direction and nothing about the work. Here is the version that survives contact with a real pipeline.

Security tooling produces findings. Findings are not work until somebody can act on them. A scanner that reports four hundred vulnerabilities on your base image has not done security — it has moved the problem from one team to another and added a number nobody can reduce. The job is turning that output into a small set of things genuinely worth doing, and then making them happen without stopping delivery.

That is the whole discipline, and almost everything difficult about it follows from that one sentence.

What transfers

More than in most of these transitions, because DevSecOps is mostly DevOps with different failure modes.

• Pipelines — unchanged. Security tools are pipeline stages.
• Containers and images — unchanged, and now you care about what is in them rather than only whether they run.
• Identity and access — unchanged, and it becomes central rather than incidental.
• Infrastructure as code — unchanged, and now it is also an audit surface, which is an advantage.
• Debugging — the most transferable skill of all. Working out whether a reported vulnerability is actually reachable is a debugging exercise.

If you can build and operate a pipeline, you have most of what this needs. What is missing is judgement about risk, and a particular kind of diplomacy.

What is genuinely different

1. You produce work for other people

This is the shift that catches DevOps engineers hardest.

In operations, you find a problem and fix it. In security, you find a problem in someone else's code and they fix it — on their schedule, against their priorities, with their understanding of how important it is. Your output is a request, and requests can be declined.

Which means the quality of the request matters enormously. "Critical vulnerability in lodash" is ignorable. "This dependency is reachable from the public API, here is the call path, here is the version that fixes it, here is the PR" gets merged.

The gap between those two is the job.

2. False positives destroy the whole programme

Security tooling is tuned to be loud, because a missed vulnerability is the failure everyone remembers. The result is output dominated by things that are technically true and practically irrelevant: a CVE in a code path never called, a critical in a test-only dependency, a finding in a base-image package the application never invokes.

A team that is asked to act on those learns quickly that the scanner is usually wrong. And a team that has learned the scanner is usually wrong will also ignore the one that matters.

You cannot fix this by tuning severity. You fix it by triaging before it reaches the team, which means you have to be the one who looks first.

3. The gate decision is the one that gets you bypassed

Every security control is either a warning or a block, and choosing wrong in either direction is expensive.

Block on everything, and the first time a release is held up by a finding in a transitive test dependency, somebody gets the gate disabled — usually permanently, usually with a manager's blessing, usually at the worst possible moment.

Warn on everything, and nothing is ever fixed.

The workable answer is narrow and specific. Block on a small number of things that are unambiguous, verifiable, and genuinely serious: a leaked credential, an unsigned artifact reaching production, a critical vulnerability with a known exploit in a reachable path. Warn on the rest, with an owner and a date.

A gate people respect is one that has never been wrong.

4. You inherit a supply chain you did not choose

Your application's attack surface includes every dependency, every base image, every GitHub Action, and every container your pipeline pulls. Most of it was chosen for convenience by someone who has left.

This is where the site's CI/CD security risks material is worth reading properly — it covers the ten categories systematically, including dependency chain abuse and improper artifact integrity validation, which are the two most commonly underestimated.

Three concrete failures from this class have their own pages, because each has a specific error and a specific fix:

• Push declined due to repository rule violations — a secret in a commit, and why deleting the line does not clear it
• Error: no matching signatures — artifact verification, and why the message cannot distinguish "unsigned" from "signed by someone else"
• Not authorized to perform sts:AssumeRoleWithWebIdentity — keyless CI identity, which is the direction everything is moving

5. Identity replaces secrets, slowly

The most significant practical change in pipeline security over recent years is that long-lived credentials are being replaced by short-lived, federated identity. A pipeline no longer holds an AWS key; it presents a token describing itself and exchanges it for credentials valid for minutes.

This is a genuine improvement — a token that expires in fifteen minutes is a much smaller problem when it leaks — and it moves the failure mode rather than removing it. The failures are now about trust policies and claim matching rather than about rotation. The OIDC page above is one of them in detail.

The principle underneath is worth stating plainly: secrets do not belong in Git, and the best secret is the one that does not exist because identity replaced it.

A worked triage

A scan on a service reports 312 findings. Here is how that number gets to something actionable.

Filter by reachability first, not severity. Most scanners report everything in the image, including packages the application never loads. A critical in a library your code does not import is not a critical for you. Several ecosystems now support reachability analysis; where they do not, grep for the import is a crude but honest first pass.

312 findings
 → 47 in packages the application actually imports

Then filter by exploitability. Is there a known exploit? Is the vulnerable function called with untrusted input? A remote-code-execution CVE in a parser you only run against your own config is different from the same CVE in a parser handling user uploads.

 47 reachable
 →  6 with a plausible path from untrusted input

Then check the fix exists. A finding with no released fix is a risk to accept and track, not a task to assign. Assigning it produces a ticket that sits open forever and teaches people that security tickets are noise.

  6 exploitable
 →  4 with an available fix

Four things worth doing, from 312. That is a deliverable. The original 312 was a dashboard.

A caution on this example: the numbers are illustrative, and the filtering ratios are not a rule — they depend entirely on your stack and how the image was built. The sequence is the point, not the arithmetic.

Common mistakes

Adding tools before deciding what you will act on. Every scanner you add produces findings you now own. Adding a second scanner before you can handle the first one's output doubles the noise and improves nothing.

Treating severity as priority. CVSS scores a vulnerability in the abstract, without knowing whether you call the code. It is an input to your judgement, not a substitute for it.

Blocking the build to make a point. It works once. What it actually buys is a conversation about disabling the gate, which you will lose, because the release is on the line and your evidence is a severity label.

Fixing by version bump alone. Updating a dependency to clear a scanner is not the same as understanding the change. Sometimes it is, and it is worth knowing which case you are in.

Turning a check off to get past it. This is the one worth being absolute about. If signature verification fails, the answer is never to remove the verification — the two situations the error conflates are "this image is unsigned" and "I am checking for the wrong signer", and they could not be more different. Find out which, then restore the check.

When to slow down

Security work has a failure mode of its own: doing so much of it that delivery stops, which gets the whole programme cancelled and leaves you with less security than a modest version would have.

Do not gate on a control you have not run in warn mode first. You do not know its false-positive rate on your codebase until you have watched it for a few weeks.

Do not roll a policy out everywhere at once. One team, one repository, until you understand what it breaks.

Do not automate a decision you cannot explain. If you cannot say why a build was blocked, you cannot defend the block, and it will be removed.

A realistic path

Start with secrets. It is the highest-value, lowest-argument place to begin, and the failure mode is unambiguous. Push protection, a scanner in CI, and a rotation procedure that someone has actually rehearsed.

Then identity. Move one pipeline off a long-lived cloud key onto federated identity. It is a contained change with a clear before and after, and it teaches you the failure modes in a low-stakes setting.

Then dependencies, in warn mode. Run the scanner, do not gate on it, and spend a few weeks triaging the output yourself. You are learning your own false-positive rate before you ask anyone else to care.

Then pick one thing to block on. One. Something unambiguous. Earn the gate.

Then artifact integrity. Signing and verification, once the pipeline is stable enough that a verification failure means something.

The honest summary

The technical skills transfer almost completely. What is new is judgement about which risks matter and the diplomacy to get other people to act on them — and the diplomacy is not a soft add-on, it is the part that determines whether any of the technical work has an effect.

The failure mode of this discipline is not missing a vulnerability. It is producing so much noise that the team stops reading, at which point you have a security programme that is worse than none, because everyone believes it is working.