The Cyber Resilience Act starts asking about your dependencies

From 11 September 2026, the first operative obligation of the EU's Cyber Resilience Act, Regulation (EU) 2024/2847, applies. It is a reporting obligation on manufacturers, not on open-source projects. But from that date a manufacturer needs an answer to "what is in this product, and who maintains it" that holds up while a vulnerability is being exploited and the clock is running.

The dates, from the text

The regulation entered into force on 10 December 2024. Article 71 sets three application dates:

• 11 June 2026: Chapter IV, on notified bodies (Articles 35 to 51).
• 11 September 2026: Article 14, the manufacturers' reporting obligation.
• 11 December 2027: everything else, including the essential requirements in Annex I and CE marking.

The Commission's policy page agrees: "reporting obligations to apply as of 11 September 2026"; "the main obligations introduced by the Act will apply from 11 December 2027".

What has to be reported from that date

Article 14 covers an actively exploited vulnerability in the product and a severe incident affecting its security, notified through the single reporting platform to the coordinating CSIRT and ENISA at once. For an exploited vulnerability: an early warning "without undue delay and in any event within 24 hours of the manufacturer becoming aware of it", a vulnerability notification within 72 hours, and a final report "no later than 14 days after a corrective or mitigating measure is available". Severe incidents follow the same 24-hour and 72-hour steps, with a final report within one month.

Article 13(8) adds that "vulnerabilities of that product, including its components" must be handled. An exploited vulnerability in a dependency is, for this purpose, a vulnerability in the product that ships it.

What it costs to get wrong

Article 64 sets the ceilings: up to EUR 15 million or 2.5 percent of worldwide annual turnover, whichever is higher, for breaches of the essential requirements and of the manufacturer obligations in Articles 13 and 14; up to EUR 10 million or 2 percent for other obligations; up to EUR 5 million or 1 percent for supplying incorrect information. Open-source software stewards, the foundations and similar bodies that support projects without selling them, have a separate and lighter set of duties under Article 24. The reporting duty that starts on that date sits with whoever puts the product on the market.

What manufacturers must know about open-source components

Due diligence at integration. Article 13(5): "manufacturers shall exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product with digital elements, including when integrating components of free and open-source software that have not been made available on the market in the course of a commercial activity." That last clause is the ordinary unpaid library. Recital 34 lists what that can mean, proportionate to the risk, including "verifying that a component receives regular security updates, such as by checking its security updates history".

The bill of materials. Annex I, Part II, point 1: "identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products". That applies formally from December 2027. In practice you need it today: you cannot report an exploited vulnerability in a component within 24 hours if you do not know the component is there.

The support period. Article 13(8): vulnerabilities must be handled for the support period, and "the support period shall be at least five years" unless the product is expected to be in use for less. Five years is longer than many packages stay maintained.

What this means for a dependency list

A production application with a large JavaScript dependency tree resolves to hundreds or thousands of packages once transitive dependencies are counted. That duty turns that list into a set of clocks. For each of those packages, the manufacturer is the one who has to notice an exploited vulnerability, who has 24 hours to say so, and who has to ship or obtain a fix during a support period of at least five years. The upstream maintainer has none of those duties. When a maintainer stops, the obligation does not stop with them; it stays with the product.

So the useful question is not only "what is in the product" but "which of these packages will still be there when I need a patch". A security-updates history answers that for the past. The regulation's own due-diligence language, proportionate to the risk, wants some view of what happens next.

Why a static SBOM is not a risk assessment

An SBOM records what was in the product on the day it was generated. It says nothing about whether the maintainer of a top-level dependency will still be there when, in year three of a five-year support period, an exploited vulnerability lands and the fix has to come from upstream.

A repository can stop getting commits without a CVE ever being filed, and the SBOM stays complete right up to the day nobody is there to ship the patch. A bill of materials records what is in the product. It says nothing about whether the repository will keep up its commit pace or publish a release.

Where a dated probability with a public score fits

Anteproof tracks npm, PyPI and crates.io packages and their source repositories. For the repositories it samples — not for everything it tracks — it asks two questions: will the default branch receive at least K commits in the next 90 days (K is the repository's own count from the previous quarter), and will there be at least one release. The live coverage counts are published on the site and move as the set grows. A forecast on either goes into an append-only log that we anchor to a public repository once a day, and it is scored in public when the window closes.

What those questions return today. A probability, and no track record to judge it by. /v1/risk answers with a live maintenance forecast wherever the question is open; what we withhold is the scoring behind it. We retired the backtest pool after finding that the event feed it resolved against had failed, so no score for these families is published; the calibration page carries the withheld verdicts and the reason. We will not publish numbers we cannot stand behind. If you call the endpoint today, expect a probability and a withheld track record, which is the system working rather than breaking.

Two ways in, today. Upload the CycloneDX or SPDX document you already produce at anteproof.com/account. Dependencies we cover are matched, and you can keep some of them on a watchlist; each one shows up on your entity pages with every live question we ask about it. Or ask for one package at a time: the dependency_risk tool answers the maintenance question for a package or repository in one call, from the API or from an MCP client, and says so plainly where the score is withheld.

What that is meant to give a manufacturer is a record: on this date, for this component, we consulted a forward-looking estimate that can be checked against what happened. Whether that meets any due-diligence standard is a question for counsel. What we can say today is narrower and worth more than a number: when the measurement behind an answer stopped being trustworthy, we withdrew it in public rather than keep serving it.

What Anteproof cannot yet show

We do not claim skill on the maintenance questions. We are not showing their scores at all. We ran a large point-in-time backtest of both families, and running it is how we found that our own data source had failed: the public GitHub event feed we resolve against lost most of its push, star and release events during 2026, so those outcomes measure our instrument rather than the projects. Every one of those resolutions was scored against that feed, so we withhold the results rather than publish numbers we cannot stand behind. We have voided live forecasts before they could resolve on a broken measurement. The reason is published on each. The skill we can show today is on different, short-horizon question types, not maintenance; the calibration page names them and shows the score: anteproof.com/calibration. The current state of every family is on anteproof.com/v1/proof, which is the page to check rather than this article.

We do not scan code or vulnerabilities. We track only packages maintained in the US, EU, UK or allied jurisdictions. We never call a package safe. A probability is not advice.