Attestium compared with related approaches
Attestium checks what a server runs after deployment, against public references the operator does not control. Most related tools secure an earlier step (the build, the signature, the boot chain) or compare a machine with its own earlier state. Attestium uses several of them as references rather than replacing them.
Summary#
| Approach | What it establishes | Where it stops | How Attestium relates |
|---|---|---|---|
| Reproducible builds | Anyone can rebuild the same bytes from the source | Says nothing about the bytes on a server | Uses a reproduced build as the reference for generated files |
| SLSA provenance | How and where an artifact was built, from which source | Ends when the artifact is deployed | Verifies provenance as a reference for packages, releases and images |
| in-toto | That each supply chain step was done by the expected party | Ends after the last step | Reads in-toto statements inside SigstoreA public signing service: short-lived certificates from Fulcio tied to an OIDC identity, with signatures logged in Rekor. bundles |
| Sigstore | Who signed an artifact, logged in a public transparency log | A signature is not proof the artifact runs | Verifies Sigstore bundles with the signer identity the verifierThe component that runs elsewhere, typically in CI: it sends a nonce, obtains references itself and compares. requires |
| Keylime | TPMTrusted Platform Module: a chip with keys that cannot be exported and registers (PCRs) that can be extended but never set. and IMAIntegrity Measurement Architecture: the Linux kernel hashes files as they are used, logs each hash and extends PCR 10. attestation against operator-maintained policies | Expected hashes come from the operator | Derives expected hashes from public references, and works without a TPM |
| System Transparency | A signed, reproducible operating system image, booted without state | Covers the boot chain, not the application | Applies the same goal to the running application |
| TPM or TEE attestation alone | Which machine answered, how it booted, its launch measurement | Says nothing about the application unless its evidence is bound in | Binds SHA-256(nonce ‖ digest) or SHA-512(nonce ‖ digest) into the hardware statement |
| File integrity monitoring | A file changed since an earlier snapshot of the same machine | A snapshot taken after a compromise is a bad baseline; memory is not checked | Compares each running file with an outside reference and checks process memory |
| Package analysis (for example Socket) | What a package does | Does not check what is installed on a server | Checks that installed files are exactly the artifacts the lockfile pins |
Reproducible builds#
Reproducible Builds means a given source always produces the same binary, so independent parties can confirm a binary came from its claimed source. That proves something about an artifact. It does not show that a server runs that artifact. Attestium is the runtime counterpart: it compares the binaries, packages and generated files on a server with the published ones. When a deploy generates files the repository ignores, such as a browser bundle, the verifier rebuilds the same commit and compares, which depends on the build being reproducible.
SLSA and in-toto#
SLSA provenance describes how, where and from which source an artifact was built. in-toto records that each step of a supply chain was performed by the expected party. Both end at the artifact. GitHub artifact attestations and npm provenance are Sigstore bundles carrying in-toto statements with SLSA provenance, and Attestium verifies them as references for release manifests, container images and npm packages. See Signatures and trust.
Sigstore#
Sigstore issues short-lived signing certificates through FulcioSigstore's certificate authority. It issues short-lived signing certificates for OIDC identities. and logs signatures in RekorSigstore's public, append-only transparency log of signatures.. A signature proves who signed, not that the signed artifact is good or deployed. Attestium checks the certificate chain, the log entry and the signer identity you require (repository, workflow file and ref), using a trusted root fetched with its own TUFThe Update Framework: signed, versioned metadata for distributing keys and files. Sigstore ships its trusted root with it. client. See Sigstore bundles.
Keylime#
Keylime is a CNCF sandbox project for TPM-based remote attestation, with measured boot and IMA runtime policies. Its policies are lists of expected file hashes that an operator maintains. Attestium also verifies TPM quotes and IMA logs, and differs in three ways:
- It obtains the expected value of every running file from a public reference: the git commit, the lockfile's registry artifacts, the container image, the official runtime release or the signed distribution archive. A third party with no relationship to the operator can therefore perform the check.
- It compares process memory with the files on disk and checks each runtime's code injection vectors.
- It works without a TPM, at the software evidence level, and with AMD SEV-SNPAMD Secure Encrypted Virtualization with Secure Nested Paging: confidential VMs whose launch measurement the AMD chip signs. and Intel TDXIntel Trust Domain Extensions: confidential VMs whose measurement is signed through Intel's quoting enclave. confidential VMs.
System Transparency#
System Transparency, developed for Mullvad's VPN servers, boots a signed, reproducible operating system image without persistent state, so users can verify what a server boots. Attestium shares the goal and applies it to the application layer, which in most services changes several times a day: its files, its dependencies, the libraries it maps and its executable memory.
TPM and confidential VM attestation on their own#
A TPM quote proves which machine answered and, with pinned PCRPlatform Configuration Register: a TPM register that can only be extended with a hash. Firmware, bootloader and kernel extend PCRs with what they load. values, how it booted. An AMD SEV-SNP or Intel TDX report proves a VM's launch measurement and that the host cannot read its memory. Neither says anything about the application unless the application's evidence is bound into the signed statement. Attestium binds it: the TPM signs SHA-256(nonce ‖ evidenceDigest) as qualifying data, and a confidential VM report carries SHA-512(nonce ‖ evidenceDigest) as report data. See Hardware-backed evidence.
File integrity monitoring#
File integrity tools compare files with an earlier snapshot of the same machine. A snapshot taken after a compromise is a bad baseline, and code injected into memory with ptrace, LD_PRELOAD or memfd_create leaves the files on disk unchanged. Attestium compares every running file with a reference the operator does not control, compares the executable pages of each mapped file with the file on disk, and reports every running file that no reference explains.
What Attestium does not replace#
Attestium trusts its references. A compromised registry, repository or distribution archive makes bad code look good, which is why it reads lockfiles from the verifier's own checkout, fetches content-addressed references by digest and follows signed archive chains. It also does not judge whether published code is safe: it shows that production runs the code you can read. Keep build-time controls, code review and package analysis in place. See Security model and limits.
Sources#
- The whitepaper, section 7.1, compares these projects in more detail.
- Supply chain verification shows how each build-time tool becomes a reference.
- FAQ answers the most common comparison questions.