How to Answer “What’s Affected?” in Open Source

How to Answer “What’s Affected?” in Open Source

Speakers: Jess Lowe (Software Engineer, Google), Rex Pan (Software Engineer, Google)

Conference: VulnCon

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

Overview

In an era of exponentially increasing software vulnerabilities, accurately identifying "what's affected" in open-source projects has become a critical, yet often elusive, challenge. Jess Lowe and Rex Pan, software engineers on the Google Open Source Security team, presented a compelling talk at VulnCon detailing their innovative approach to this problem through the Open Source Vulnerability (OSV) schema and sophisticated Git graph analysis. Their work addresses the fundamental disconnect between the sheer volume of vulnerability reports and the practical needs of developers and security teams.

The core issue stems from the limitations of traditional vulnerability reporting mechanisms, such as CVEs, which often contain unstructured text and lack the precision needed for automated, artifact-level matching. This leads to a deluge of "junk vulnerabilities" that consume valuable developer time without genuinely enhancing security. Lowe and Pan's presentation illuminates how the OSV schema, coupled with a deep understanding of Git's branching and merging complexities, provides a machine-readable, precise, and actionable framework for determining the exact scope of a vulnerability.

This talk is particularly significant because it offers a pragmatic solution to the "voln-pocalypse"—the overwhelming number of reported vulnerabilities. By moving beyond simplistic version ranges to a more granular, commit-level understanding of vulnerability lifecycles, the OSV approach enables maintainers to prioritize real threats, reduce noise, and ultimately ship features more efficiently while maintaining a robust security posture. It represents a crucial step towards making vulnerability management scalable and effective for the open-source ecosystem.

Background

▶ Watch: The problem: vulnerability overload and developer needs (0:00)

The CVE program, established in 1999, aimed to standardize vulnerability identification, allowing security experts to communicate about specific issues without ambiguity. However, what started with 321 records in its inaugural year has ballooned to an average of one new record every 10 minutes today. This exponential growth has rendered the traditional approach of manually reviewing every vulnerability report, blog post, and patch unmanageable for most organizations, let alone individual open-source projects.

Developers, primarily focused on delivering features, reluctantly engage with security compliance, which often translates to merely reducing the number of alerts from vulnerability scanners. This creates a significant problem: if scanners flag vulnerabilities that don't genuinely affect a project, developers waste countless hours addressing irrelevant issues, leading to "vulnerability fatigue" and a false sense of security. The ideal scenario for developers is an alert-on-artifact workflow, where notifications are precise, indicating exactly which package, binary, or commit is vulnerable.

Achieving this precision is challenging. While the CVE schema has evolved, many records still rely on largely unstructured text. Extracting critical information—such as the affected product, specific versions, and the relevant ecosystem—for automated matching is often difficult. Even more structured data from sources like the NVD (National Vulnerability Database) often relies on CPE (Common Platform Enumeration) strings, which have seen a slowdown in updates, making direct CVE data interpretation more pressing. The speakers highlighted the need for machine-readable version data that clearly delineates where a vulnerability was introduced and where it was fixed.

Recognizing these limitations and encountering their own issues with open-source vulnerability tracking, the Google team developed the Open Source Vulnerability (OSV) schema. This minimal, machine-readable schema was designed to describe vulnerabilities in open-source packages with high fidelity. Notably, OSV's pioneering use of version ranges influenced the inclusion of similar capabilities in the CVE 5 schema. OSV leverages the concept of introduced, last affected, and fixed events, and critically, it accounts for the diverse versioning schemes across different ecosystems, such as SemVer for Rust, PEP 40/40 for Python, and Debian's complex system for Ubuntu. This ecosystem-specific interpretation is crucial for accurate vulnerability assessment.

Key Findings

▶ Watch: Using Git commits for precise vulnerability tracking (6:00)

The central finding presented by Lowe and Pan is that a simplistic, linear interpretation of "introduced" and "fixed" version ranges is fundamentally inadequate for accurately tracking vulnerabilities in real-world open-source projects. While intuitively one might assume a vulnerability introduced in version 1.0 and fixed in 3.0.5 affects all versions in between, this assumption breaks down rapidly when considering common development practices.

The complexities arise from Git's branching and merging patterns, particularly the prevalence of LTS (Long Term Support) branches where fixes are often backported. If a vulnerability is fixed in an LTS branch (e.g., 1.12) and also in a later main branch version (e.g., 2.2.8), simply listing these fixed versions creates ambiguity. A version like 2.0.0 might be higher than 1.12, but if it diverged before the LTS fix was applied, it could still be vulnerable. This necessitates the introduction of "phantom introduced labels" in a version-based schema, leading to messy and counter-intuitive records, as version 3.0 might appear "reintroduced" even if the underlying bug has existed since version one.

The key insight is that the issue lies not with versions themselves, but with the underlying Git commit graph. A fix applied to a 2.0 branch does not automatically mean version 3.0 is fixed, especially if 3.0 diverged earlier or received the fix via a different path. The speakers demonstrated that by utilizing the original Git commits and the project's Git graph, the "introduced" and "fixed" labels can be applied directly to the exact commits that introduced or resolved the issue.

This approach offers several significant benefits:

1. Elimination of Phantom Labels: It removes the need for artificial introduced labels on later versions that merely inherited an existing vulnerability.
2. Patch IDs: Git's patch ID feature, which hashes the diff of a commit, allows for automatic identification of cherry-picked fixes across different branches. This means a single fixed commit can automatically resolve multiple instances of the fix across the graph.
3. Intrinsic Ordering: Git records possess intrinsic chronological ordering, removing the dependency on potentially inconsistent or poorly defined ecosystem-specific versioning rules.

These properties make Git-based tracking a much more robust and precise method for defining vulnerability ranges, forming the bedrock of the OSV schema's advanced capabilities.

Technical Deep Dive

▶ Watch: Formalizing the graph rule for affected commits (12:00)

The core of the OSV schema's precision lies in its ability to deterministically identify affected commits using Git graph analysis. This involves defining a set of rules for how vulnerabilities propagate and are resolved across a project's commit history. The system models each commit as being in one of two states: affected (red) or unaffected (blue).

The basic rules are straightforward:

• When a vulnerability is introduced, the commit bearing the introduced label and all subsequent commits are marked as affected.
• When a vulnerability is fixed, the commit with the fixed label and all subsequent commits are marked as unaffected.
• When a branch is created, it inherits the state of its parent commit.
• Merging branches of the same status is simple: two affected branches merge into an affected commit, and two unaffected branches merge into an unaffected commit.

The complexity arises when merging commits of different statuses (e.g., an affected branch merging with an unaffected branch). The naive assumption that such a merge always results in a fixed commit is flawed, as demonstrated by several edge cases:

1. Fix Branch Merge: If a separate branch is created to fix a vulnerability, and then merged back into the main branch, the merge commit should ideally be considered fixed.
2. Pre-Vulnerability Branch Merge: If a feature branch is created before a vulnerability is introduced on the main branch, and then merged back after the vulnerability is fixed on main, the merge commit might still contain the vulnerable code, or at least its history needs careful consideration. This scenario shows that the history before the merge commit is crucial.
3. Parallel Merge with Cherry-Pick: A developer might cherry-pick a vulnerable commit from main onto a feature branch, while main simultaneously receives a fix. When the feature branch is merged back, the outcome is ambiguous. The OSV approach leans towards marking such ambiguous cases as vulnerable, reasoning that a merge conflict would likely occur, requiring manual resolution. For it to be considered truly fixed, the developer would need to explicitly label that merge commit as fixed.

To address these complexities, the speakers introduced a formal, graph-based rule:

"A commit is only affected if there's a path from an introduced commit to the current commit that does not pass through a fixed commit."

This rule provides a robust heuristic that resolves the aforementioned ambiguous cases:

• For branching before introduction, the path from the merge commit back to the introduced commit contains no fixed commits, so it's correctly marked as vulnerable.
• For branching to fix, a path from the merge commit to the introduced commit does pass through a fixed commit, correctly marking it as fixed.
• For parallel merges, this rule generally resolves to vulnerable, aligning with the heuristic of erring on the side of caution.

The graph-based nature of this rule also allows it to handle more complex scenarios like double introduced vulnerabilities or octopus merges (merges with more than two parents) effectively, yielding sensible results without needing specific rules for each.

A significant caveat to this system is the introduced zero concept. Often, it's impractical or impossible to pinpoint the exact commit that introduced a vulnerability, especially for older projects. In such cases, introduced zero signifies that the vulnerability exists from the very first version of the package. While straightforward for linear versioning, introduced zero presents challenges in Git graphs with multiple root commits or disjoint trees (e.g., when using Git subtrees for vendoring third-party code). Applying introduced zero indiscriminately to all root commits could erroneously mark unrelated code as vulnerable. To mitigate this, the rule is refined: introduced zero only applies to the specific tree root that the vulnerability report references and can be reached by searching backward from the fixed commit. This prevents marking unrelated vendored code or other disjoint histories as vulnerable, ensuring precision even when the initial introduction point is unknown.

Demo / Proof of Concept

▶ Watch: Aggregating vulnerability data from various sources (16:00)

While the talk did not feature a live, interactive demonstration of the OSV system in action, the speakers effectively illustrated the underlying mechanisms and data flow using detailed Git graph visualizations and examples of OSV records. The entire presentation can be considered a conceptual demonstration of the OSV schema's capabilities and the logic behind its Git-based analysis.

The OSV project itself, including the public service OSV.dev, serves as the practical implementation of these concepts. OSV.dev aggregates vulnerability data from various distributed advisory databases, many of which are ecosystem-specific (e.g., Crates.io for Rust). It also ingests data from aggregators like GitHub Security Advisory (GHSA), which provides vulnerability information in the OSV format for ecosystems like Maven and NPM that lack their own public databases. Projects like Curl and Python Interpreter directly supply Git ranges to OSV, offering highly precise, artifact-level vulnerability data.

The OSV system also processes data from the CVE list and NVD. For CVEs that don't provide explicit Git hashes (which is common, with the Linux kernel being a notable exception that provides Git commits, SemVer, and CPEs), OSV attempts to derive Git ranges. It achieves this by normalizing versions found in CVE/NVD records and comparing them against Git tags in a repository. By matching versions to Git tags (which are bookmarks to specific commits), OSV can infer introduced and fixed events. Although this derived data might be less precise than directly provided Git commits (often resolving to release commits rather than exact fix commits, thus hindering cherry-pick detection), it significantly expands coverage, providing valuable information where none would otherwise exist. Once these ranges are established, OSV can enumerate all affected commits and associated tags/versions, making this information available via its API for automated querying.

Defensive Implications

▶ Watch: Q&A: Handling re-introduced vulnerabilities during merges (22:00)

The work presented by Jess Lowe and Rex Pan has profound implications for how organizations and individuals approach software supply chain security. The shift towards precise, Git-commit-based vulnerability reporting and analysis offers several critical advantages for defenders:

1. Reduce Vulnerability Noise and Fatigue: By providing highly accurate "what's affected" information, OSV significantly reduces the volume of irrelevant alerts that security scanners often generate. This allows security teams and developers to stop "chasing ghosts" and focus their efforts on vulnerabilities that genuinely impact their specific project context. This precision is vital in the current "voln-pocalypse" era, where the sheer volume of reports can lead to real threats being lost in the noise.

1. Enable Efficient Remediation: Maintainers can patch or update for real threats with confidence, knowing exactly which versions or commits are truly vulnerable. This efficiency allows them to allocate more time to shipping new features rather than sifting through false positives. The ability to abstract away ecosystem-specific version comparison logic through the OSV API streamlines the remediation process across diverse technology stacks.

1. Improve Reachability Analysis: When vulnerability data includes specific Git commits and even affected function information (as sometimes provided directly by ecosystems), it enables more sophisticated reachability analysis. Tools can determine if the vulnerable code path is actually invoked by the application, further narrowing down the true impact and allowing for highly targeted patching or mitigation strategies, potentially leveraging concepts like VEX (Vulnerability Exploitability eXchange).

1. Standardize and Automate Security Workflows: The machine-readable and unambiguous format of OSV records, especially when using Git commit hashes, makes it significantly easier to automate security processes. Vulnerability scanners can use the OSV API to correlate dependency versions from lock files with known vulnerabilities, providing precise answers about affected software. This standardization is crucial for building robust, scalable software supply chain security solutions.

1. Call to Action for CNAs: The speakers explicitly called upon CVE Numbering Authorities (CNAs) operating in the open-source space to publish Git commits (ideally full hashes) in their CVE records. This would dramatically improve the precision and utility of vulnerability information for the entire ecosystem, making it easier for library maintainers and security researchers to generate accurate reports.

Key Takeaways

• Vulnerability Fatigue is a Major Problem: The explosive growth of vulnerability reports (one every 10 minutes) overwhelms developers and security teams, leading to wasted effort on irrelevant alerts and a failure to address critical issues.
• OSV Schema Offers Machine-Readable Precision: The Open Source Vulnerability (OSV) schema provides a minimal, machine-readable format to describe open-source vulnerabilities, abstracting away ecosystem-specific versioning complexities.
• Git Graph Analysis is Essential for Accuracy: Relying solely on linear version ranges is insufficient. OSV leverages the underlying Git commit graph, applying introduced and fixed labels directly to commits, which is crucial for handling complex branching, merging, and LTS backports.
• Formal Graph Rule Determines Affected Status: A robust rule states that "a commit is only affected if there's a path from an introduced commit to the current commit that does not pass through a fixed commit," effectively resolving ambiguous merge scenarios.
• introduced zero Requires Careful Handling: When the initial introduction commit is unknown, introduced zero must be carefully applied to specific tree roots within the Git graph to avoid incorrectly marking unrelated code as vulnerable.
• Actionable Tooling Empowers Defenders: OSV aggregates and derives vulnerability data from diverse sources (ecosystem databases, GHSA, CVE/NVD) and provides it via an API, enabling tools like VEX, reachability analysis, and static analysis to offer highly precise, actionable intelligence, reducing noise and improving security posture.

About the Speaker(s)

Jess Lowe and Rex Pan are both Software Engineers on the Google Open Source Security team. Based in Sydney, Australia, they are actively involved in developing tools and projects related to open-source vulnerabilities, including the Open Source Vulnerability (OSV) schema and its associated services. Their work aims to enhance the accuracy and actionability of vulnerability intelligence within the open-source ecosystem.