Engineering status · reviewed 12 August 2026
Runtime attestation: design and current status
OpenFactory is designing a dual-source check that compares the state requested through systemd with the state exposed by the Linux kernel. That signed, TPM-bound workflow is not generally available today. This page records the boundary clearly.
Capability status
| Capability | Status | How to verify |
|---|---|---|
| Build artifact hashes and hash-bound CycloneDX records | Available | Inspect the downloadable build evidence for the specific artifact. Availability can vary by build path. |
| Fleet drift-report ingestion and Integrity Center timeline | Available | Confirm that the target VM is enrolled and that fresh reports appear in the console before relying on them. |
| Signed dual-source kernel and systemd comparison reports | In development | No production-availability claim is made on this page. |
| dm-verity boot enforcement and TPM-bound report signing | In development | These are design goals, not generally available controls. |
What the proposed design is meant to test
A service manager records the configuration it attempted to apply. The kernel exposes the live state that applications are actually running under. Comparing those independent views can identify mismatches that a single observation source could miss.
Candidate comparisons include cgroup resource limits, process capabilities, namespace and mount state, mandatory-access-control mode, and listening sockets. A mismatch is a finding to investigate; it is not by itself proof of compromise.
Important limits
- Runtime observations do not replace vulnerability management, endpoint detection, logs, backups, or incident response.
- A report is useful only when its collector, signing key, transport, freshness, and expected state are independently trustworthy.
- Measured boot and dm-verity address different questions from live process and policy state. One does not imply the other.
- A product feature cannot certify a deployment against GxP, DORA, defense, or another regime on its own.
Evidence required before release
- A documented threat model and protocol, including trust roots, freshness, replay resistance, key rotation, and failure modes.
- Automated tests that cause deliberate configuration and kernel mismatches and confirm that the system reports them.
- End-to-end verification on supported kernels, init systems, architectures, and deployment paths.
- Independent security review and accountable human approval for any compliance-facing language.
Related material
The engineering article explains the proposed model and its validation plan. Product documentation should remain the source of truth for released capabilities.