Product security

Building Product Security Without the Gates

Making the secure path the easiest path

1. The problem: we find vulnerabilities too late, and it costs too much

Research on defect origins has been consistent for three decades. Most defects are introduced early — roughly 70 to 80 percent in requirements, architecture, and code.1 Fixing in production runs 50 to 100 times more expensive than fixing in requirements.7

The gap between those two facts is widening. Meanwhile only 26 percent of CISA Known Exploited Vulnerabilities were fully remediated.8 Veracode's 2026 data puts average fix time at 252 days, up from 171 five years ago.9

Friction is what connects the two

Late involvement, big-bang reviews, manual processes, unclear ownership, tool sprawl.

We need a different model: continuous, integrated, environment-aware, and automation-first.

2. Where bugs, cost, and friction originate: why even shift-left could fail

BUGS INTRODUCED

share of total defect potential1

COST TO FIX

relative, square-root scale7

FRICTION

none of these is a missing tool

Defects mass on the left. Cost masses on the right. Friction is what carries a defect from one end to the other.

A requirements defect is not intrinsically expensive. It becomes expensive because design decisions, code, tests, and eventually deployed instances got built on top of it. Cost is a function of delay.

The queue is the control.Whatever your scanners find, your actual exposure is set by the interval between a defect being created and an engineer hearing about it. If you have never measured that interval, you do not know what your control is set to.

Why even shift-left fails

It moves the review earlier without removing the wait, producing an earlier bottleneck instead of a later one. What has to move left is feedback latency, not calendar position.

3. What we really need: the continuous, no-gates security model

Security needs to run in the flow of engineering, not next to it.

SECURITY IN THE FLOW OF ENGINEERINGFeedback loops, not gates
Every finding updates the model, the template, and the test suite — so the same defect class cannot return the same way.

Two mechanics do most of the work.

Ratchet, don't gate. Block only on new criticals in changed code. Nobody fixes the backlog to ship — they just cannot make it worse.

Exceptions expire. Named business risk owner, expiry date, compensating control. Exceptions security owns never close.

4. The enablers that make it real

None is a new class of tool. Same tools, moved off the calendar and onto the commit.

5. Release and maintenance of long-lasting components

A device fielded in 2026 is supported into the 2040s. Frozen toolchain, vendor BSP with no upstream, patches that may require regulatory action. Five mechanics.

Under FD&C Act §524B the postmarket obligation is continuous16 — the only evidence worth having is the evidence the process already generates.

6. Measure what matters

Risk reduction, speed, friction — not activity. Scans run and reviews completed are attendance metrics.

Put these beside your DORA delivery metrics, not instead of them.14 Recurrence rate is the honesty check: it only falls when a finding actually updated the model and the tests.

7. The outcome

The trade is real. You give up veto points, spend more engineering effort upfront, and accept residual risk in writing with a named owner. If every exception still routes back to security for a decision, you kept the gate and added paperwork.

Some things stay gates. Gate the irreversible and the legally attributable: a premarket submission, production access to patient data, the first agent with write authority into a system of record. No model sets a risk acceptance, closes a finding, or signs a regulated release.

Most programs have it backwards — they gate the routine, where volume guarantees a workaround, and automate the exceptional, where a human decision was worth the wait.

If you change one thing this quarter, measure your queues.

Context, automation, feedback, and trust. Make the secure path the easiest path.

8. References

    Provenance. Cost-to-fix multipliers are widely reproduced and poorly documented. The escalation trend is well supported; the specific stops trace to IBM Systems Sciences Institute data whose methodology was never fully published. Boehm's original range is 6x–100x. Defect-origin shares come from function-point data on general quality defects, not security defects specifically. Treat both as directional.