惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

J
Java Code Geeks
F
Fortinet All Blogs
Martin Fowler
Martin Fowler
M
MIT News - Artificial intelligence
G
Google Developers Blog
P
Proofpoint News Feed
Recent Announcements
Recent Announcements
MyScale Blog
MyScale Blog
D
DataBreaches.Net
Stack Overflow Blog
Stack Overflow Blog
月光博客
月光博客
爱范儿
爱范儿
罗磊的独立博客
腾讯CDC
Hugging Face - Blog
Hugging Face - Blog
博客园 - 叶小钗
Vercel News
Vercel News
酷 壳 – CoolShell
酷 壳 – CoolShell
B
Blog
C
Check Point Blog
美团技术团队
宝玉的分享
宝玉的分享
Microsoft Security Blog
Microsoft Security Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻

2024 Sonatype Blog

Reduce AI Token Waste by Getting Decisions Right Earlier Optimising Out the Waste in Open Source Publishing Hugging Face Security Incident: A New Class of Threat Is Here The AI Productivity Paradox: More Code, Not More Delivery A Reported Log4j RCE Is More Complicated Than It Looks Why Financial Services Is the Canary in the Code Mine 91 Spring CVEs: The AI Vulnerability Consumption Problem An Air Gap Doesn Securing Software at the Speed of AI: What Four Years of Data Reveal Major Themes at Black Hat 2026 Six npm Packages Use Ethereum Transactions to Retrieve Malicious Payloads Flooding Dropper Hits npm With 850 Malicious Packages Mini Shai-Hulud npm Attack: More Than 2,200 Components Impacted 5 Reasons Developers Still Download Malicious Packages Defining Community Open Source Is Harder Than It Looks Walking the Walk on Package Registry Sustainability AI Changes the Software Supply Chain and How We Secure It The Hugging Face Incident Changes the Vulnerability Equation What Is Grounding? Why AI Coding Assistants Need Better Intelligence Open Source, Open Infrastructure, and the Space Between Request for Comments: CARE and Maven Central Q2 2026 Open Source Malware Index AI Is Forcing a New Open Source Security Model Vulnerability Prioritization Is Missing the AI-Era Point The Hidden National Security Threat Inside AI-Driven Software Miasma Returns: Leo Platform Compromise in npm The Rise of Collective Defense for Open Source Signal Over Noise: Reachability Analysis Is the Reality Check SCA Has Been Missing Software Security Has to Start at Assembly easy-day-js Targets Mastra, Dependency Attacks Grow
The CRA Reporting Deadline Is Almost Here
Aaron Linskens · 2026-09-03 · via 2024 Sonatype Blog

The European Union (EU) Cyber Resilience Act (CRA) is no longer a future-looking compliance project. Its first major operational deadline is now days away.

Starting September 11, 2026, manufacturers must report actively exploited vulnerabilities and severe incidents that affect the security of products with digital elements.

The broader CRA obligations will apply on December 11, 2027, but this earlier milestone tests if organizations can turn vulnerability intelligence, product inventory, engineering response, and external communications into a coordinated process under tight time constraints.

For many software organizations, that is the harder part. Knowing that a vulnerable component exists is only the first step. Teams must determine if it is present in a released product, if it is being actively exploited, who owns the response, and what must be communicated to regulators. And do all of that quickly enough to meet the deadline.

The CRA Reporting Deadline Is September 11, 2026

The CRA entered into force in December 2024. While most of its requirements apply in December 2027, its reporting obligations apply sooner.

Under the CRA, manufacturers must report actively exploited vulnerabilities and severe incidents that affect the security of their products with digital elements.

The European Commission states that the reporting process includes:

  • An early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident.

  • A notification within 72 hours.

  • A final report no later than 14 days after a corrective measure becomes available for an actively exploited vulnerability, or within one month for a severe incident.

Reports will be submitted through the CRA Single Reporting Platform to the Computer Security Incident Response Team (CSIRT) in the country of the manufacturer's main establishment, with information also made available to European Network and Information Security Agency (ENISA) unless exceptional circumstances apply.

These timeframes are not simply an incident-response concern. They depend on software supply chain visibility. To make a timely, defensible report, teams need to know which released products contain the affected component, assess the vulnerability's impact in context, identify the appropriate response owner, and understand the status of available fixes.

New Commission Guidance Makes Preparation More Concrete

In July 2026, the European Commission published actionable guidelines designed to assist in prompt CRA execution. The non-binding guidance addresses questions stakeholders have raised about scope, including remote data processing solutions and free and open source software, as well as substantial modifications, support periods, reporting obligations, and risk assessments.

The CRA applies across the lifecycle of products with digital elements, not only at the point of release. For software manufacturers, compliance will increasingly rely on repeatable evidence that they understand the components in their products, assess relevant risk, manage vulnerabilities, and can respond when conditions change.

The Commission's guidance does not eliminate the work ahead, but it gives teams a clearer starting point for translating legal obligations into operating processes. With the reporting deadline imminent, the question is no longer whether or not to prepare. It's if the people, data, and workflows needed to issue a 24-hour early warning are already in place.

Why Software Supply Chain Visibility Determines Reporting Readiness

Modern applications are assembled from direct and transitive dependencies, containers, frameworks, proprietary code, and increasingly AI-related components and services. A security event involving even one widely used component can quickly become an investigation across product lines and development teams.

That is where a software bill of materials (SBOM) becomes essential. An SBOM provides an inventory of the components and dependencies that make up a software product. But an inventory alone is not enough for CRA reporting readiness. It must be current, connected to the products that have actually been released, and paired with vulnerability intelligence and a process for determining ownership and impact.

Teams should be able to move from a new vulnerability disclosure to answers about exposure without starting a manual search across source repositories, build systems, and spreadsheets. They also need to preserve a record of what was known, what was assessed, what action was taken, and when, both for effective remediation and for reporting.

Four Questions to Ask Before the Deadline

The September 11, 2026, deadline is a useful forcing function for testing the foundations of a CRA program. Product security, engineering, legal, compliance, and communications teams should be able to answer these questions before an event occurs:

  • Can we identify every affected product quickly? Maintain current component inventories and SBOMs that include direct and transitive dependencies and map them to released product versions.

  • Can we assess whether an alert requires action? Establish a consistent process to evaluate whether a reported vulnerability is actively exploited, whether it affects a product, and whether it meets the threshold for reporting.

  • Can we coordinate a response in hours, not days? Define escalation paths, decision owners, and communication channels across engineering, product security, legal, and compliance before a qualifying event creates urgency.

  • Can we document and report the response? Prepare the information and evidence needed for an early warning, subsequent notification, and final report and validate the process through a tabletop exercise.

The goal is not to make every security event a compliance exercise but to ensure that the events that meet the CRA threshold do not expose gaps in visibility, decision-making, or communication when the clock starts.

September Is the First Operational Test, Not the Finish Line

The EU Cyber Resilience Act deadline on September 11 is an important milestone, but it is also part of a longer implementation sequence. The main CRA obligations, including the cybersecurity requirements that apply across a product's lifecycle, follow in December 2027.

Organizations that use the reporting deadline to strengthen component visibility, SBOM management, continuous monitoring, and incident response will be better positioned for those broader obligations. The same capabilities that help a team answer a regulator's questions quickly also help it reduce risk before a vulnerability becomes a reportable event.

For more on how to prepare for the EU Cyber Resilience Act, explore Sonatype's CRA compliance guide and checklist.

Tags

software bill of materials Cybersecurity Compliance europe SBOM EU Cyber Resilience Act Liability Regulation federal