Every year, thousands of Common Vulnerabilities and Exposures (CVEs) get assigned to software components with no clear owner. A research team finds a flaw in a library that was abandoned by its original developer, or a hardware vendor goes out of business and leaves its firmware orphaned. The CVE exists, the risk is real, but nobody steps forward to ship a patch. The result is a patch vacuum that shifts the financial burden onto everyone downstream: the enterprises that deploy the component, the insurers who underwrite their risk, and ultimately the taxpayer who funds public-sector breaches.

The Patch Vacuum: When CVE Ownership Is a Legal Black Hole

The CVE system was designed to give security researchers a common language to describe vulnerabilities. The MITRE Corporation maintains the list, and CVE Numbering Authorities (CNAs) assign identifiers. But the system was never designed to answer the question of who is financially responsible for fixing the flaw. When a CVE is assigned to a component with no active maintainer, the ownership question becomes a legal black hole.

End-of-life hardware is a prime example. A network switch that reached its end-of-life in 2015 may still be running in a factory, because replacing it costs more than the risk of a breach. The vendor no longer issues firmware updates, but the device is still exposed to the internet. When a CVE is found in that firmware, the vendor's legal team is unlikely to volunteer a patch, because doing so would imply ongoing support obligations.

Custom firmware compounds the problem. Many industrial control systems run on bespoke software written by a systems integrator that has since dissolved. The CVE gets assigned, but there is no legal entity to contact. The customer who bought the system is left holding the bag, and their contract with the integrator probably has a clause that limits liability to the original purchase price, which is often a fraction of the cost of a breach.

Contract clauses rarely cover this scenario. Most software licensing agreements include a disclaimer of warranties and a limitation of liability, but they do not address what happens when the vendor disappears. The result is that the user bears the full cost of the vulnerability, from incident response to regulatory fines.

Consider the case of a regional hospital that relied on a medical device running an embedded operating system that reached end-of-life in the late 2010s. When a critical vulnerability was disclosed in that OS, the device manufacturer had already discontinued support, and the hospital's maintenance contract explicitly excluded security updates after the end-of-life date. The hospital faced a choice: replace the device at a cost of tens of thousands of dollars, or continue operating with a known flaw and hope for the best. They chose the latter, and when the device was later compromised, the remediation costs dwarfed the replacement cost. This pattern repeats across sectors, from manufacturing to energy to healthcare.

Who Pays for the Unpatched: The Real Cost Shift

The cost of an unpatched vulnerability is rarely borne by the entity that created the flaw. Instead, it is shifted to the enterprises that deploy the software, the insurers who underwrite their risk, and the public sector that funds breach response.

Enterprises absorb the cost of incident response. When a CVE is exploited, the affected organization has to pay for forensic analysis, system restoration, and notification. A single breach can cost millions of dollars, and the cost is rarely recoverable from the vendor, even when the vendor is still in business. The legal theory of strict liability for software defects has not gained traction in most jurisdictions, so the enterprise is left to negotiate with its cyber insurance provider.

Insurance premiums rise for everyone. As claims from unpatched vulnerabilities mount, insurers adjust their actuarial models. A company that cannot demonstrate a patch management process will see higher premiums, but even companies with rigorous processes are paying more because the overall risk pool is larger. The cost of the patch vacuum is socialized across all policyholders.

Small vendors dodge liability because they have no assets to pursue. A startup that released a library and then dissolved cannot be sued successfully, even if the library is used in thousands of products. The legal costs of pursuing a defunct entity are prohibitive, so the plaintiff gives up.

Open-source foundations stretch their budgets to cover orphaned projects. The Linux Foundation, the Apache Software Foundation, and others often step in to maintain critical projects that lose their original maintainers, but their resources are limited. A foundation cannot patch every abandoned library, and it has no obligation to do so.

Taxpayers fund public-sector breaches. Government agencies are required to use certain software, and when that software has an unpatched vulnerability, the cost of the breach falls on the agency's budget, which is ultimately funded by taxpayers. The post-breach forensics are often more expensive than the patch would have been.

Let's put numbers on it. The average cost of a data breach in 2024 was around $4.88 million, according to a widely cited industry report. For a small or medium enterprise, that figure can be crippling. Meanwhile, the cost of developing a patch for a moderate vulnerability might be in the range of $10,000 to $50,000, depending on the complexity. The asymmetry is stark: a patch that costs a few thousand dollars can prevent a breach that costs millions. Yet the vendor has no incentive to spend that money if the product is no longer generating revenue.

The Money Trail: How Vendors Monetize Ambiguity

Vendors have a financial incentive to keep CVE attribution ambiguous. By not claiming ownership of a vulnerability, they avoid the cost of developing and testing a patch, and they avoid the legal liability that comes with admitting a flaw exists.

Support contracts exclude legacy products. A typical support contract covers a specific version of a product for a set period. Once that period ends, the vendor has no obligation to provide security updates. The customer is told to upgrade, but the upgrade path may be expensive or technically disruptive, so the customer stays on the old version and accepts the risk.

Paid extended lifecycle is a premium service. Some vendors offer extended support for an additional fee, but that fee is often higher than the cost of a new license, and it only covers a limited set of updates. The vendor monetizes the customer's fear of change.

Mergers and acquisitions leave orphaned product lines. When a company is acquired, the acquiring company may decide to discontinue certain products. The CVE for those products is still valid, but the new owner has no incentive to patch something it no longer sells. The customers who bought the product are left with no support.

Security research budgets are often marketing. A vendor may fund a security team that discovers vulnerabilities in its own products, but the findings are often used in marketing materials to demonstrate the vendor's commitment to security. The actual patch development is a separate budget item that may be underfunded.

Attribution disputes delay fixes. When a vulnerability is found in a component that is used by multiple vendors, each vendor may claim that the flaw is in the other's code. The CVE gets assigned, but the fix is delayed while the vendors argue about who should take responsibility.

Consider a real-world example from the open-source ecosystem. In 2014, the Heartbleed bug in OpenSSL was a textbook case of a widely used component with a single maintainer and no commercial backing. The fix was developed by volunteers, but the cost of patching millions of systems fell on the organizations that used OpenSSL. A similar situation occurs with smaller libraries that are dependencies in countless applications. When a CVE is assigned to such a library, the maintainer may be a single individual who cannot realistically patch it in a timely manner, or may have abandoned the project entirely.

Market Incentives That Reward Non-Attribution

The market rewards vendors who avoid claiming CVE ownership. There is no revenue in owning a CVE, only costs. A vendor that publicly acknowledges a vulnerability in its product may see a short-term dip in its stock price, even if the vulnerability is minor and the patch is released quickly.

Patch release costs real money. Developing, testing, and distributing a patch requires engineering time, which is a finite resource. A vendor may prioritize new features over patching old ones, especially if the old product is no longer a revenue driver.

Legal teams fear admitting liability. Once a vendor acknowledges a vulnerability, it may be used against them in a lawsuit. The legal team's job is to minimize liability, so they may advise against making public statements about the vulnerability.

Analyst reports punish disclosed flaws. Security analysts who rate products may penalize a vendor for having a high number of CVEs, even if the vendor is proactive about patching. The vendor is caught in a double bind: if it discloses vulnerabilities, it looks insecure; if it hides them, it is unethical.

Shareholder pressure on earnings. A vendor that spends money on patching old products is spending money that could be returned to shareholders. The pressure to meet quarterly earnings targets discourages long-term investment in security.

But is this always the case? Some vendors have found that a strong security posture can be a differentiator. For example, a vendor that publicly commits to a clear patch policy and maintains a transparent vulnerability disclosure process may win enterprise customers who value security. In that sense, the market can reward proactive patching, but only if buyers signal that they care. The problem is that many buyers do not ask about patch guarantees until after a breach occurs.

What a Vendor-Neutral Attribution Model Would Cost

One proposed solution is a vendor-neutral attribution model, where an independent body assigns responsibility for a CVE and coordinates the patch. This model would require funding, and the question is who pays.

A central clearinghouse would need a budget for staff, infrastructure, and legal fees. The annual budget could be in the tens of millions of dollars, a tiny fraction of the global cyber insurance market, which is estimated to be worth over $14 billion as of 2024.

Fees per CVE or a subscription model could fund the clearinghouse. Vendors could pay a subscription fee based on the number of CVEs they have, or a per-CVE fee for each vulnerability they claim. The fee would be small relative to the cost of a breach, but it would create a financial incentive to claim ownership.

Independent auditors would be needed to verify that the responsible party is actually patching. The auditors would need access to the vendor's source code and testing processes, which raises confidentiality concerns.

Liability caps for small firms would protect startups from the cost of a large-scale breach. A small firm that cannot afford to patch every vulnerability might be given a pass, but only if it discloses the vulnerability and provides a workaround.

Some estimates suggest that a vendor-neutral attribution model could cost as little as 0.1% of cyber insurance premiums, a rounding error for most companies. The benefits would be lower insurance claims, faster patch times, and a clearer legal landscape.

However, there are trade-offs. A central clearinghouse could become a bottleneck, slowing down the patch process if it lacks resources or authority. It might also face resistance from vendors who do not want to cede control over their security response. And the funding model could be contentious: if vendors are required to pay, they may pass the cost on to customers, ultimately increasing software prices. Alternatively, if the clearinghouse is funded by taxpayers, it could be seen as a subsidy for the software industry.

Practical Levers for Buyers and Builders

While the industry waits for a systemic solution, buyers and builders can take practical steps to reduce their exposure to the patch vacuum.

Contract for patch guarantees. When negotiating a software license, include a clause that requires the vendor to provide security patches for a specified period, even after the end-of-life date. The clause should specify a reasonable timeframe for patch release and a penalty for non-compliance.

Audit supply-chain ownership terms. Before adopting a third-party component, review the license and support terms. If the component is an open-source project, check the maintainer's track record and the project's bus factor. The maintainer onboarding process can be a good indicator of long-term health.

Budget for orphaned component risk. In your security budget, allocate a line item for the risk of using orphaned components. This could be a fund for emergency patching or a reserve for potential breach costs.

Demand a Software Bill of Materials (SBOM) with maintainer contacts. An SBOM is a list of all the components in your software, and it should include the contact information for each component's maintainer. This makes it easier to reach out when a vulnerability is discovered.

Push for industry standards via CISA. The Cybersecurity and Infrastructure Security Agency has been active in promoting SBOMs and other supply-chain security measures. As a buyer, you can ask your vendors to comply with CISA's guidance, which creates market pressure.

But these levers have limits. Small organizations may lack the negotiating power to demand patch guarantees from large vendors. And even with an SBOM, the maintainer's contact information may be out of date. Furthermore, contract clauses are only as good as the vendor's willingness to honor them; if the vendor goes bankrupt, the clause is worthless. So while these steps are necessary, they are not sufficient.

The Bottom Line: Someone Always Pays, Usually You

Patch ambiguity is a hidden tax on every organization that uses software. The cost of a vulnerability is not zero, and if the vendor does not pay it, you do. The question is whether you pay it in the form of a breach, an insurance premium, or a procurement decision.

Attribution is a business decision, not a technical one. Vendors weigh the cost of patching against the cost of not patching, and they often choose not to patch because the consequences are delayed and diffuse. The market has not yet priced in the full cost of the patch vacuum, but it is starting to.

Collective action lowers costs. When buyers demand patch guarantees and SBOMs, vendors will have to respond. Industry standards, such as the ones CISA is promoting, can level the playing field and make it easier for everyone to do the right thing.

Start with your own procurement. The next time you renew a software license, ask the vendor what happens when a CVE is assigned to a product they no longer support. The answer may surprise you, and it will inform your decision.

Hedging my conclusion: the costs vary by sector. A financial institution that faces regulatory penalties for a breach will have a different calculus than a small manufacturer. The patch vacuum is not a one-size-fits-all problem, and the solution will not be either.

In the end, the only way to close the patch vacuum is to make non-attribution more expensive than attribution. That means legal reforms that hold vendors accountable for the security of their products, even after end-of-life, and market mechanisms that reward transparency. Until then, the burden will continue to fall on the most vulnerable link in the chain: the user.