DevSecOps

Why most security tooling fails#

Not because the tools are bad. Because they were switched on, produced thousands of findings against a decade of accumulated code, overwhelmed the team, and got muted. The dashboard still exists. Nobody looks at it.

Security that works is boring and incremental: fix what is actually reachable, then prevent new problems at the point of change, and leave the historical backlog to a scheduled burn-down.

Exploitability over severity#

A critical CVE in a library you import but never call on a path an attacker can reach is lower priority than a medium-severity issue in your public authentication flow. Scanner severity does not know the difference. We triage by:

• Is the vulnerable code actually reachable in a running path?
• Is the component exposed to the internet or to untrusted input?
• Does a working exploit exist in the wild?
• What would an attacker get if it worked?

That reordering typically turns four thousand findings into fifteen that matter this week.

Gates at the point of change#

Once the exploitable set is closed, the pipeline blocks new critical findings — dependencies, container images, Terraform plans and committed secrets. The threshold is set so the gate is credible: a gate that fires on everything gets removed within a fortnight.

Where AI changes the threat model#

If you run LLM features, you inherit a new surface: prompt injection through untrusted content, data exfiltration via tool calls, and over-permissioned agents acting with more authority than the user who invoked them. We cover those explicitly alongside AI Governance — conventional application security controls do not address them.