FID-088 · Open question
Independent Verification of Autonomous Cyber Repairs
Which independent checks provide useful evidence that an AI-generated security repair resolves the vulnerability while preserving legitimate software behavior?
Program context
AIxCC demonstrated automated vulnerability discovery and repair and released cyber reasoning systems for further use. Fide proposes independent evaluation of repair acceptance using suitable released artifacts. The competition concluded in 2025; this is a research reference, not an open competition.
Research context; no funding, partnership, endorsement, or open solicitation is implied.
Why the question remains open
Automated repair can shorten vulnerability exposure, but accepting an ineffective fix can leave software vulnerable or introduce a functional regression. A plausible patch and a passed reproduction test provide different evidence from a broader assessment of security and preserved behavior. Maintainers need to know which additional checks change an acceptance decision enough to justify their cost and review burden.
Working hypothesis
A proposition to test, not a finding.
A verification policy that adds independently designed security and functional checks will reduce false acceptance of ineffective repairs compared with reliance on the original reproduction check at a defined verification budget. The null is that it provides no meaningful improvement, or that false rejections, invalid tests, and additional cost outweigh the benefit. Valid repair acceptance must be measured too.
Proposed method
How the question could be tested
- 01With software-security collaborators, qualify a small corpus of already-disclosed vulnerabilities and candidate repairs with reproducible builds and executable checks. Consider released AIxCC artifacts alongside other suitable corpora. Record provenance, licenses, task overlap, tool versions, and the evidence available for each repair.
- 02Reproduce the original failure and acceptance check before adding verification. Include known valid and invalid repair controls where independently established; report unreproducible cases and their exclusion criteria.
- 03Define original-test, existing validation, and independent-verification policies. Additional checks may include security variants and legitimate behavior tests reviewed by domain specialists. Set policies on development projects before held-out projects, keeping related vulnerabilities and repairs together to limit leakage.
- 04Fix candidate repairs before exposing them to held-out verification. Record any test information already available to the repair system. Blind reviewers to the producing system where practical; keep agent completion claims separate from executable evidence.
- 05Compare acceptance decisions at fixed check or compute budgets. Measure independently adjudicated ineffective repairs accepted, valid repairs rejected, unresolved failures, functional regressions, inconclusive results, and verification cost.
- 06Review disagreements to distinguish an invalid test from an invalid repair. Estimate uncertainty with project-level dependence in mind and publish sensitivity to ambiguous labels. Describe how curated cases limit any estimated false-acceptance rate.
Needed controls
What must constrain the study
- 01Execute only authorized, contained reproductions using already-disclosed cases. Isolate untrusted builds and patches, disable uncontrolled egress, and exclude real credentials, production systems, and confidential source code.
- 02Do not use the same check as both the verification method and an unquestioned ground truth. Document independent adjudication, reviewer disagreement, and residual unknowns.
- 03Require checks to preserve the intended specification. Removing useful functionality or disabling a vulnerable feature does not automatically establish an acceptable fix.
- 04Predefine timeouts and infrastructure-failure handling. Report inconclusive checks separately from repair failures and successful verification.
- 05Keep human review time separate from automated compute cost. Do not assume escalation produces a correct result without measuring the review process.
- 06Review artifacts for licenses, sensitive content, and release risks. Follow responsible disclosure if evaluation unexpectedly uncovers a previously unknown vulnerability.
Relationship to existing work
FID-075 evaluates whole-system cyber capability; this call examines the evidence for accepting a proposed repair. FID-076 covers authority to act and the consequences of response decisions. FID-077 reconstructs incidents and causes; reconstruction alone does not establish a repair's effectiveness. FID-087 concerns collective resilience rather than verification of software changes.
Expected outputs
Artifacts the work should produce
- 01An independent repair-verification protocol with explicit acceptance criteria, baselines, resource budgets, and adjudication rules.
- 02A reviewed corpus of repair outcomes, or reproducible retrieval instructions and permitted derived results where redistribution is restricted.
- 03A comparative report on false acceptance, false rejection, regressions, uncertainty, and verification cost, including negative and inconclusive results.
- 04Reusable checks and a reporting template that distinguish observed evidence from unsupported claims of complete security or recovery.
Open questions
Uncertainties the protocol must resolve
- 01Which checks add evidence beyond existing patch-validation methods at realistic cost?
- 02How independent can verification be when repair and review use similar models or data?
- 03When do narrow tests miss partial fixes, and when do broader tests reject valid repairs?
- 04What evidence supports acceptance when no complete behavioral specification exists?
- 05Which findings transfer across projects, vulnerability families, and repair systems?
Related calls
Explore related cybersecurity calls
FID-076
Authorization Boundaries and AI Control in Cybersecurity
Which controls keep capable agents within legitimate authorization when task pressure, untrusted inputs, or delegated work creates opportunities to exceed it? For autonomous cyber defense, how can response controls preserve threat containment and legitimate service availability while respecting human authority?
FID-087
Collective Resilience in Autonomous Cyber Defense
Which coordination and verification mechanisms let a team of AI defenders contain an unreliable or compromised agent while continuing to protect legitimate services?
FID-075
Cybersecurity Capabilities and Whole-System Risk
How do autonomy, tool access, resource budgets, and human assistance change an AI system's cybersecurity capabilities and the risk it creates?
Open question
Open work
Primary need: software security, maintainers, executable regression tests, independent verification
- Maintainers and vulnerability researchers to qualify cases and adjudicate outcomes.
- Automated repair and testing researchers to identify strong existing baselines.
- Evaluation engineers to reproduce builds, isolate execution, and track provenance.
- Statisticians to assess selection effects, dependence, and uncertain ground truth.