Not In My Git Yard: A Fuzzing-Based Defense Against Commit and Release Backdoors

A new paper, "Not In My Git Yard: Catching Backdoors at Commit and Release Time", describes Lily, an automated system for catching code-level backdoors before they land in commits or ship in releases. It's slated for ASE 2026 in Munich.

The problem

The abstract frames code-level backdoors as "stealthy code changes that grant hidden privileges via secret triggers," and notes that known attempts to inject them into widely used open-source projects — via malicious commits, tampered release packages, or compromised dependencies — were stopped by luck and manual review, not tooling. As the paper puts it: "Existing Continuous Integration (CI) pipelines cannot detect these attacks, and downstream binary analysis tools require substantial manual effort."

Lily is pitched as the fix: an "automated approach that strengthens open-source development and release processes against backdoor injection," integrated at two points:

1. CI pipelines, to block malicious commits as they're proposed.
2. Release vetting workflows, to catch tampered releases or compromised dependencies before they enter large ecosystems — the paper cites Linux distributions as an example of scale.

What Lily does, per the abstract

Two contributions are listed. First, Lily "enhances CI-compatible fuzzing with the capability to detect triggers of suspicious behavior based on historical and current software executions" — built to run within normal CI time/resource constraints rather than as an offline audit step.

Second, Lily "combines code change analysis with fuzzing data to precisely point maintainers to backdoor-revealing code regions, even when release updates modify millions of lines of code." That targets the triage problem: flagging that a release is suspicious is one thing; pointing at the actual responsible lines in a multi-million-line diff is harder, and the paper claims to address it by fusing code-change analysis with the fuzzing signal.

Evasion is part of the evaluation

The authors don't just test Lily against known backdoors — the abstract states they "outline five strategies attackers could use to evade Lily, and evaluate corresponding defenses." The abstract doesn't specify what those five strategies are or how the defenses work; that's in the full paper. But it signals evasion was treated as a first-class part of the threat model, not an afterthought.

What the evaluation claims — and doesn't

The abstract says testing covered "hundreds of benign and backdoored commits and releases," and that Lily "achieves high detection accuracy with low false alarm rates, reliably identifies malicious code, resists adversarial attempts, and would have prevented real-world backdoor incidents."

Notably absent: any specific accuracy percentage, false-positive rate, or named list of real-world incidents. Those numbers, if they exist, are in the full paper, not the abstract.

Where to find it

The preprint is at arxiv.org/abs/2607.26719, with the PDF and HTML (experimental) versions. It's cross-listed under Cryptography and Security (cs.CR) and Software Engineering (cs.SE), with a DOI at https://doi.org/10.48550/arXiv.2607.26719.

Canonical citation:

arXiv:2607.26719 [cs.CR]
(or arXiv:2607.26719v1 [cs.CR] for this version)

Submitting author: Stefano Zacchiroli (via CCSD proxy). v1 submitted Wed, 29 Jul 2026. The paper is set to appear at ASE 2026 in Munich, October 2026.

What's still open

The abstract gives the shape of the problem, the shape of the fix, and a summary verdict on the evaluation — but no underlying numbers, no list of evaluated projects, no specifics on the five evasion strategies, and no implementation details (language/toolchain support, deployment into existing CI). Those require the full paper.