Cyber Security and Resilience Bill risks prioritising reporting over resilience

By Ilkka Turunen, Field CTO, Sonatype

Why Britain’s next big cyber law could miss the point

The UK’s Cyber Security and Resilience Bill is being promoted as a landmark step towards improving national cybe r resilience. It contains several important measures, including expanded regulatory oversight, broader coverage of critical suppliers and faster incident reporting requirements. However, much of the attention has focused on reporting timelines. While earlier notification may improve visibility, coordination and threat intelligence sharing, it does little to address the underlying software supply chain weaknesses and security practices that enable many cyber incidents in the first place.

Unlike the EU’s NIS2 regime, which places significant emphasis on governance, accountability and supply-chain security obligations, the UK debate has focused heavily on incident reporting requirements.

Why faster reporting does not deliver resilience

Faster reporting can provide regulators and national cyber authorities with earlier visibility into emerging threats, helping to improve coordination and sector-wide awareness. However, these benefits should not be confused with resilience itself. For organisations responding to an active incident, the ability to detect, contain and recover remains far more important than how quickly a notification is submitted.

Real resilience is built long before an alert is filed. It depends on preparation, rehearsed coordination, clear roles and rehearsed response processes. Deadlines on paperwork do not replace detection, containment, recovery and the ability to absorb an attack without systemic shock.

The root causes remain unaddressed

The economic impact of this imbalance is significant. Supply-chain driven incidents routinely trigger forced downtime, emergency remediation, regulatory exposure and lost productivity across entire organisations. In large enterprises, a single compromised dependency can halt development teams, delay releases and absorb weeks of engineering effort. For smaller firms, the cost is often existential. When incidents originate deep in shared software components, organisations pay to fix problems they did not create, using resources that could otherwise be invested in growth, innovation and competitiveness.

Modern cyber incidents almost always have roots far upstream from where they are reported. They begin in the software supply chain, not the SOC dashboard. Vulnerable open-source components, outdated libraries and fragile CI/CD pipelines are among the biggest accelerants of compromise. 

The open source ecosystem is vast: developers worldwide downloaded components nearly 9.8 trillion times last year, exposing enormous shared infrastructure to exploitation (that’s 1,180 downloads for every human on Earth). Over the same period, malicious open-source packages grew by 75 percent, pushing the total above 1.23 million threats lurking in dependency graphs used by European enterprises every day.

While the Bill strengthens governance, oversight and reporting requirements, it places less emphasis on the practical measures organisations can take to improve software supply chain security, vulnerability management and secure-by-design development practices.

Unless organisations also address how software is built, maintained and governed, reporting obligations risk treating symptoms rather than causes. The challenge is becoming more acute as organisations adopt AI-assisted development tools that accelerate code generation and dependency adoption. Without strong governance and oversight, these technologies can amplify existing software supply chain risks at scale.

Supply chains, not silos, will test the law

The Bill’s expansion to managed service providers, critical suppliers and additional digital infrastructure reflects a growing recognition that cyber risk increasingly resides across interconnected ecosystems rather than within individual organisations.

One of the most significant practical impacts of the Bill will be on supply-chain accountability. Organisations will be accountable not only for their own reporting readiness, but for that of their suppliers, managed service providers and software partners. Most third parties do not have mature incident detection and response capabilities today. Few can honestly demonstrate that they can detect, assess and report incidents under tight deadlines. This will force rapid changes to procurement standards, contractual clauses and supplier risk assessments.

Far from creating resilience, the regulation could expose systemic fragilities as organisations scramble to map their dependencies and manage risk in sprawling software supply chains. Weaknesses in third parties may become the largest source of non-compliance and operational disruption.

What European businesses should do now

Companies should treat this as a stress test for existing practices, not a compliance playbook. First, simulate realistic detection and reporting scenarios to see whether your teams can meet the proposed timeframes without sacrificing incident containment or recovery. Next, assess supplier readiness against these new requirements. If your partners cannot demonstrate mature security and response practices, the legal obligations are likely to fall back on you.

Most importantly, invest in better software development practices, continuous vulnerability management, and dependency oversight. Improving the hygiene and provenance of software components reduces incident frequency and severity more effectively than accelerating how quickly an incident is reported after the fact.

Governing risk, not just reporting it

Without addressing insecure software, brittle supply chains and untested response processes, the Cyber Security and Resilience Bill risks becoming an administrative burden rather than a catalyst for real resilience. Mandatory reporting has a place, but it cannot be a substitute for upstream prevention. The real measure of cyber resilience will not be how quickly organisations notify regulators after an attack, but how effectively they prevent, contain and recover from one. 

Context/background:

We secured this placement following our CSRB briefing call, after which we drafted and finalised the below synopsis:

Cyber Security and Resilience Bill fixes the wrong problem

The UK Cyber Resilience Bill gives the appearance of progress, but focusing on 24- and 72-hour reporting solves the wrong problem. Faster disclosure helps regulators, but it does not stop attacks or reduce risk. The real issues sit upstream in insecure software, unmanaged vulnerabilities, fragile supply chains and incident processes that many organisations have never tested. Unless these fundamentals are addressed, the Bill risks becoming a reporting exercise rather than a meaningful step toward resilience. 

Ilkka Turunen, Field CTO at Sonatype, could discuss how:

• Reporting is not resilience: Tight deadlines may give regulators quicker visibility, but they will not reduce the number of breaches. The real challenge is coordinating a fast and effective response, made harder by the Bill’s vague definition of a ‘significant incident’
• The software problem is being overlooked: Most cyber incidents start with insecure code, outdated components or weak development pipelines. The Bill offers little guidance on improving software hygiene or adopting secure-by-design practices
• Supply-chain risk will be the biggest shock: Organisations will be held responsible for whether their suppliers and MSPs can meet reporting requirements. This will force immediate changes to procurement, contracting and overall risk management
• Businesses need to act now: Companies should begin testing whether they can actually meet the 24- and 72-hour reporting windows, reviewing supplier readiness and strengthening their development and security practices before the Bill exposes current shortcomings