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

What it says#

Open source is critical infrastructure, and the risk that ends a project 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.

The article builds the case on three projects. Ingress NGINX, the ingress controller behind a large share of Kubernetes environments, is the one we could check at source. The Kubernetes Steering and Security Response Committees announced in January 2026 that the project retires that March ¹. 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 ¹. Its 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.

The piece derives a formula from the cases: 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.

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.

The article's 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.

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.