Regulators Will Require What You Can't Do Manually
For two decades, "secure software" was a best-effort promise. You scanned, you triaged what you could, and you carried the rest as backlog. Regulators are ending that arrangement. The obligation is shifting from best-effort to continuous and provable, and the difference is not paperwork.
The European Union's Cyber Resilience Act phases in, with reporting duties from September 2026 and the main manufacturer obligations binding from December 11, 2027. Those obligations are concrete: manufacturers must keep a product secure across its support period, ship a Software Bill of Materials, and run an ongoing vulnerability-handling process (Germany's BSI operationalizes the SBOM spec in its TR-03183 guideline). NIS2 already pulled tens of thousands more organizations into scope. And the revised EU Product Liability Directive now treats software like any other product that can be defective, with a carve-out for non-commercial open-source.
Together, they point one way. Security is becoming a standing obligation a producer has to demonstrate on a schedule, not a report you generate before an audit and forget.
"Continuous" is the word that breaks the old model
A one-time SBOM is a snapshot. A continuous obligation is not: the SBOM has to stay current, the vulnerabilities in it have to be dispositioned, and the fixes have to ship within the support window, for every product, indefinitely.
That is a different kind of work than an audit. An audit is a moment you prepare for. A continuous guarantee is a state you have to stay in.
Megi Benia, who runs the Strategic Security Initiative, argues the underlying point: without liability for producers, insecure code stays the rational business choice. Liability is how regulators intend to change that math.
Most security programs cannot hold that state today, and the reason has nothing to do with intent.
The math regulators are ignoring, and you can't
Continuous guarantees assume you can resolve findings roughly as fast as they arrive. The industry is moving hard in the opposite direction.
AI-assisted developers commit three to four times faster than their peers, and at Fortune 50 scale the Cloud Security Alliance found monthly security findings rising roughly tenfold. The same research note reports that 45% of AI-generated code fails OWASP Top 10 tests, and that privilege-escalation paths climbed 322%. Volume is going up and the mix is getting worse.
Now set that against the resolution side. Average time to fix a flaw has reached 252 days per Veracode, and plenty of enterprises carry six-figure backlogs. A 252-day fix cycle does not satisfy a support-period guarantee. It violates it, one unpatched finding at a time.
Wendi Whitmore of Palo Alto Networks framed the shift for security leaders: your program's maturity no longer determines your exposure, your supply chain does, and the question has moved from "are we secure?" to "are we faster?" Regulation is about to make the second question a legal one.
You cannot hire your way out of this. The gap between finding rate and fix rate is now wide enough that adding analysts moves it by rounding error. The obligation is continuous, so the response has to be too.
What a continuous guarantee actually requires
Underneath the acronyms, a provable and continuous obligation needs two things running as machinery, not as a quarterly scramble.
The first is triage that produces evidence, not opinions. Regulators and auditors do not want a longer list of findings. They want a defensible answer to which findings are real, which are reachable, and why the rest were dropped.
Exploitability analysis does exactly that, and it does it as a logged decision. When most of a backlog is noise, an automated gate that dispositions and drops the unreachable findings turns "we have 100,000 alerts" into "here are the ones that matter, and here is the record of how we decided." That record captures the outcome, the rationale, and a confidence level for every finding. It is what the old spreadsheet never was.
The second is remediation that ships on a clock. A continuous guarantee is not a document. It is a merge rate.
If your obligation is to keep a product patched across its support period, the operative metric is how fast merge-ready fixes actually reach the branch, not how many tickets you filed. Context-aware remediation, where the fix matches the codebase and passes the existing tests before a human reviews it, is what lets fix-rate track find-rate instead of falling further behind every sprint.
Triage without remediation gives you a beautifully documented backlog you still cannot clear. Remediation without triage floods your reviewers with fixes for findings that never mattered. A continuous obligation needs both, under one record.
The compliance-theater trap
There is a tempting wrong answer, and vendors will sell it to you. You can buy tools that generate the SBOM, produce the report, and populate the dashboard, and you will have documentation that looks like compliance.
An SBOM is an ingredient list. It tells you what is in the software. It does not disposition the vulnerabilities in those ingredients, and it does not fix them.
A software bill of materials is inventory, and inventory alone does not reduce risk. Producing the document is not producing the security. When the obligation is continuous and provable, the artifact regulators will eventually care about is not the inventory. It is the disposition record and the fix history behind it.
Compliance theater is expensive and it fails exactly when tested, at the moment a finding in your SBOM turns into an incident and someone asks what you did about it and when.
Where Pixee fits
Pixee is not a compliance product, and it will not make you CRA-compliant. Compliance is yours, on your systems, judged against your obligations.
What Pixee does is run the two things a continuous guarantee depends on. It confirms which findings are exploitable across the scanners you already run and drops the noise with a logged disposition, and it opens context-aware pull requests for what survives. Triage and remediation are co-equal by design, because the evidence trail and the merge rate are the two things an auditor and a support-period obligation actually ask for.
The regulation is arriving on a fixed date. The finding volume is climbing on its own schedule. The teams that treat "continuous" as an operating capability, rather than a document to generate, are the ones who will still be able to answer the question when it is asked.
Frequently asked questions
What does the CRA require for software security?
The EU Cyber Resilience Act, binding from December 11, 2027, requires manufacturers to ensure cybersecurity across a product's full support period, ship a Software Bill of Materials, and run an ongoing vulnerability-handling process. It is a continuous obligation, not a one-time certification.
Is an SBOM enough to meet continuous security obligations?
No. An SBOM is an inventory of components. It does not tell you which vulnerabilities are exploitable, and it does not remediate them. Meeting a continuous obligation requires dispositioning findings and shipping fixes within the support window, with a record of both.
Why can't manual processes keep up with these requirements?
AI-assisted development has pushed commit rates up three to four times and monthly security findings up roughly tenfold, while average time to fix a flaw sits at 252 days. Adding analysts does not close a gap that wide. A continuous obligation needs automated triage and remediation to make fix-rate track find-rate.
Does automated remediation make us compliant?
No tool makes you compliant. Automation produces the two things compliance regimes ask for: an evidence-backed disposition record for every finding, and a fast, provable fix history. Compliance remains your responsibility; the operational capability is what makes it achievable.
Related reading
• SBOM tools vs fix tools: why inventory alone doesn't reduce risk
• What is VulnOps? Vulnerability Operations, defined
