Amutable

Amutable

2 min read Original article ↗

01

Verified build

Hermetic, reproducible builds with full provenance.

Every component and image is built in a hermetic, pinned environment and comes out bit-for-bit reproducible, signed, and ready for standard SBOM tooling and security scanners.

  • Pinned inputs from the distribution of your choice
  • Bitwise reproducible components and bootable images
  • Signing with hardware keys through PKCS#11
  • SBOMs that work with syft, grype and trivy

The tine build system →

02

Immutable OS

A minimal, image-based Linux system that starts verified.

A read-only, image-based operating system. Signed unified kernel images and dm-verity protected volumes mean the system only runs what was built and signed for it.

  • Signed unified kernel images and measured boot
  • dm-verity protected, read-only system volumes
  • Execution policies that only allow trusted code
  • Atomic, image-based updates and rollback

Our kernel work →

03

Trusted delivery

Signed, need-to-know updates built on TUF.

Updates are distributed as signed static content using The Update Framework. Each machine gets its own repository, so it only ever learns about the artifacts meant for it.

  • Built on The Update Framework (TUF)
  • Per-machine repositories with cross-repository links
  • Mirrors and CDNs without trusting the server
  • Key ownership you can move without touching clients

Distributing images with Quarry →

04

Remote attestation

Hardware-rooted proof of what is running.

Trust is rooted in hardware. Nodes report signed measurements of their state, backed by the TPM or confidential computing, so you can verify what is running on your fleet at any time.

  • Measurements rooted in the hardware
  • Signed node reports with systemd-report
  • Predictable measured boot with systemd-pcrlock
  • Works with confidential computing

systemd-report →