A compliance verdict is testimony until someone else can reproduce it. Contract-based execution is what turns the verdict from a vendor claim into something an assessor can re-run end to end.
A scanner hands you a number. Pass. Sometimes fail, sometimes indeterminate. That number is the verdict. The path it traveled to get there — what was collected, on which target, with which command, against which expected state — is almost always invisible.
So you trust the scanner.
That trust is the gap. It is the only thing holding the verdict up.
What a Verdict Needs to Be Proof
The verdict is one bit. Pass or fail. Proof is a record of how that bit was produced. Three pieces.
The intent: what was being checked, declared up front, not inferred after the fact.
The contract: how it was checked, expressed as the exact collection method the engine ran.
The outcome: what happened, recorded per field, with the operator that produced the verdict.
Intent is the policy. The previous article in this series put intent in a file an auditor can read — that is what policy as data means. The check is no longer code; it is a declarative file an assessor can open and follow.
This piece is about the contract.
Contract-Based Execution, Up Close
A policy says what to check. It does not say how. The how lives in the engine, under a name that travels with the verdict: the contract.
In the ESP engine, the contract is a typed object named CtnContract. It carries five things: the kind of check it implements; what the policy is allowed to say about the object being inspected; the operators and field types allowed in the STATE block; how collected fields map to comparisons; and the legal evaluation modes for this contract.
pub struct CtnContract {
pub ctn_type: CtnType,
pub object_requirements: ObjectRequirements,
pub state_requirements: StateRequirements,
pub field_mappings: FieldMappings,
pub supported_behaviors: BehaviorSet,
}Each CtnContract binds to two pieces of code: a CtnDataCollector that knows how to gather the data, and a CtnExecutor that knows how to compare it to the declared state. Both register ahead of time, in the engine’s strategy registry. A policy cannot invent a contract at runtime. The contract has to already exist, registered, on the engine that will run the scan.
That registration is also where the whitelist lives. On RHEL 9, the executor is permitted exactly four commands: rpm, systemctl, sysctl, getenforce. A policy cannot ask the engine to run anything outside that set. There is no exec("anything") escape hatch in the language. There is no late-bound shell-out. The surface is fixed at registration and frozen for the life of the engine build.
This sounds restrictive. It is the point.
A finite, enumerable list of contracts is auditable. You can read the registry. You can read the whitelist. The total surface area of things this engine could possibly do to your host is a document, not a black box. The contract is data. The collector and executor are code, but they are bound to a contract type and constrained by a whitelist, so the operational surface a policy can reach is itself a piece of data — auditable like one.
We walk a contract end to end in the companion video, Contract-Based Execution: How a Compliance Verdict Becomes a Replayable Proof.
How the Verdict Becomes Replayable
Now the verdict.
In ESP, every verdict carries a replay_hash. That hash is the cryptographic fingerprint that lets a third party check the verdict for themselves. It is built in three layers.
Layer 1 — Intent. From the validated AST of the policy file: policy identity, control mappings, the OBJECT and STATE blocks as the compiler produced them. Same policy, byte-identical layer.
Layer 2 — Contract. From the CtnContract itself, including the field mappings the engine used to interpret the data. Same contract type and version, byte-identical layer.
Layer 3 — Outcome. Per-field pass/fail, with the operator that produced the verdict. Volatile collected values — file contents, API responses, command output, timestamps, counters — are deliberately excluded. The hash captures the decision, not the data the decision was made over.
The three layers fold together through the CRI tree — the policy’s logical-criteria structure — and combine with the policy identity (id, platform, criticality, control mappings). The whole thing is hashed with SHA-256 over a canonical JSON serialization. The output is the replay hash.
The engine then signs SHA256(replay_hash) with ECDSA P-256. The signature’s covers field is always ["replay_hash"]. The chain ties the verdict to a specific scanner identity at a specific moment.
Same policy, same system state, same contract registration, same hash. Every time. That stability is the whole point.
Drift detection means the same thing here. If the hash changes between two scans, something the hash actually covers changed: intent, contract, or outcome. It did not change because a timestamp moved or a token rotated. The hash was built so it cannot.
The Reproducibility Block
Carrying a stable replay hash is necessary. It is not enough.
The envelope an assessor receives is the AssessorPackage. It carries the verdict, the replay hash, the signature — and a reproducibility block: the exact command the scanner ran, the object it ran against, and which collection method was used.
A minimal entry, verbatim from the trust model spec:
{
"object_id": "passwd_file",
"method_type": "file_stat",
"command": "stat /etc/passwd",
"target": "/etc/passwd"
}The assessor pulls the package. They run stat /etc/passwd on their own infrastructure — their workstation, their lab, their assessment environment. They feed the result back through the same ESP engine — open source, Apache 2.0, the exact code the scanner ran. They get their own replay hash.
If the hashes match, the verdict is real.
There is no shared infrastructure to compromise. No vendor service to trust. No remote attestation to wait on. The assessor reproduces the verdict end to end on their own machine, and the cryptographic chain closes around that fact.
This is what verify without trusting the scanner looks like when you actually trace it through.
What Contract-Based Execution Unlocks
A replayable verdict is the prerequisite. Here is what it makes possible.
Auditable Continuous Monitoring
Continuous monitoring is only as credible as the methodology behind every snapshot. When the contract is data — registered, enumerated, version-controlled — the methodology audit is one-time. Every cycle inherits it.
Drift detection becomes a signal you can act on, not a checksum jitter. A measurable change in something the hash actually covers: intent, contract, or outcome. Not noise from a moving timestamp. Not a flip from a rotated token. The volatile-data exclusion that keeps the hash stable is the same property that makes drift meaningful when the hash finally moves.
A Tamper-Evident Evidence Chain
The replay hash is intentionally narrow. It covers the decision and the method, not the volatile data the decision was made over. That narrowness is what makes the hash stable, and the stability is what makes tampering visible.
Change the verdict, the hash changes. Swap the contract, the hash changes. Edit the policy, the hash changes. Tamper with the envelope downstream and the ECDSA signature breaks. The chain holds end to end because there is nothing volatile inside it to drift on its own.
Independent Verification, No Vendor Trust Required
The assessor takes the AssessorPackage to their own infrastructure. They re-run the recorded commands from the reproducibility block. They re-derive the replay hash. They check the ECDSA signature against the published public key.
There is no remote-attestation service, no vendor portal, no API to depend on. The only things the verification depends on are open code and the assessor’s own machine. The verdict stands or it does not — and the verdict makes its own case.
A Chain of Custody That Holds Up Under FedRAMP 20x
FedRAMP 20x moved the assessment surface. The assessor no longer just reviews a compiled artifact package and trusts the methodology underneath. They evaluate the validation process itself: its logic, and whether its results reproduce.
Contract-based execution answers that. The process is finite — a list of registered contracts. The execution is whitelisted — a list of allowed commands. The verdict carries a cryptographic identity — the replay hash. The reproduction is a documented procedure — the reproducibility block in the envelope.
A process you can read. An execution you can constrain. A verdict you can re-derive. That is the chain of custody assessors are now being asked to require.
Intent. Contract. Outcome. The verdict is signed over all three. The contract is the part assessors most often have no way to see.
The previous article in this series put intent in a file an assessor can read. This one puts the contract in a registry an assessor can enumerate, with a hash that ties it to the verdict and a reproducibility block that lets an assessor run the same check on their own machine. The whole chain is walked end to end in the companion video above.
The engine is open source, Apache 2.0: github.com/scanset/Endpoint-State-Policy. The trust model, the contract registry, and the replay-hash construction are all in the repository — readable, reviewable, replayable.
If you are building an evidence layer for a federal program, or trying to figure out what continuous monitoring is supposed to look like when an assessor actually has to evaluate the validation process, that is a conversation worth having. Reach the ScanSet engineering team at contact@scanset.io.