Software security is trapped in an uncomfortable contradiction. Organisations increasingly demand visibility into vulnerabilities, dependencies and the software supply chain, but when that visibility appears in the form of thousands of public CVEs, it is often interpreted as a sign of higher risk. Open source is therefore penalised for one of its greatest strengths: showing what others hide, downplay or silently fix with little public explanation.
Red Hat has highlighted an issue that many companies already face in their vulnerability management programmes. The old idea of “patch everything” no longer works at today’s scale. In 1999, the first year of the CVE programme, hundreds of vulnerabilities were catalogued. In 2024, the figure exceeded 40,000, driven by the maturity of the system, the addition of more numbering authorities and the Linux kernel becoming a CNA.
The problem is not that there are more visible vulnerabilities. The problem is that many organisations still treat every CVE as if it carried the same urgency. That no longer scales. In complex environments, with thousands of servers, containers, libraries, applications, appliances, OT systems and cloud services, chasing every low-severity vulnerability can consume resources that should be focused on flaws that are genuinely exploitable.
The end of “patch everything”
Modern vulnerability management needs to accept one reality: not all flaws are equal. A remotely exploitable vulnerability that requires no authentication, enables privilege escalation and has public exploit code available cannot have the same priority as a low-impact bug that is difficult to exploit and located in a component that is not exposed.
Red Hat argues that the key criteria should be real-world exploitation and potential impact. It points to sources such as CISA’s Known Exploited Vulnerabilities catalogue, which tracks vulnerabilities actively exploited in the wild and helps security teams prioritise. According to Red Hat’s analysis, historical exploitation rates remain very low compared with the total volume of CVEs, below 0.5% annually. In 2024, only 0.26% of open source vulnerabilities affecting Red Hat software, 11 out of more than 4,200, were known to have been exploited in real-world situations on any platform.
That does not mean the rest should be ignored. It means urgency must be better assigned. In security, the scarce resource is not only budget. It is also team time, maintenance windows, the ability to test patches, tolerance for disruption and the attention of technical leaders.
| Traditional approach | Risk-based approach |
|---|---|
| Count CVEs and demand zero vulnerabilities | Prioritise by exploitation, exposure and impact |
| Treat everything as urgent | Separate critical, important, moderate and low issues |
| Patch by volume | Patch by probable threat |
| Penalise visible software | Compare real risk across all types of software |
| Measure activity | Measure risk reduction |
The phrase “patch everything” may have made sense when environments were smaller and the number of vulnerabilities was manageable. Today it can create a false sense of control. An organisation can close hundreds of low-impact CVEs and still remain exposed to three critical flaws being actively exploited on the internet.
Open source transparency creates bias
Open source exposes more information because its model allows it. The code can be reviewed, flaws are discussed publicly and minor vulnerabilities are often documented more frequently. In proprietary software, by contrast, many low-impact vulnerabilities may go unpublished, be silently fixed or be grouped into advisories with limited detail.
This creates an unfair comparison. If an internal policy requires “zero known vulnerabilities”, open source software will look worse in the metrics simply because it documents more. Not because it is necessarily more dangerous. The opacity of proprietary software does not remove flaws; it only reduces what the customer can see.
Red Hat frames this as an issue of equity. The residual risk that many organisations implicitly accept in closed-source software should also be explicitly assessed in open source. The difference is not only risk, but visibility.
The example cited by Red Hat is striking. In its 2024 Risk Report, 92% of vulnerabilities affecting Red Hat software were classified as moderate or low. In its comparison with a large proprietary software vendor using a similar severity scale, only 5.5% of the vulnerabilities published by that vendor were classified as moderate or low. That difference does not necessarily suggest that one vendor produces far fewer low-impact flaws than another. It may reflect very different disclosure policies.
Counting vulnerabilities is no longer enough
Measuring an organisation’s security by the raw number of pending CVEs is a dangerous simplification. It can be useful as an initial indicator, but not as the sole decision-making criterion. An inventory with 1,000 moderate vulnerabilities in non-exposed components may be less urgent than a single critical vulnerability exploited in an internet-facing system.
Maturity means combining several signals: whether there is active exploitation, whether public exploit code exists, whether the asset is exposed, whether the service is critical to the business, whether sensitive data is involved, whether the flaw enables lateral movement, whether mitigations exist and whether the patch can be applied without breaking production.
| Prioritisation signal | Useful question |
| CISA KEV | Is it being exploited in the real world? |
| Exposure | Is the system accessible from the internet or untrusted networks? |
| Impact | Does it enable remote execution, escalation or access to sensitive data? |
| Asset criticality | Does it affect key business systems? |
| Exploit availability | Is there a working proof of concept or mass exploitation? |
| Mitigations | Can the risk be reduced without immediate patching? |
| Operational cost | What is the impact of applying the patch now? |
This approach does not excuse negligence. On the contrary, it requires more judgement. A team that prioritises well must know what it will not patch immediately and why. That risk acceptance must be documented, reviewed and changed if active exploitation appears or if the asset becomes more exposed.
What security teams should change
The first change is to move away from absolute “zero CVE” policies as an operational goal. In some regulated environments, very strict criteria may be necessary, but even there it is useful to distinguish vulnerabilities by real risk. A policy that does not differentiate ends up creating informal exceptions, fatigue and patches applied without proper testing.
The second is to incorporate exploitation intelligence. CISA’s KEV catalogue, EPSS, threat intelligence, internal telemetry and asset exposure should be part of prioritisation. CVSS remains useful, but it is not enough. A high score does not always mean likely exploitation, and a medium-scoring vulnerability can be urgent if it affects a highly exposed component.
The third is to evaluate open source and proprietary software with the same criteria. If transparency is required from open source dependencies, closed-source vendors should also be expected to provide clear advisories, correction timelines, SBOMs, vulnerability history, real impact and mitigations.
The fourth is to improve the inventory. You cannot prioritise what you do not know. Knowing which versions are running, where, with what exposure and which dependencies each application uses remains one of the hardest tasks. Without SBOMs, an updated CMDB, continuous scanning and business context, vulnerability management becomes an endless list without hierarchy.
The fifth is to accept that transparency is not a defect. Seeing more flaws allows better decisions. Risk does not disappear because a vendor hides it or publishes it with less detail.
A lesson for procurement, compliance and leadership
This debate does not only affect technical teams. It also matters to procurement, legal, compliance and executive leadership. Many software decisions are made through questionnaires that penalise the number of known vulnerabilities without analysing severity, exploitation or disclosure policy. That can lead organisations to choose less transparent solutions instead of safer ones.
A good procurement process should ask how the vendor manages vulnerabilities, how quickly it fixes critical issues, how it communicates risk, whether it publishes SBOMs, which patches it prioritises and which mitigations it provides. The total number of CVEs only makes sense within that context.
There is also a cultural issue. Open source has moved from being seen as a marginal alternative to becoming the foundation of cloud, containers, Kubernetes, Linux, databases, programming languages, frameworks and security tools. Treating its transparency as a weakness means misunderstanding how modern software is built.
The open source paradox in security is that it appears more vulnerable because it allows people to look inside. But opacity is not protection. It is uncertainty. Mature risk management is not about having less information, but about using the information better.
Frequently asked questions
Does open source have more vulnerabilities than proprietary software?
Not necessarily. It usually has more visible vulnerabilities because its transparency model makes it easier to review, document and publish flaws, including low-impact ones.
Why is “patch everything” no longer enough?
Because the volume of CVEs has grown sharply and not all flaws carry the same risk. Prioritising by real-world exploitation, exposure and impact helps security teams use resources better.
What is CISA’s KEV catalogue?
It is a list of vulnerabilities known to be exploited in the real world. It helps organisations identify flaws that should be prioritised over less likely or lower-impact vulnerabilities.
What should a company do with moderate or low vulnerabilities?
It should assess them in context. Some may be temporarily accepted, others may require mitigations and others can be fixed in normal maintenance cycles. The key is to document the decision and review it.
Source: Red Hat, “The open source paradox: Unpacking risk, equity and acceptance”.