Runtime Attestation on OpenFactory

Most Linux fleets monitor themselves the way a student grades their own homework: ask systemd whether the policy is in force, record what systemd says, move on. That works until it doesn't. systemd is a userspace orchestrator. It configures the kernel; it does not verify that the kernel actually enforced the configuration. A kernel bug, a race condition, or a deliberate rootkit can make the kernel's real state diverge from what systemd believes it set — and that divergence is invisible to single-source monitoring.

Runtime attestation on OpenFactory closes that gap. An agent running inside each deployed VM independently queries both systemd and the kernel for the same security-relevant state, then writes a paired report. Matches are evidence; mismatches are findings. Every report is signed with a key sealed to the same TPM PCR set the boot chain extended, so a tampered runtime cannot quietly produce a clean report.

Why runtime attestation on OpenFactory exists

The pitch for "tamper-evident compute" sounds great in a sales deck. In practice, an auditor doesn't want a deck — they want evidence. 21 CFR Part 11 (the FDA's rule for electronic records and signatures in regulated medical and pharmaceutical systems) and DORA (the EU's Digital Operational Resilience Act for financial services) both require operators to prove that security controls are enforced, not merely configured. A configured control with no proof of enforcement is, to a regulator, a control that is not in force.

The threat that makes this concrete is supply-chain compromise of the platform itself. The 2025 Verizon Data Breach Investigations Report found that 30% of breaches now involve a third party — a 100% increase year over year, and Cybersecurity Ventures projects the global cost of software supply-chain attacks reaching $60 billion in 2025. When the package, the build, or the kernel module you trusted turns hostile, the only durable defense is evidence that survives the compromise: a signed report the attacker cannot forge, anchored in hardware the attacker cannot reach from userspace. That is what a TPM-sealed attestation gives you — and why confidential-computing spend is climbing past $15 billion in 2026.

The enforced-versus-configured distinction is also what breaks single-source monitoring. If systemd reports a service is running with NoNewPrivileges=true, the monitoring system records "no new privileges" and moves on. If a kernel module disables that flag at runtime, systemctl show still says NoNewPrivileges=true — because systemd is reading from its own configuration, not from /proc/PID/status. The orchestrator marks its own homework. That's the failure mode runtime attestation on OpenFactory is built to prevent.

The dual-source verification model

OpenFactory layers attestation across fourteen verification levels (V1–V14). The early levels cover what you booted; the later levels cover what is actually running.

V1–V3 — signed-build verification (live today). Every OpenFactory ISO ships with a signed manifest. Each file's hash is recorded at build time, the manifest is chained into measured boot, and dm-verity enforces the chain at runtime so a modified base image fails to mount. This is the same chain that already powers the tamper-evident compute page on the site — runtime attestation builds directly on top of it.

V4–V14 — live-runtime kernel + systemd cross-check (rolling out). Periodic paired-observation reports across six domains:

• Resource limits. systemd MemoryMax, CPUQuota, TasksMax against kernel memory.max, cpu.max, pids.max.
• Security policies. systemd ProtectSystem, NoNewPrivileges, PrivateTmp against kernel mount flags, namespace state, and prctl(PR_GET_NO_NEW_PRIVS).
• Network state. systemd socket activation against kernel ss / netstat listeners.
• File permissions. systemd UMask, ReadOnlyPaths against actual mount options and file modes.
• SELinux / AppArmor. systemd security context against /proc/self/attr/current and /sys/fs/selinux/enforce.
• Capabilities. systemd CapabilityBoundingSet against /proc/PID/status CapBnd.

Each report is a flat JSON document. It is verbose by design: auditors don't want clever — they want grep-able. The agent writes it to /var/lib/openfactory/attestation/reports/ and the CTO GUI mirrors it to a dual-column comparison view: systemd on the left, kernel on the right, discrepancies in red with an English-language explanation of what the mismatch means and its security implication.

How it chains end to end

The full chain runs from the build machine to the running VM. Each stage measures the next before handing off control, and every measurement is folded into a Platform Configuration Register (PCR) inside the TPM. PCRs are append-only: a value can be extended (hashed together with what was already there) but never rewritten, so the final register state is a tamper-evident fingerprint of the entire boot path. Measured boot occupies PCRs 0–7 (firmware, bootloader, Secure Boot state), with the kernel's Integrity Measurement Architecture extending PCR 10 for user-space binaries. The TPM then proves those values with a signed quote that a remote verifier checks against the expected build.

Walking that chain step by step:

1. Build time. OpenFactory generates the ISO, computes per-file hashes, and signs a manifest with a build_id. The manifest is the seed for everything downstream.
2. Boot. dm-verity verifies the base image against the manifest. The TPM extends PCRs as each layer loads. Boot-time attestation is anchored to a TPM quote referencing the build ID.
3. Runtime. A 5-minute systemd timer triggers the dual-attestation agent. The agent queries systemd for expected state, queries the kernel for actual state, and writes a paired JSON report.
4. Signing. The report is signed with a key sealed to the same PCR set the boot chain extended. A tampered runtime cannot produce a valid signature.
5. Surface. Reports stream to the CTO GUI and land in object storage for the audit trail. Discrepancies trigger alerts.

Enabling it on a recipe

Runtime attestation is opt-in. Most fleets don't need it; the ones that do need it across every node. Add dual-attestation to your recipe's feature list and OpenFactory installs the agent and configures the timer:

{
  "name": "gxp-medtech-station",
  "base_image": "ubuntu-24.04",
  "features": [
    "dm-verity-verification",
    "dual-attestation",
    "gxp-ssh-hardening",
    "auditd"
  ]
}

That's it. The hook installs a Python agent at /opt/openfactory/attestation-agent/, sets up the systemd timer, and seals the signing key to the boot chain. First report writes within 5 minutes.

What this is not

Runtime attestation on OpenFactory is not intrusion detection. It does not look for known-bad patterns and it does not try to fingerprint malware. It catches a much narrower failure mode: policy that is configured but not enforced. That's a different problem from "an attacker is on the box," and the evidence it produces is for auditors, not SOC analysts.

It also is not a replacement for monitoring. You still need metrics, logs, and alerting. What runtime attestation adds is the one thing those tools structurally cannot provide: signed, paired evidence that the orchestrator and the kernel agree on the live state of the system.

And it is not a sandbox. Confining what an AI agent or workload is allowed to touch is a separate control — see sandboxing AI agents on OpenFactory for that layer. Attestation tells you whether the confinement you configured is still the confinement the kernel enforces. The two compose: sandbox sets the policy, attestation proves it holds.

Where this gets operational is the hand-off to your system of record. A signed mismatch is exactly the kind of high-confidence signal that should open a change or incident automatically — which is why teams running ServiceNow wire attestation findings into it. See OpenFactory + ServiceNow for Linux fleet management for how drift and attestation failures flow into CMDB, incidents, and GRC evidence.

Where to next

If you're scoping an FDA-validated medical workstation, a DORA audit for a trading platform, or a defense fleet that needs to answer the "prove enforcement" question, the Runtime Attestation reference page has the full FAQ and the recipe-side configuration; the Tamper-Evident Compute page covers the boot-chain foundation runtime attestation builds on; and the Enterprise & GxP page covers fleet-scale deployment. To see a verified build land on a running VM, open the OpenFactory console, walk through the GxP demo, or check pricing for regulated-fleet tiers.