mirror of
https://github.com/BaaRai/ARTEX.git
synced 2026-11-15 04:30:55 +08:00
BaaRai
7644ae2a2f
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.
40 lines
2.0 KiB
JSON
Executable File
40 lines
2.0 KiB
JSON
Executable File
{
|
|
"name": "strict-vdp",
|
|
"version": "v1",
|
|
"description": "Default rule set mirroring a strict vulnerability-disclosure policy (rewrite it to your program's exact published text; the reviewer only judges against what is written here).",
|
|
"accepted_classes": [
|
|
"SQL injection",
|
|
"arbitrary file upload / deletion / download with full path and extension control",
|
|
"remote code execution",
|
|
"PHP object injection",
|
|
"significant settings change (impactful application options)",
|
|
"privilege escalation to contributor level or above",
|
|
"broken access control on genuinely sensitive objects only (API keys, secrets, password hashes, backup or SQL files)",
|
|
"IDOR with significant impact (personal-data leakage alone is NOT significant)",
|
|
"stored XSS that executes on page open with zero interaction, unauthenticated or low-privilege reachable",
|
|
"CSRF only when it chains into one of the accepted write actions above",
|
|
"denial of service only when the whole site crashes"
|
|
],
|
|
"rejected_classes": [
|
|
"user or account enumeration and other low-impact information disclosure",
|
|
"personal-data-limited broken access control or IDOR",
|
|
"CSRF that does not chain into an accepted write action",
|
|
"role prerequisites at or below contributor level",
|
|
"blind SSRF",
|
|
"CSV injection",
|
|
"open redirects",
|
|
"self-XSS or XSS requiring unusual interaction"
|
|
],
|
|
"format_requirements": {
|
|
"language": "English",
|
|
"version": "the latest released version of the component at the time of writing",
|
|
"poc_perspective": "remote attacker over HTTP; steps a third party can follow end to end; the full PoC lives in the report body, not only in attachments",
|
|
"consolidation": "multiple findings of the same type go into ONE report",
|
|
"impact": "quantified with its denominator or a concrete demonstrated attacker outcome"
|
|
},
|
|
"risk_notes": [
|
|
"an untested or assumption-based report can earn an immediate temporary ban",
|
|
"a high rejection rate can remove the reporter from the program"
|
|
]
|
|
}
|