DevSecOps Is Failing Because Security Is Still Being Sold as a Product, Not a Practice

At RSA Conference this year there were 650+ security vendors. All of them were selling security products. Almost none of them were selling security practices.

This distinction sounds academic. It isn’t.

A security product gives you a tool and a dashboard. A security practice gives you a discipline that gets embedded into how your engineers work every day.

The security industry has spent 30 years optimising for selling products. The result: organisations with extraordinary tooling and catastrophic outcomes. The average enterprise uses 76 security products. The average cost of a data breach keeps climbing.

Why Products Don’t Solve the Problem

Security products solve the problem of not having a particular security product. They do not solve the problem of not having a security practice.

I see this pattern constantly: a CISO presents the board with a security incident. The board asks “how could this happen?” The CISO requests budget for a new tool that would have detected the specific attack vector used. The board approves. The tool is purchased. The problem shifts laterally to the next unprotected vector.

The 76-product enterprise has a dashboard that shows findings from all 76 products, with no prioritisation, no ownership, and no process for remediation that engineers actually follow. The findings accumulate. The material risk doesn’t decrease.

What a Practice Actually Looks Like

The organisations with the best security outcomes I’ve worked with are not the ones with the most security products. They’re the ones where security has been embedded into how engineers work.

Concretely:

Engineers know what a security finding is and how to fix it. Not as a theoretical concept they encounter findings in their normal workflow, understand what they mean, and know how to resolve them. This happens because SAST findings appear in PR comments, not in a separate portal. Container scan results are in the build log, not in a dashboard three levels away.

Security has clear ownership at the team level. Every service has a team. That team owns the security posture of their service. There is no separate security team that “owns” application security the application team does. The security team provides tools, standards, and consultation. They do not own and operate the security controls for other teams’ services.

Remediation time is tracked and taken seriously. The mean time to remediate a CRITICAL finding is a KPI. When it’s trending in the wrong direction, it gets treated with the same urgency as a deployment frequency regression.

Security is in the conversation at the design stage. Architecture reviews include a threat model not a full 40-page document, but at minimum a conversation about trust boundaries, data flows, and the attack surface being created.

The Vendor Problem

The security tooling market has a perverse incentive structure. Vendors benefit from complexity more products means more vendor relationships, more renewals, more seats to sell. Vendors do not benefit from simplification.

The result is a market that actively works against the goal of a coherent security practice.

My advice: before buying your next security product, ask four questions.

One: Do you have a remediation process that engineers actually follow for findings from your existing tools? If not, another tool generates more unfollowed findings.

Two: Is this finding-generation or finding-prevention? Most products are the former. Finding-prevention (guardrails, policy enforcement, hardened defaults) is almost always higher leverage.

Three: Who owns the findings this product generates? If the answer is unclear or “the security team,” the findings will pile up.

Four: Does this integrate into where engineers already work, or does it create a new place engineers have to go?

The best security investment most organisations can make is not a new tool. It’s investing in the process that makes their existing tools actually produce remediated findings rather than accumulating dashboards.

The Inconvenient Truth

DevSecOps as a term has been fully captured by the vendor community. It now mostly means “security tools that integrate with your CI/CD pipeline.”

The actual practice making security a normal, continuous, engineer-owned part of software development is harder to sell because it requires organisational change, not a procurement decision.

That’s why it doesn’t dominate conference floors.

It’s also why the organisations that actually achieve it tend to win.