A reviewer receives a JSON evidence file and its SHA256 hash.
The sender says the file came from a production system. The reviewer calculates the hash again, and it matches.
Can we now say the evidence is authentic?
Not yet.
The file and its hash may have come from the same sender. Someone could have modified the original content, generated a new hash, and delivered both together. The hash would still match.
The calculation is correct. But we have not established where the evidence originally came from.
What a matching hash actually proves
A SHA256 comparison answers a specific question:
computed_hash(received_bytes)
==
reference_hashIf they match, the received bytes correspond to the reference hash used in that comparison.
But where did the reference hash come from?
If it was independently captured and protected during collection, that gives us a stronger basis for detecting later changes.
If it was supplied alongside the file by the same unverified sender, the comparison cannot establish that the file is unchanged from the original collection.
This is a different problem from the one SHA256 was designed to solve.
And it becomes more interesting when we look at the evidence metadata.
A collector name is still a claim
An evidence object may already contain:
collector:
name: ansible-readonly-collector
version: 0.1.0
source:
system: production-server-01These fields are useful. They tell us which collector and source the evidence claims to represent.
But they do not independently authenticate that collector.
A field containing production-server-01 does not prove that the bytes came from that server. Similarly, a collector version does not prove which executable actually ran.
This is why collector provenance and evidence authenticity need to remain separate.
Collector metadata helps us reconstruct the claimed production path. Authenticity requires additional assurance that the claimed producer is genuinely bound to the evidence.
Even an authenticated producer does not automatically prove that the source was authoritative or that the collected facts were correct.
A recorded handoff is not a verified custody chain
Now suppose the evidence pipeline also records a handoff:
custody_event:
from: collector
to: evidence_repository
subject_sha256: ...
received_at_utc: ...This is useful information. It makes the claimed transfer visible.
But who recorded the event? Were the two parties authenticated? Was the evidence digest checked against an independently protected reference? And what happened before and after this handoff?
A JSON record containing those fields does not answer these questions by itself.
The term chain of custody is used in digital evidence handling to describe tracking evidence through collection, handling, and transfer. That includes recording who handled the evidence, when, and for what purpose.
For an automated evidence pipeline, the engineering lesson is narrower: we need to distinguish a recorded custody event from an authenticated and complete custody history.
One recorded handoff does not establish the entire chain.
Two synthetic scenarios
The latest CodeYourCompliance artifact models this distinction using two scenarios involving the same synthetic evidence subject.
The first scenario contains a modeled digest correspondence and claimed collector metadata, but no handoff event.
modeled_digest_match = true
integrity_verification = not_executed
origin_authentication = not_established
handoff_count = 0The second scenario uses the same evidence subject but adds one recorded handoff.
modeled_digest_match = true
integrity_verification = not_executed
origin_authentication = not_established
handoff_count = 1
custody_chain = not_assessedThe second record contains more information than the first.
But it still does not establish authenticated origin or a verified custody chain.
There is another important limitation: these are synthetic models. No real hash verification, transfer, signature verification, or policy evaluation was executed. Even the digest is explicitly marked as a placeholder.
The examples are intended to expose the distinction, not demonstrate a finished custody-verification system.
Where authenticity belongs in the evidence pipeline
Previous CodeYourCompliance work has separated collector provenance, transformation provenance, policy evaluation, observation outcomes, and time provenance.
Custody and authenticity add another boundary.
Before an evidence object is accepted for policy evaluation, we may need to know not only whether its bytes match a digest, but also what assurance exists for its claimed origin and handling history.
That does not mean every evidence package must immediately use digital signatures or an immutable evidence store.
It means the pipeline should preserve what it actually knows.
If the reference digest is self-supplied, record that.
If a handoff is only asserted, record it as an asserted handoff.
If origin authentication was never performed, keep that state as not_established.
Otherwise a series of unverified metadata fields can gradually become a report that describes the evidence as fully authenticated.
The report looks stronger. The underlying evidence has not changed.
MAS TRM-inspired means engineering interpretation
This is not a claim that the MAS Technology Risk Management Guidelines prescribe this custody schema, cryptographic signature mechanism, or particular evidence architecture.
The engineering interpretation is limited to preserving integrity, origin, and custody distinctions before making stronger technical control claims.
A matching hash does not authenticate the evidence producer.
A handoff record does not establish a verified chain of custody.
Those claims require their own evidence.
Public reference artifacts
The accompanying technical material is available in the CodeYourCompliance evidence-validation-pipeline repository:
Origin and scope
CodeYourCompliance
Website: Compliance Evidence Automation | CodeYourCompliance
GitHub: https://github.com/codeyourcompliance
CodeYourCompliance explores compliance automation, replayable audit evidence, read-only evidence collection, policy-as-code, and evidence packages.
Attribution is requested for forks, references, adaptations, and technical discussions.
MAS TRM-inspired means engineering interpretation. This project does not provide legal, regulatory, audit, certification, or compliance advice.