This describes a regulation and where a forecasting tool sits next to it. It is not legal advice; read the regulation and ask counsel what it means for your products.
Today, 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 today 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 regulation entered into force on 10 December 2024. Article 71 sets three application dates:
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".
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.
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 today sits with whoever puts the product on the market.
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.
A production application of ordinary size resolves to a few thousand packages once transitive dependencies are counted; four thousand is not unusual. Today's 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 four thousand 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.
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.
Most dependency incidents do not begin with a CVE; they begin with a repository that goes quiet, and the SBOM stays complete right up to the day nobody is there to ship the patch. The eleven lines in the video were a package with a maintainer who left. Nothing in any bill of materials would have flagged it the week before.
Anteproof asks, for each tracked npm, PyPI and crates.io package and its source repository, 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. A forecast on either is sealed with a public timestamp before the outcome is knowable, anchored daily to a public log, and scored in public when the window closes.
What those questions return today. Nothing, on most packages, and deliberately. We
retired the backtest behind both families this week after finding that the event feed they resolved
against had failed, so /v1/risk answers null rather than a number we cannot
stand behind, and the calibration page shows the families withheld. Resolution is moving to GitHub's own
API. If you call the endpoint today expecting a probability, you should get a null, and that is the
system working rather than breaking.
Two ways in when they resume. Upload the CycloneDX or SPDX document you already produce at
anteproof.com/account and
every matched entry gets its question id, the resolution rule and the family's scoring history. 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 when the answer is
currently 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.
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 two live forecasts rather than let them resolve on a broken measurement, with the reason published on each. We are migrating resolution to GitHub's own API and will publish these families' scores when they mean what they say. The first live questions resolve from January 2027. The skill we can show today is on a different question type, 7-day news-tone questions, n=900, Brier skill 0.112, on 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.