ANTIBODY — Incident-to-Immunity Engine

Turn production defects into verifiable defenses. ANTIBODY proves fixes, discovers sibling vulnerabilities, validates structural rules, and checks for recurrence through GitLab CI.

Comment

Inspiration

A production bug should not simply be fixed and forgotten. The same underlying mistake can exist in multiple places, and a similar defect can return later if the original fix is not enforced through repeatable checks.

ANTIBODY was inspired by one question: What if a production incident could become a verifiable, reusable defense against recurrence?

Built on the open-source Sherlock project, ANTIBODY uses a real defect involving an outbound HTTP request without an explicit timeout in sherlock_project/sites.py as its starting point. The goal is to turn a specific incident into a structural defense that can be tested, inspected, and checked again through CI.

What it does

ANTIBODY is a supervised incident-to-immunity system that demonstrates how a known software defect can be transformed into a repeatable verification workflow.

Its five stages are:

Regression proof: Reproduce the defect and verify the correction with a red-to-green test.

Sibling discovery: Identify related call sites that may share the same risk.

Structural defense validation: Test whether a defense rule catches relevant defect patterns without matching unrelated code.

Recurrence checking: Run a recurrence gate against a held-out scenario to check whether the known defect pattern returns.

Evidence generation: Consolidate verification results into machine-readable receipts for inspection.

In the demonstrated test scenarios, ANTIBODY discovers six confirmed sibling call sites across four files, catches seven out of seven synthetic mutation cases, and rejects three negative-control rules. The recurrence gate blocks the held-out recurrence scenario, with zero reported false positives on clean code.

These results demonstrate the workflow against defined test cases; they do not claim universal vulnerability detection or prevention.

How we built it

ANTIBODY combines Python-based regression testing, structural analysis, sibling-call discovery, defense validation, and recurrence checks. GitLab CI connects these stages into a pipeline so reviewers can inspect individual job results and supporting evidence.

The project includes a web dashboard that presents the workflow and links to the GitLab repository and pipeline evidence. Rather than relying on a single success indicator, the dashboard makes the different stages and their outcomes visible.

ANTIBODY builds on the open-source Sherlock project and uses a real defect as the basis for its verification workflow. The implementation focuses on turning a known failure pattern into a testable structural rule and checking that rule against related cases and recurrence scenarios.

Challenges we ran into

One of the main challenges was distinguishing a genuinely useful structural defense from a rule that merely matches text. A rule must detect relevant variations without being so broad that it flags unrelated code or so narrow that it misses meaningful variants.

Another challenge was validating more than the original regression test. Sibling discovery, mutation testing, negative controls, recurrence checks, and clean-code checks each provide different evidence and must be evaluated separately.

We also had to make the project's limitations explicit. The displayed GitLab pipeline reports a warning because static analysis has an allowed failure associated with Ruff issues. Live GitLab Duo agent execution and automated canary rollback remain unverified, and the current structural analysis has limitations with complex inter-procedural flows.

Documenting these boundaries was an important engineering decision: a trustworthy tool should distinguish demonstrated functionality from work that remains incomplete.

Accomplishments that we're proud of

We are proud to have built a working demonstration that connects a real defect to regression proof, related-call-site discovery, structural defense validation, recurrence checking, and machine-readable evidence.

The demonstrated tests identify six confirmed sibling call sites across four files, catch all seven defined synthetic mutation cases, reject three negative-control rules, and block a held-out recurrence scenario.

We also built a live dashboard and connected the workflow to GitLab CI, making the results accessible for review. Most importantly, ANTIBODY does not hide its limitations or present unverified automation as completed functionality.

What we learned

We learned that fixing a bug is only the beginning of making software more resilient. A durable defense also requires investigating related code, testing the quality of the rule, checking for recurrence, and making the supporting evidence easy to inspect.

We also learned the importance of negative testing. Positive test cases show that a defense can work, while mutation cases and negative controls help determine whether it works for the right reasons.

Finally, we learned that transparency is part of engineering quality. Clearly identifying pipeline warnings, analysis limitations, and unverified automation makes the project's current capabilities easier to evaluate honestly.

What's next for ANTIBODY — Incident-to-Immunity Engine

The next steps are to resolve the remaining static-analysis issues, strengthen analysis across function boundaries, and verify the currently unverified automation paths.

We also want to improve the workflow's ability to handle more complex defect patterns and expand the range of cases used to validate structural defenses and recurrence checks.

The long-term goal is to make ANTIBODY a more complete incident-to-immunity workflow: one that helps developers move from a production defect to a tested defense, identify related risks, and produce evidence that can be independently inspected.

ANTIBODY turns production incidents into stronger, testable defenses—with evidence that reviewers can inspect.

Built With

  • abstract-syntax-tree-(ast)
  • automated-testing
  • automation
  • continuous-integration
  • css
  • developer-tools
  • devsecops
  • gitlab
  • gitlab-ci/cd
  • html
  • javascript
  • mutation-testing
  • open-source
  • python
  • regression-testing
  • security
  • sherlock
  • software-engineering
  • static-analysis
  • test
  • web-dashboard
Share this project:

Updates

Submission history