All posts
SecuritycompliancesecuritySOC 2evidence

Tamper-Evident Compliance: How We Built SHA-256 Evidence Chains for Test Execution

For regulated industries, 'trust us, the tests passed' isn't enough. QuantumVerifi provides cryptographic proof that every test execution is authentic and unmodified.

QuantumVerifi Team18 March 20263 min read

When a healthcare company deploys a patient portal, or a bank ships a new transaction flow, regulators don't accept "the tests passed" as evidence. They need proof: what was tested, when, by whom, and whether anyone has tampered with the results since.

QuantumVerifi's compliance evidence chains provide exactly that — cryptographic proof of test execution integrity that meets SOC 2, ISO 27001, and healthcare audit requirements.

The Problem#

Traditional test results are stored in a database. Databases can be edited. Timestamps can be modified. Test results can be deleted and re-inserted. There's no way for an auditor to verify that the test execution record they're looking at is the same one that was created at runtime.

Our Solution: Hash-Linked Evidence Chains#

Every event in a test execution is hashed and linked to the previous event, forming an immutable chain:

Code
1Event 1: Test case registered 2 hash: SHA-256(canonical_json(event_1)) 3 prev_hash: "" (genesis event) 4 5Event 2: Test run started 6 hash: SHA-256(canonical_json(event_2)) 7 prev_hash: hash_of_event_1 8 9Event 3: Test item passed 10 hash: SHA-256(canonical_json(event_3)) 11 prev_hash: hash_of_event_2 12 13Event 4: Artifact linked (screenshot) 14 hash: SHA-256(canonical_json(event_4)) 15 prev_hash: hash_of_event_3

If anyone modifies event 2 after the fact, its hash changes. That breaks the link to event 3 (which stores event 2's original hash as its prev_hash). The chain verification algorithm detects this immediately.

Canonical JSON#

Hash consistency requires deterministic serialisation. The same data must produce the same hash every time, regardless of key ordering or whitespace. Our canonical JSON rules:

  • Keys sorted alphabetically
  • No whitespace between tokens
  • Null values omitted
  • Consistent number formatting (no trailing zeros)

This means {"b": 1, "a": 2} and {"a": 2, "b": 1} produce the same hash.

What Gets Recorded#

Every analysis produces a complete evidence chain:

Event TypeWhat's Recorded
test_case_registeredTest name, content hash, language, framework
test_run_startedRun ID, environment, sandbox provider
test_item_completedPass/fail, duration, error output (if any)
artifact_linkedScreenshot URL, S3 key, content hash
test_run_completedAggregate results, overall verdict

Chain Verification#

The API endpoint GET /api/v1/analyses/:id/compliance/evidence-chain returns the full chain with a verification result:

JSON
1{ 2 "chain_valid": true, 3 "events_count": 47, 4 "first_event": "2026-03-18T14:22:01Z", 5 "last_event": "2026-03-18T14:28:33Z", 6 "broken_links": [], 7 "events": [...] 8}

If broken_links is non-empty, at least one event has been modified after creation.

Five Report Types#

The compliance system generates five report types, each serving a different audit need:

  1. Test Execution — Test results with pass/fail breakdown and timing
  2. Coverage — Code and requirement coverage metrics
  3. Security — Vulnerability findings with severity and remediation
  4. Evidence Chain — Full hash chain with verification status
  5. End of Test — Comprehensive audit report combining all of the above

Reports are available in JSON, HTML, and PDF formats.

Database Design#

Seven tables enforce the compliance model:

  • compliance_test_cases — Test registry with content hashes
  • compliance_test_runs — Execution records with attestation hashes
  • compliance_test_run_items — Individual test results
  • compliance_artifact_links — Links to S3-stored evidence (screenshots, logs)
  • compliance_evidence_chain_events — The immutable event log
  • compliance_reports — Generated report records
  • compliance_audits — Change audit trail

All tables enforce tenant isolation via PostgreSQL Row-Level Security.

Who Needs This#

  • Healthcare — HIPAA requires audit trails for systems handling patient data
  • Finance — SOC 2 Type II requires evidence of testing controls
  • Government — FedRAMP and similar frameworks require tamper-evident records
  • Any regulated industry — ISO 27001 Annex A.14 covers secure development practices

The Bottom Line#

Evidence chains turn "we tested it" into "here's cryptographic proof we tested it, and nobody has modified the results."

For teams in regulated industries, this is the difference between passing an audit and failing one. For everyone else, it's a level of quality assurance transparency that builds trust with customers, partners, and stakeholders.