Every time a serious software vulnerability is discovered, it gets a public entry in a database (a CVE) that describes what went wrong, which piece of code was affected, and — crucially — the exact patch that fixed it. Over the years, we've accumulated hundreds of thousands of these records. They're a goldmine of information about how software breaks. The problem? They're written for humans to read, not for machines to act on.

Here's the frustrating consequence: the same kind of buggy pattern that got fixed in one project probably exists, undiscovered, in dozens of other codebases. But nobody's systematically hunting for it, because turning "here's the diff that fixed CVE-2019-XXXX" into "here's a detector that finds this bug everywhere else" is genuinely hard work.

This paper proposes a clever inversion of the usual approach. Instead of trying to teach a static analyzer abstract rules about what "unsafe code" looks like, the authors treat the patch history itself as the detector. The idea, roughly:

• Take a known CVE and its fixing commit.
• Extract what the unsafe condition looked like before the fix — the actual code shape, control flow, and data flow that made the bug possible.
• Turn that into an executable check you can run against any target codebase to see if the same unsafe pattern is lurking there.

The "end-to-end" part matters: rather than requiring a security engineer to hand-craft a rule from each CVE, the pipeline goes from raw advisory + patch → runnable detector automatically. That's the shift. It treats the vast archive of past fixes as a self-updating library of vulnerability signatures.

Why is this a big deal? Two reasons. First, known bug classes recur constantly — the same off-by-one, the same missing bounds check, the same forgotten sanitization — because developers keep writing similar code and copying patterns across projects. If a fix taught the community something, that lesson should transfer. Second, current vulnerability scanners lean heavily on either version-matching (does your dependency list contain a known-vulnerable version?) or generic rules that produce mountains of false positives. Neither catches the "same bug, different codebase, no advisory" case that this work targets.

The core insight is philosophical as much as technical: the historical record of how software gets fixed is more precise than any abstract rule we could write about what "safe code" looks like. Real patches encode real developer understanding of real bugs. Executing that history — literally replaying it against new code — turns a passive archive into an active defense.