Did You Forkget It? Detecting One-Day Vulnerabilities in Open-source ForksWith Global History Analysis

arXiv:2511.05097 · cs.CR, cs.SE · Submitted 2025-11-07 · Read on arXiv

Listen

Transcript

Introduction to the show: ident: Security Radio. Generated commentary on the latest security and cryptography papers.

Nadia: I'm Nadia, and with me are Elias and Priya, guest researcher.

Elias: Today's paper: "Did You Forkget It? Detecting One-Day Vulnerabilities in Open-source ForksWith Global History Analysis".

Nadia: A global history analysis approach leverages a comprehensive graph of public code to identify one-day vulnerabilities in forked repositories,

Elias: First, who's behind it and why it matters.

Title and authors: Nadia: The title "Did You Forkget It? Detecting One-Day Vulnerabilities in Open-source ForksWith Global History Analysis" perfectly captures the essence of finding those known but unpatched issues in downstream code.

Elias: I think it points directly to the gap they’re filling by tracking vulnerabilities inherited from third-party open-source software, which is a well-known challenge, often addressed by tracing dependency information sixteen twenty-seven <ref:2511.05097#pg0,tracking vulnerabilities inherited from third-party open-source software>.

Priya: From a measurement standpoint, the paper claims an implementation that can scale to the complete Software Heritage commit graph consisting of more than five billion unique commits, so we need to see how those massive datasets are practically utilized.

Nadia: That's what I want to know; if you have that much data, how does the system efficiently pinpoint which specific forks are potentially impacted by a vulnerability introduced earlier?

Elias: The paper describes an implementation that scales to this large graph, enabling commit-level vulnerability tracking across heterogeneous public forges and version control systems.

Priya: When they talk about propagation, they mention showing that starting from seven thousand one hundred sixty-two repositories referenced by the OSV database as having been affected by vulnerabilities in the past, vulnerabilities propagate to two point two million potentially impacted forks <ref:2511.05097#pg0>.

Nadia: That number is significant; it shows a substantial reach when you start tracing those connections through the fork ecosystem.

Elias: And they also report identifying real, high-impact one-day vulnerabilities in independent forks after filtering based on significant use and severity, confirming one hundred thirty-five cases with a precision of zero point six nine <ref:2511.05097#pg2>.

Priya: That precision figure is interesting; it tells us the statistical reliability of this global history analysis approach when it comes to flagging true risks for downstream users.

Nadia: It gives us a concrete metric, Priya, which is much better than just saying it's effective; we can see how accurate these initial findings are before they even get to the maintainers.

Elias: The authors also obtained further positive confirmation from maintainers for nine high-severity one-day vulnerabilities <ref:2511.05097#pg2>, which adds a layer of real-world validation to their findings.

Priya: So, in short, this paper is presenting a method that leverages the global graph to find specific forks with known but unpatched vulnerabilities by tracking fixes and introductions across the entire ecosystem <ref:2511.05097#pg0>.

Nadia: It’s about moving from reactive scanning to proactive historical analysis for fork maintainers and users, which is a key area of focus for security research right now.

Elias: This whole approach is really about providing a mechanism that helps developers identify vulnerabilities that their local scans simply miss because they are inherited through the fork structure.

The paper's summary: Nadia: Essentially, the core idea is taking a deduplicated Merkle directed acyclic graph structure, like Software Heritage’s model, which links public code commits together into one massive history.

Elias: That global commit graph acts as the foundation; they then apply OSV semantics globally to "label" each commit with records containing introduction, fix, limit, and last affected commits <ref:2511.05097#pg2>.

Priya: This labeling process means that every single commit in that five billion-plus graph gets tagged not just for what it does now, but for the entire history of vulnerabilities associated with it.

Nadia: That’s exactly right; it formalizes the idea of vulnerability propagation by tracking how fixes from an upstream repository are incorporated into downstream forks.

Elias: The summary highlights a global model where vulnerability ranges are defined as records containing introduction, fix, limit, and last affected commits <ref:2511.05097#pg2>.

Priya: So the paper is summarizing that by applying this global framework to the commit graph, they can effectively track vulnerable and fixing commits across the entire fork ecosystem <ref:2511.05097#pg0>.

Nadia: It boils down to a powerful system where maintainers and users of forks get an automated way to see if their specific branch is affected by something that was introduced long ago upstream.

Elias: The summary emphasizes the implementation's ability to scale to this massive commit graph, which is what makes it feasible for tracking across heterogeneous version control systems <ref:2511.05097#pg2>.

Priya: I think the most important part of the summary is that they aren't just looking at current versions; they are looking at the entire lineage to find those one-day issues <ref:2511.05097#pg0>.

Nadia: That’s because those one-day vulnerabilities, where a fix exists but isn't integrated into the fork yet, are exactly what this global history analysis is designed to catch.

Elias: So, in simple terms, it's a system that maps the entire history of code changes and overlays vulnerability data onto that map to flag potential issues in forks <ref:2511.05097#pg0>.

The paper's improvements: Nadia: The paper suggests several integration scenarios, including assisting fork maintainers in recognizing vulnerabilities reported elsewhere and providing downstream users with knowledge to derisk their software <ref:2511.05097#pg2>.

Elias: They also propose integrating this approach into traditional dependency-based audits to warn users about dependencies that are themselves forks, which is a practical application for supply chain auditing <ref:2511.05097#pg2>.

Priya: The paper introduces a public lookup website as a tool intended to expose vulnerability labels prior to filtering, which sounds like it could be very useful for independent security researchers <ref:2511.05097#pg3>.

Nadia: I think the authors are pushing for democratization of this information, making these deep history analyses accessible through tools rather than just being buried in complex research papers.

Elias: They also suggest future work involving using vulnerability detection techniques from literature, like deep learning models, to enhance the detection of equivalent commits in the global commit graph <ref:2511.05097#pg3>.

Priya: That’s an interesting direction; integrating deep learning could help automate the detection of similar vulnerable commits across different codebases more intelligently than current methods.

Nadia: And they also propose a database mapping individual commits to OSV ranges and derived mappings from fork URLs, which would make it much easier for independent security researchers to access this information <ref:2511.05097#pg3>.

Elias: That mapping would really democratize access by creating an indexed source of truth linking specific code history to known vulnerability data, which is a huge step forward in tooling <ref:2511.05097#pg3>.

Conclusion: Nadia: The analysis successfully tracked introduction and fixes across two point two million forks on three hundred twelve forges, confirming that global history analysis is effective in supporting the identification of downstream forks affected by one-day vulnerabilities <ref:2511.05097#pg0>.

Elias: Yes, the study confirmed that this method can identify downstream forks affected by one-day vulnerabilities, as exemplified by cases like PANDA and Xperia <ref:2511.05097#pg2>.

Priya: It seems the main implication is that we need automated tooling to notify maintainers and users of potential one-day vulnerabilities at a global scale, which is what this paper advocates for.

Nadia: It really underscores the need for automated tools that can help fork maintainers recognize relevant vulnerabilities and derisk software use for fork users <ref:2511.05097#pg2>.

Elias: Overall, this work confirms that global history analysis is a viable way to support the identification of downstream forks affected by one-day vulnerabilities <ref:2511.05097#pg2>.

Priya: To weigh in one last time, I think the real value here is moving toward an automated system that can handle this scale and provide actionable intelligence for those who manage these complex software lineages <ref:2511.05097#pg3>.

Nadia: It’s a massive step toward making the open-source supply chain more resilient by catching these inherited security issues before they cause problems <ref:2511.05097#pg3>.

Elias: We've seen a solid study that shows how tracking fixes and introductions across the entire ecosystem helps in understanding propagation, which is valuable for cryptographers too <ref:2511.05097#pg2>.

Priya: It’s exciting to see how historical context can be leveraged so effectively to build better security practices for software development worldwide <ref:2511.05097#pg3>.

University of Rennes · LTCI, Télécom Paris, Institut Polytechnique de Paris · inria

cs.CR, cs.SE

Submitted: 2025-11-07

Updated: 2026-10-07

Journal ref: Scored 2026 - Conference on Software Supply Chain Offensive Research and Ecosystem Defenses, Oct 2026, Pragues, Czech Republic

Code: https://github.com/Panda-re/Panda

Project page: https://ossf.github.io/osv-schema

License: http://arxiv.org/licenses/nonexclusive-distrib/1.0/

Importance score: 83/100

The gist: A global history analysis approach leverages a comprehensive graph of public code to identify one-day vulnerabilities in forked repositories, addressing a critical gap where existing tools fail to

Key concepts

Global History Analysis Approach: This method uses a massive graph of public code commits to track how vulnerabilities are introduced and fixed across different repositories. It labels each commit with vulnerability information, allowing researchers to map security issues across the entire ecosystem of forks.
Cross-Fork Vulnerability Propagation: This refers to the risk where a vulnerability in one piece of code affects many downstream forks because they share common history from an original upstream repository. The approach tracks these shared histories to identify these inherited, unpatched bugs.
OSV Semantics Formalization: This involves creating a standardized way to record vulnerability information—specifically introduction, fix, limit, and last affected commits—and applying this standard globally across the commit graph. This formal structure allows the system to accurately track when and where vulnerabilities occurred in the code.
One-Day Vulnerability: This is a critical security issue where a known vulnerability exists in software that has been forked, but the necessary fix from the original upstream repository has not yet been integrated into that specific fork. The analysis aims to find these 'known but unpatched' flaws.

Terminology

Elias — 17× in this paper · explained in 2 episodes
Nadia — 16× in this paper · explained in 2 episodes
Mining Software Repositories — 8× in this paper
Version Control System — 8× in this paper
Open-Source Software — 7× in this paper
Trace — 4× in this paper · explained in 2 episodes
Core — 3× in this paper · explained in 2 episodes
Actor — 2× in this paper · explained in 3 episodes
Adam — 2× in this paper · explained in 2 episodes
Formal Methods — 2× in this paper · explained in 3 episodes
IEEE Symposium on Security and Privacy — 2× in this paper
Consistency — 1× in this paper · explained in 3 episodes
Convolutional Neural Networks (CNNs) — 1× in this paper · explained in 2 episodes
Data Augmentation — 1× in this paper · explained in 7 episodes
GNNs — 1× in this paper · explained in 2 episodes
Graph Neural Networks (GNNs) — 1× in this paper · explained in 7 episodes
Open Source Vulnerabilities — 1× in this paper
Redundancy — 1× in this paper · explained in 2 episodes
Representation Learning — 1× in this paper · explained in 2 episodes

Summary

A global history analysis approach leverages a comprehensive graph of public code to identify one-day vulnerabilities in forked repositories, addressing a critical gap where existing tools fail to track inherited security issues across diverse fork ecosystems. This method is significant because it enables developers and users to proactively detect known but unpatched vulnerabilities in downstream software that may have been introduced by upstream code before a fix was integrated into the fork.

The gist

Our global history analysis approach enables maintainers and users of forks to identify one-day vulnerabilities affecting a given fork by tracking vulnerable and fixing commits across its entire fork ecosystem.

Problem Statement and Motivation

The paper addresses the underexplored topic of “cross-fork” vulnerability propagation in the open-source ecosystem, where forks share parts of a common code history. A vulnerability identified in one fork is likely to affect others depending on when forking happened and how changes in the initial (”upstream”) code repository are incorporated into (”downstream”) forks. This can result in a so-called one-day vulnerability: a known, but unpatched vulnerability. The challenge lies in the lack of approaches and tools to track cross-fork vulnerability propagation, leaving fork maintainers to manually track vulnerabilities associated with their fork ecosystem and assess if corresponding fixes have been integrated.

Global History Analysis Approach

The proposed approach is based on a global model of commits, such as the one materialized by Software Heritage (SWH), which is a deduplicated Merkle directed acyclic graph (DAG) structure linking public code commits across unrelated development platforms. The core idea is to label each commit in the global commit graph with the set of known vulnerabilities affecting it by propagating commit-level information about which commits introduced and fixed vulnerabilities from upstream repositories to downstream forks. This involves a formalization of OSV semantics applied globally, where vulnerability ranges are defined as records containing introduction, fix, limit, and last affected commits.

Experimental Protocol and Results

The experimental protocol involved three steps: (1) Data Collection using a recent export of the global commit graph from Software Heritage and vulnerability information exported from OSV; (2) Data Preparation involving cleaning and augmentation of the OSV dataset, including handling special cases like "0" as an introduction event or detecting cherry-picked events via commit messages; and (3) Commit Labeling, applying the propagation algorithm to the SWH commit graph. The results showed that starting from 7162 repositories referenced by OSV, the approach could identify 2.2 million forks containing at least one presumed vulnerable commit. Furthermore, after filtering for significant use (based on GitHub stars) and severity (CVSS scores), the study confirmed 135 cases of vulnerabilities with a precision of 0.69, with 9 high-severity one-day vulnerabilities confirmed by maintainers.

Vetting and Integration Scenarios

To assess practical usefulness, a multi-stage experimental protocol was used for RQ2, focusing on identifying forks with unpatched heads (the most recent commit remaining vulnerable) and applying filters such as popularity filtering (e.g., GitHub stars > 100), severity filtering (CVSS > 7), stale filtering, and divergence filtering. The final vetting involved manual code audit to check for false positives and contacting project maintainers for confirmation, which served as the ground truth. The findings concluded that global history analysis is effective in supporting the identification of downstream forks affected by one-day vulnerabilities, with 9 confirmed one-day vulnerabilities identified among the evaluated set. This knowledge can be integrated into development workflows to assist fork maintainers in recognizing relevant vulnerabilities and to derisk software use for fork users.

Tooling and Future Directions

The paper outlines several integration scenarios, including assisting fork maintainers in recognizing vulnerabilities reported elsewhere, providing downstream users with knowledge to derisk their software, and integrating the approach into traditional dependency-based audits to warn users about dependencies that are themselves forks. A public lookup website is proposed as a tool to expose vulnerability labels prior to filtering. Future work suggests exploring the use of vulnerability detection techniques from literature (like deep learning models) to enhance the detection of equivalent commits that introduce or fix vulnerabilities in the global commit graph. Additionally, a database mapping individual commits to OSV ranges and derived mappings from fork URLs are proposed to democratize access to this information for independent security researchers.

Conclusion

The analysis successfully tracked introduction and fixes across 2.2 million forks on 312 forges, confirming that global history analysis is effective in supporting the identification of downstream forks affected by one-day vulnerabilities, as exemplified by the PANDA and Xperia cases. The work underscores the need for automated tooling to notify maintainers and users of potential one-day vulnerabilities in relevant code repositories at a global scale.

References

[1] Mahmoud Alfadel, Diego Elias Costa, Emad Shihab, and Mouafak Mkhallalati. 2021.

Improvements for AI systems

Based on the provided scientific paper, here are specific improvements that can be made to AI systems, categorized by the capabilities they would gain:

) 1. Enhanced Vulnerability Propagation Tracking (Global Context Awareness)

The core contribution is a scalable method for tracking vulnerabilities across forked repositories using the Software Heritage (SWH) graph.

A system utilizing this approach can move beyond local dependency scanning to perform cross-fork vulnerability impact analysis.
It can identify that a vulnerability introduced in an upstream commit remains an unpatched one-day vulnerability in numerous downstream forks, even if those forks have diverged significantly from the original code.
The improved AI system can automatically flag specific fork versions (identified by their head commit) as potentially vulnerable based on the global history of their ancestors, rather than relying solely on local repository scans or static dependency checks.

) 2. Automated Risk Assessment for Downstream Users (Fork Maintainers & End Users)

The paper provides tools and database mapping for active users to proactively manage risk.

An AI-driven platform can provide real-time dashboards showing which of a developer's forks are affected by known, unpatched upstream vulnerabilities, allowing maintainers to prioritize patching efforts.
For end users, the system can act as a security advisor, warning them if the specific commit they are using in a dependency (especially in Git submodules or Go dependencies) is part of a history chain that contains an unpatched vulnerability.

) 3. High-Precision Risk Filtering and Triage (Noise Reduction)

The experimental protocol demonstrates sophisticated filtering stages to move from billions of potential matches to a manageable set of high-impact, real-world risks.

An AI system can implement the exact filtering heuristics described (Popularity filtering based on GitHub stars/forks, Severity filtering by CVSS score > 7, Stale filtering based on commit dates > 2023-01-01).
This capability allows security teams to focus only on forks with significant user bases and high-severity vulnerabilities, drastically reducing the manual auditing load.

) 4. Automated False Positive Reduction (Semantic Patch Verification)

The methodology includes a rigorous Vetting of one-day vulnerable forks phase involving manual code audit and patch verification (comparing diff hunks against the fork's codebase).

An AI system can be trained on this validation logic to automate the detection of false positives. It could automatically check if an equivalent patch has been applied in a fork by analyzing commit diffs, thereby increasing the precision of vulnerability alerts to 0.69 (as demonstrated).
This reduces alert fatigue for developers and security teams by ensuring that only truly vulnerable forks are flagged for manual intervention or notification.

) 5. Proactive Security Policy Generation (Supply Chain Auditing)

The ability to map commits to OSV ranges allows for a holistic view of the entire supply chain history.

An AI system can integrate this global mapping into Software Bill of Materials (SBOM) generation tools, not just for current dependencies but also for the entire lineage of forks.
This enables automated compliance checks that warn users if a dependency is not only vulnerable but also inherits a known vulnerability from an upstream fork.