The Open Source Paradox: Unpacking Risk, Equity, and Acceptance

The Open Source Paradox: Unpacking Risk, Equity, and Acceptance

Speakers: Vincent Dan, VP of Product Security, Red Hat

Conference: VulnCon

YouTube: https://www.youtube.com/watch?v=tcN9Xfl_jtg

Overview

In this thought-provoking VulnCon presentation, Vincent Dan, VP of Product Security at Red Hat, addresses the inherent paradox in how the security of open source software is perceived and managed compared to its proprietary counterparts. Drawing on over 25 years of experience in open source security, Dan argues that the very transparency that defines open source – its open code, public bug reporting, and visible vulnerabilities – often leads to an unfair and counterproductive assessment of its security posture. He asserts that while open source has become the dominant force in software development, the rules for assessing its risk have failed to evolve, resulting in an overemphasis on vulnerability counts rather than actual exploitation risk.

Dan’s central thesis challenges the conventional wisdom that equates a high number of reported Common Vulnerabilities and Exposures (CVEs) with increased risk. Through a data-driven analysis, he demonstrates that a disproportionately small percentage of vulnerabilities are ever actively exploited, and that the vast majority of successful breaches stem from human error, misconfigurations, and process failures, not software flaws. The talk advocates for a more mature, contextual, and risk-based approach to security that acknowledges the unique characteristics of open source transparency and encourages a re-evaluation of how organizations prioritize their defensive efforts.

This discussion is particularly pertinent given the current landscape of escalating supply chain attacks, new regulatory frameworks like CRA, and the pervasive integration of open source components across nearly all software. Dan aims to shift the narrative, highlighting that open source's transparency, while sometimes a compliance challenge, is ultimately a strength that empowers users with knowledge and options, unlike the opaque nature of proprietary software. The article will delve into the details of his arguments, supported by compelling statistics and real-world examples.

Background

▶ Watch: Speaker's background and open source security focus (0:00)

The landscape of software security has undergone a dramatic transformation over the past two decades, marked by an exponential increase in reported vulnerabilities. Since the inception of the CVE program in 1999, the annual number of new CVEs has grown by an astonishing 4,400% by 2024. This surge can be attributed to several factors: the rapid development and deployment of new software, increased adoption of CVE reporting by vendors, and, notably, the Linux kernel becoming a CNA (CVE Numbering Authority), which significantly drove up reported numbers in recent years. For instance, the Linux kernel alone contributed to 69% of all vulnerabilities affecting Red Hat products between 2023 and 2024, leading to a 138% increase in total CVEs for Red Hat.

However, Dan emphasizes that the sheer volume of reported CVEs is a misleading indicator of actual risk. He points out that not all vulnerabilities matter; many are never exploited, and even if exploited, they may not lead to a compromise. To illustrate this, he references the CISA (Cyber Security and Infrastructure Security Agency) Known Exploited Vulnerabilities (KEV) database, which tracks vulnerabilities actively exploited in the wild. While CVE numbers have skyrocketed, the rate of exploitation has remained relatively steady, consistently below 1% of known vulnerabilities. This suggests a significant disconnect between the number of reported flaws and their real-world impact.

Further underscoring this point, Dan cites Verizon's annual Data Breach Investigations Report (DBIR). Year after year, the DBIR consistently shows that breaches due to software exploitation constitute a small fraction of the total. In 2022, only 7% of breaches were attributed to exploited software vulnerabilities, dropping to 5% in 2023. While the 2024 report saw an increase to 15%, this was largely driven by a single, highly publicized vulnerability: MoveIt – notably, a piece of proprietary software. The overwhelming majority of breaches, according to Verizon, stem from "human exploitation" factors such as stolen credentials, business email compromise (BEC), phishing campaigns, misconfigurations, and weak passwords. Dan argues that even the lack of patching when fixes are available falls into this "people and process" bucket, not a technology problem.

The talk also highlights the pervasive nature of open source software. The 2025 BlackDuck Open Source Security and Risk Analysis report, which scanned 1,600 codebases, found that 97% contained open source components, and 70% of all code originated from open source projects. This widespread adoption signifies that open source has "won" and is now the norm, not an outlier. Yet, Dan observes that while software development rules have changed, the rules for assessing software risk have not. Open source's inherent transparency – where code, reports, and bugs are openly visible – means that anything that remotely resembles a security issue, regardless of its improbability or low impact, is often labeled and disclosed as such. This transparency, while a core tenet and strength of open source, creates a "paradox" where it is often judged more harshly than opaque proprietary software, which can selectively disclose vulnerabilities.

Key Findings

▶ Watch: Distinguishing vulnerabilities from actual exploited compromises (4:00)

Vincent Dan's presentation delivers several critical findings that challenge conventional wisdom in software security:

1. The Open Source Transparency Paradox: Open source software, by its very nature, is transparent. Its code is open, vulnerability reporting is public, and bugs are visible. This transparency means that a large volume of potential security issues, including many of low or moderate severity, are openly disclosed. Dan presents data from Red Hat showing that over 92% of vulnerabilities affecting their products are rated moderate or low. In contrast, proprietary vendors, who operate with opaque codebases, are under no obligation to disclose minor issues. This leads to a skewed perception where open source appears to have far more vulnerabilities, while proprietary software's reported numbers are artificially lower, often focusing only on critical and important issues. This disparity creates an unfair standard for risk assessment, penalizing open source for its transparency.

1. Vulnerability Count vs. Actual Risk: The sheer number of reported CVEs has increased by 4,400% from 1999 to 2024. However, Dan demonstrates that this growth does not correlate with a similar increase in actual exploitation or successful breaches. Less than 1% of known vulnerabilities are ever exploited, and an even smaller percentage lead to compromise. The CISA KEV database and Verizon DBIR consistently show that human factors (phishing, misconfigurations, weak passwords) are responsible for the vast majority of breaches, not software vulnerabilities. This finding underscores that focusing solely on CVE counts is a "red herring" and diverts resources from addressing more impactful security vectors.

1. Misapplication of CVSS: A significant finding is the widespread misuse of CVSS (Common Vulnerability Scoring System). Dan explicitly states, referencing the CVSS user guide, that "CVSS base scores do not measure risk." Instead, CVSS is designed as a prioritization mechanism to help organizations decide which vulnerabilities to address first among a dozen, not to quantify overall risk. Many security tools and practitioners, however, incorrectly equate a high CVSS score with high risk, leading to misinformed patching strategies and an inefficient allocation of security resources.

1. The Cost of Blind Patching: The talk highlights that blindly patching every reported vulnerability, especially low and moderate ones, introduces its own set of risks and costs. Code changes, even for minor security fixes, can introduce new, unknown vulnerabilities, cause system instability, or negatively impact performance. The Spectre/Meltdown example vividly illustrates this, where fixes required thousands of person-hours, led to significant performance degradation (e.g., disabling SMT), and were implemented for vulnerabilities that saw no known real-world exploitation. This "cure worse than the disease" scenario suggests that a pragmatic approach to risk acceptance for lower-severity issues is often more beneficial than chasing a "no known vulnerabilities" ideal.

1. Defenders Must Focus on Contextual Risk: Dan advocates for a shift from a purely vulnerability-centric view to a contextual risk assessment. This involves understanding the specific environment, application usage, and potential exposure paths for a vulnerability. For example, a CVE in a kernel driver for hardware not present in the environment, or a vulnerability in a component used as "internal plumbing" with no path to execution, may be safely ignored. Red Hat's practice of rating the same component differently in Red Hat Enterprise Linux (RHEL) versus Red Hat OpenShift based on its deployment context exemplifies this contextual approach. This allows organizations to focus resources on truly impactful threats, rather than noise.

Technical Deep Dive

▶ Watch: Odds of successful software exploitation are vanishingly small (5:50)

Dan’s presentation meticulously dissects the data to reveal the nuances of open source security. He begins by illustrating the staggering growth of CVEs, noting a 4,400% increase from 1999 to 2024. This escalation saw a 125% increase around 2017, followed by another 50% jump in the subsequent six years, culminating in the largest single-year increase ever recorded last year. A significant driver of this recent growth, as highlighted by Dan, is the Linux kernel becoming a CNA, leading to a massive influx of reported vulnerabilities. For Red Hat, the Linux kernel accounted for 2,760 CVEs, representing 69% of all vulnerabilities affecting their products and contributing to a 138% increase in Red Hat's overall CVE count between 2023 and 2024.

Despite this explosion in CVEs, Dan presents compelling evidence that exploitation rates remain remarkably low. He points to the CISA KEV database, which confirms that while the number of vulnerabilities grows, actual exploitation does not keep pace. Historically, less than 1% of known vulnerabilities are ever exploited. The Verizon DBIR further supports this, showing that in 2022, only 7% of breaches were due to exploited software vulnerabilities, declining to 5% in 2023. While the 2024 report showed a spike to 15%, this was heavily skewed by the widespread exploitation of the MoveIt vulnerability, which notably affected proprietary software. The persistent top contributors to breaches remain stolen credentials, business email compromise, phishing campaigns, and improperly configured software—all human or process-related issues.

A core technical argument revolves around the disparity in vulnerability reporting between open source and proprietary vendors. Dan provides a stark comparison using preliminary 2024 data from Red Hat (an enterprise open source vendor) and a major proprietary vendor.

Red Hat (Open Source):

• Total Vulnerabilities Discovered: 4,272
• Severity Distribution:
• Critical: <0.25%
• Important: <8%
• Moderate/Low: 92% (e.g., over 200 moderate CVEs in 2023, none known to be exploited)
• Exploitation Rate: Very low, with only 3 out of over 3,300 moderate/low vulnerabilities known to be exploited in 2023.

Proprietary Vendor (Public Data):

• Total Vulnerabilities Reported: 1,397 (with only 1,121 having a severity rating)
• Severity Distribution:
• Critical: 28% (28 times higher than Red Hat's percentage)
• Important: 88%
• Moderate/Low: 5.5% (of these, 41 were in publicly known open source components)
• Overall Exploitation Rate: Significantly higher than Red Hat's, particularly among moderate issues, despite fewer total reported vulnerabilities.

Dan highlights that the proprietary vendor's numbers are "inverted" compared to Red Hat's, with a much higher proportion of critical and important vulnerabilities reported and a minuscule percentage of moderate/low. He infers that this is not due to superior development practices but rather selective disclosure. Proprietary vendors often only report critical and important issues, ignoring or silently fixing moderate and low ones, or not even looking for them. This opacity stands in stark contrast to open source's transparency, where everything is visible.

The talk also delves into the critical distinction of contextual risk assessment. Dan explains how Red Hat assigns different severity ratings to the same component based on its deployment context. For instance, a component in Red Hat Enterprise Linux (RHEL) might be rated higher than in Red Hat OpenShift. In RHEL, as a general-purpose operating system, Red Hat assumes a worst-case scenario because the specific usage is unknown. In OpenShift, however, if the component is used as "internal plumbing" with no user access or path to exploitation, its risk is rated lower. This demonstrates a pragmatic approach to risk that goes beyond generic CVSS scores.

Speaking of CVSS, Dan emphatically states that its base scores "do not measure risk"—a point that garnered applause from the audience. He clarifies that CVSS is a prioritization mechanism, designed to help sequence vulnerability remediation, not to quantify the total risk to an organization.

Finally, Dan uses the Spectre and Meltdown vulnerabilities (discovered in early 2018) as a powerful case study. Red Hat spent over 8,000 person-hours across 20 kernel releases to address these, engaging weekly calls with Intel and daily internal discussions. The primary "fix" involved disabling Simultaneous Multi-threading (SMT), which significantly degraded performance and increased compute costs. Despite this enormous effort, Dan notes that no evidence of real-world exploitation by weaponized code was observed for three years, and even then, actual compromises were not reported. This exemplifies how fixing vulnerabilities can introduce new, significant operational risks and costs, highlighting that sometimes "the cure is worse than the disease." He also references the Borland Interbase incident from 2001, where a hardcoded user and password existed for seven years, only to be discovered and fixed when the project became the open source Firebird database, showcasing transparency's role in ultimately improving security.

Demo / Proof of Concept

▶ Watch: People and process are the vast majority of breach sources (6:20)

The presentation was primarily an analytical discussion, relying on statistical data, real-world case studies, and comparative analyses of vulnerability reporting practices. It did not feature a live demo or proof of concept of any specific exploit or tool.

Defensive Implications

▶ Watch: Move It vulnerability highlights proprietary software risks (7:50)

Vincent Dan's analysis provides crucial insights for defenders looking to optimize their security strategies in an increasingly open source-driven world. The primary implication is a call to move beyond a simplistic, vulnerability-count-driven approach and embrace a more nuanced, risk-based security posture.

1. Prioritize Actively Exploited and High-Impact Vulnerabilities: Defenders should shift their focus from patching every reported CVE to prioritizing those that are actively exploited in the wild, as tracked by databases like the CISA KEV, and those rated as critical or important due to their ease of exploitation and high potential impact. Red Hat’s strategy of treating any moderate or low vulnerability that becomes actively exploited as a critical issue and patching it immediately is a pragmatic model. This approach ensures resources are allocated to addressing genuine, immediate threats, rather than expending effort on issues with vanishingly small chances of exploitation.

1. Address the Human Element and Misconfigurations: Given that stolen credentials, phishing, business email compromise, and misconfigurations are the leading causes of breaches, organizations must re-prioritize investments in these areas. This includes robust security awareness training, strong identity and access management (IAM) practices, multi-factor authentication (MFA), and rigorous configuration management. Dan explicitly states that if 80% of security budgets are spent finding software vulnerabilities that don't get exploited, while 80% of breaches happen due to human factors, priorities are fundamentally wrong.

1. Implement Contextual Risk Assessments: It is imperative to perform contextual risk assessments that consider the specific environment, application, and usage patterns of software components. A vulnerability's severity can vary dramatically based on how the component is deployed and whether there's an actual path to exploitation. Defenders should ask: Is the vulnerable component exposed? Is it accessible to untrusted input? Is the affected hardware present? For example, ignoring a CVE in a kernel driver for hardware not present in the environment or a tar vulnerability in a container that doesn't process untrusted remote input is a sensible, risk-aware decision. This prevents "noise" from overwhelming security teams and allows focus on truly actionable risks.

1. Manage Software Life Cycles Proactively: The anecdote about Adobe Flash exploitation years after its end-of-life, and the "Swiss cheese" analogy for unsupported software, underscore the critical importance of keeping software within vendor-supported life cycles. Organizations must plan for upgrades and migrations, rather than relying on endless patching of outdated systems. This dramatically reduces overall risk by eliminating vast swathes of known, unfixed vulnerabilities.

1. Challenge Overtly Strict Compliance Interpretations: Many compliance frameworks provide latitude for risk-management methodologies, but organizations often over-interpret these, leading to rigid "fix all CVEs" mandates. Defenders should engage with internal auditors and compliance officers to advocate for risk-based interpretations that align with actual business impact. Downtime due to unstable patches, performance degradation, or the cost of fixing non-impactful vulnerabilities can be far more damaging to a business than the accepted risk of a low-severity, unexploited bug. This requires framing risk in its totality—considering business continuity, operational costs, and stability alongside security.

1. Embrace Open Source Transparency as an Advantage: Instead of penalizing open source for its transparency, defenders should leverage it. Knowing about lower-severity vulnerabilities in open source provides options: mitigate without patching, implement compensating controls, or, if truly critical, seek a fix or replace the component. This is a power that proprietary software users often lack, as they implicitly accept unknown risks.

Key Takeaways

• Open source transparency creates a paradox: While it reveals a high volume of vulnerabilities (many low/moderate), this openness is often unfairly penalized compared to opaque proprietary software, which selectively discloses issues.
• CVE counts are a poor indicator of real risk: The exponential growth in CVEs does not correlate with exploitation rates, with less than 1% of known vulnerabilities ever being actively exploited.
• Human factors drive most breaches: The vast majority of successful breaches stem from misconfigurations, stolen credentials, phishing, and other human/process-related weaknesses, not from exploited software vulnerabilities.
• CVSS is a prioritization tool, not a risk measure: CVSS base scores help prioritize which vulnerabilities to address first; they do not quantify the overall risk to an organization.
• Contextual risk assessment is essential: Defenders must move beyond blind patching and implement nuanced risk assessments that consider the specific environment, application usage, and actual path to exploitation for each vulnerability.
• Blind patching introduces its own risks: Fixing every vulnerability, especially low-severity ones, can introduce new bugs, cause instability, degrade performance, and divert resources from more impactful security efforts.

About the Speaker(s)

Vincent Dan is the Vice President of Product Security at Red Hat, bringing nearly 25 years of extensive experience in the field of open source security. Prior to his 16-year tenure at Red Hat, he spent eight years at Mandriva (formerly MandrakeSoft), a pioneering Linux distribution company. His deep involvement in the open source community includes contributions to numerous upstream security teams, such as PHP and WebKit. He even created and maintained his own Linux distribution for five years, gaining firsthand experience in the challenges and rewards of open source development and maintenance. Dan's long and varied career has provided him with a unique perspective on the complexities of securing open source software and understanding the differences in risk perception between open and proprietary ecosystems.