Open-source risk is a maintainer problem, not a CVE count

What it says#

The article's claim is compact: open source is critical infrastructure, and the risk that ends projects is not a vulnerability in the code but the absence of people and money behind it. Enterprises consume components the way they consume electricity, scan them for known vulnerabilities, and never ask who maintains them.

It builds the case on three projects. Ingress NGINX, the ingress controller behind a large share of Kubernetes environments, is the one we could check against its own project. In January 2026 the Kubernetes Steering and Security Response Committees announced that the project retires in March 2026 ¹. After that there are no more releases, bug fixes or security patches of any kind ¹. The same statement says the project had been kept alive by only one or two volunteers, unpaid, on their own time ¹. The article's other two cases, FFmpeg and Flux, are told as near misses: a maintainer base kept going by outside funding, and a project that outlived the company employing its developers. We report those two as the article tells them.

From the cases the piece derives a formula: open-source risk equals people risk plus funding risk plus governance risk plus security risk. It then observes that the tools most organisations run answer only the last term. Scorecards, criticality scores, build attestations and software bills of materials say nothing about who is paid to fix the next bug.

The proposed remedy is a health review beside the security and licence reviews. It scores maintainer depth and employer diversity, release cadence over twelve months, time to fix serious defects, clarity of governance, commercial or foundation backing, and the cost of migrating away. Components are tiered by business importance, engineers spend fixed hours upstream on the core tier, budget goes to subscriptions or sponsorship, and an exit plan exists before a project stalls.

What we take from it#

The formula is the useful part, and it maps cleanly onto obligations that already exist. NIS2 asks essential and important entities for supply chain security, including the relationships with their direct suppliers ². The Cyber Resilience Act asks a manufacturer to exercise due diligence when integrating third-party components, open source included ³. It also asks the manufacturer to report a vulnerability it finds in such a component upstream ⁴. Neither obligation is satisfied by a scanner. Both are satisfied by a record that names the component, its importance, its maintainer situation and the decision taken.

So the health review is not an extra. It is the missing half of a control that most registers already claim to run. In the language of our regulation-to-controls method, the obligation is "supply chain security". The control objective is "every component in the core tier has a current health and security decision", and the evidence is the dated review.

Two practical additions. First, put the health review in the same intake as the licence check, because that gate already exists and already blocks. Second, count the exceptions. A register that lists ten core components with a single maintainer and no sponsor is a finding waiting to be written, whether or not any of them has a CVE this quarter.

Where we would push back#

The article costs its remedy lightly. Fixed engineering hours upstream and paid sponsorship are real money for a mid-sized company, and the piece does not say how to choose when the core tier is longer than the budget. Our answer is the tiering itself: the review is for the components whose outage is a business incident, and that list is short if it is honest.

The three cases also lean towards rescue. FFmpeg and Flux found backers; Ingress NGINX did not. A reader could conclude that critical projects get saved. The retirement statement is the better lesson: a project used by half an ecosystem can still run on two volunteers until it stops.

Related on GRCIDE#

• From regulation to controls, step 3.5, on mapping an obligation to a control and naming the gap.
• NIS2 for the security officer, on Article 21 and the supply chain point.
• CRA obligations by product class, on the component due-diligence duty.