Strict vulnerability programs reject, and sometimes ban, reports that
miss their published criteria: wrong class, PoC not written from a
remote attacker's perspective, no measured impact, same-type findings
split across reports, untested claims presented as verified. Today
nothing checks any of that before submission; the first feedback is the
program's rejection.
scripts/submission_review adds the validation side of the loop:
- review.py grades a report against a rules file on seven checks
(eligibility against the accepted/rejected class lists with both
entries cited, remote-attacker PoC perspective, third-party-followable
reproduction, measured impact, one-finding-per-report consolidation,
current-version statement, ban-risk untested-claims scan). Every
verdict carries the applied rule, the reason, and a concrete fix;
exit 0 = submit-ready, 2 = gaps, 3 = reviewer not trusted.
- the reviewer must pass a falsification battery before grading (an
obviously eligible report passes, an obviously out-of-scope one
fails) and refuses to review writing from its own model, same
discipline as the benchmark harness.
- rules/strict-vdp.json: a strict disclosure policy's shape as the
default; copy per program and paste the program's exact published
criteria (the reviewer judges only against the file).
Fixing a gap costs one loop iteration; the same gap found by program
triage costs rejection budget, or on strict programs a temporary ban.
