EVIDENCE INTEGRITY · CVSS 3.1 · CAPTURE STRUCTURE · SCOPE · SECRET PATTERNS

EvidenceGate

The ledger that refuses to confirm a finding with no evidence

A security finding is only as good as the proof behind it. EvidenceGate keeps findings and evidence references in a small SQLite ledger and enforces one rule at the database level: a finding cannot be marked confirmed unless it has a hashed evidence record. A separate, deterministic gate then re-checks the whole package and prints a single READY or NOT READY verdict for the configured checks.

Source on GitHub Download the release Worked demonstration Author site

MIT licensed · Python 3.10+, standard library only · SQLite ledger · no network requests, no telemetry · 21 tests on Linux, Windows and macOS on every push · Version 1.0.0

Terminal recording: confirm is refused with no evidence, succeeds after a hashed capture is attached, then the gate prints READY

Typeset from a verified run of python examples/quickstart.py. Local paths are normalised and the gate report is condensed to one line per check. The capture is invented, not taken from a service, and no target is contacted.

How it works

EvidenceGate architecture: findings and evidence in a SQLite ledger with triggers, then five deterministic checks and a verdict

The five checks

G1Evidence integrityReferenced evidence for confirmed findings matches its recorded SHA-256 hash and resolves inside the evidence root. Path traversal and symlink escapes are rejected.
G2CVSS recomputationSupplied CVSS 3.1 base vectors are valid and the recomputed score agrees with the supplied severity. Missing vectors are never inferred.
G3HTTP capture structureA request line and a response status occur in the supporting evidence, so a "capture" that is only a narrative does not pass as proof.
G4ScopeRequest hosts match the declared hostname policy, with case and port normalised. Substring lookalikes do not match. No --in-scope means scope was not checked, and the report says so.
G5Secret patternsRaw JWTs, bearer tokens, AWS access key ids and private-key blocks are flagged before a package leaves the analyst's machine. Heuristic: cookies and personal data still need a manual review.
LEDGERTriggers, not conventionsSQLite triggers require evidence before confirmation, validate the hash format and prevent deleting or moving the final evidence row of a confirmed finding.

Assessment workflow

python evidencegate.py init assessment.db
python evidencegate.py add-finding assessment.db --id F-01 --title "Candidate IDOR" --severity MEDIUM --cvss "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N"
python evidencegate.py add-evidence assessment.db --finding F-01 --file proof/idor.txt --kind http
python evidencegate.py confirm assessment.db --id F-01
python evidencegate.py gate assessment.db --evidence-root . --in-scope example.test

# Exit codes: 0 checks passed, 1 checks failed, 2 invalid input
What READY means, and does not. READY means the configured checks passed. It does not establish vulnerability, authenticity, authorization, complete redaction or analyst approval. The confirmed status is a recorded analyst decision; the tool enforces that supporting evidence is present, not the truth of that decision. Hashes are not signatures: keep the ledger and a trusted hash reference protected separately. HTTP/2 binary captures and non-HTTP proof formats are outside the HTTP checks. Cite the tool with the repository's CITATION.cff.