Reproducible Builds Were Never Enough: What Malus Gets Right About Supply Chain Security

The reproducible builds movement has spent over a decade making the case that given the same source code and build toolchain, you should get the same binary output. The argument is sound. Debian has been running reproducibility checks across its package archive since 2015. The Tor Project, Bitcoin Core, and a growing list of security-critical projects verify that builds are deterministic. But reproducibility solves a different problem than the one that keeps supply chain security people awake at night.

The xz-utils backdoor (CVE-2024-3094) did not sneak in through a non-deterministic build. It was committed to the source repository by a maintainer account that had been carefully cultivated over two years. The attack triggered only under specific conditions: glibc-based Linux systems, built with gcc, with systemd present. Reproducible builds would have faithfully reproduced the backdoor. A build environment stripped of everything extraneous, producing an artifact cryptographically attested to have been constructed from exactly these inputs, in this environment, by this process, would at least have made the anomaly surface faster during artifact comparison.

That is the problem Malus is trying to solve. The project, which was the subject of a FOSDEM 2026 talk and landed prominently on Hacker News in March 2026, positions itself as “Clean Room as a Service.” The name borrows from semiconductor manufacturing, where a clean room controls particulate contamination to parts-per-million tolerances. In software, the contamination is accumulated state: cached build artifacts from a previous compromised run, environment variables that leak secrets or alter behavior, developer tools that have lived on a machine for three years without audit.

What hermetic actually means

A hermetic build starts with nothing. No ambient network access, no host filesystem leakage, no pre-populated caches from prior runs. The inputs are explicitly declared: this source tree, these toolchain binaries at these verified hashes, these dependencies. The build system resolves everything before the build begins, the network is severed, and the build runs. The output can then be signed with a key tied to the build system itself rather than a developer’s laptop.

Bazel has offered hermetic builds for large monorepos since Google open-sourced it in 2015. Nix’s entire model is built on this principle: every package in nixpkgs is a pure function of its inputs, and the store path encodes a cryptographic hash of everything that contributed to it. Guix goes further with bootstrappable builds, tracing the entire toolchain back to a minimal binary seed to address the “trusting trust” problem Ken Thompson described in his 1984 Turing Award lecture.

These tools are powerful, but they impose significant adoption cost. Migrating a non-trivial project to Bazel is a multi-month engineering effort. Nix has a steep learning curve and a packaging ecosystem that, while extensive, requires real investment to use well. Neither is something you attach to an existing GitHub Actions workflow without substantial rework.

The service model

What Malus offers is the clean room guarantee without requiring you to adopt a new build system. The model resembles how cloud CI services decoupled “I need a clean Linux environment” from “I need to maintain a fleet of build machines.” You get an ephemeral, isolated environment, the build runs, an attestation is produced, and the environment is discarded.

The critical technical question for any service in this space is what the attestation actually covers and who controls the signing keys. In the SLSA framework, provenance attestations record the builder identity, the source repository, the invocation parameters, and the materials (dependencies) that went into the build. SLSA level 3 requires that provenance is generated by a hosted build platform that users do not administer, which is precisely what a “Clean Room as a Service” provides by design.

Sigstore’s cosign and the accompanying Rekor transparency log have made signing and verifying artifacts significantly more accessible since their introduction by the Linux Foundation. The infrastructure for attestation exists; the gap has been making the clean build environments that produce trustworthy attestations accessible to projects that are not Kubernetes or Chromium.

The developer machine problem

There is a dimension of this that does not get enough attention. Supply chain attacks increasingly target developer machines and the tools they run, not just CI systems. The xz-utils attack specifically targeted openssh-server on machines running systemd, attempting to establish a backdoor via SSH access to developer and server infrastructure. A backdoored compiler on a developer’s machine can inject malicious code into any binary that developer compiles, regardless of what the source looks like. Thompson’s lecture described exactly this attack class forty years ago, and it remains a live threat.

Clean room build services decouple the release process from developer machines by design. If the service’s build environment is the authoritative source of signed release artifacts, a compromised developer workstation cannot produce a signed release. That is a meaningful security property that reproducible builds alone do not provide.

What the alternatives cost

Self-hosted hermetic CI is achievable. Tekton on Kubernetes with appropriate pod security policies and network policies provides build isolation. in-toto attestations can be generated and stored. But standing this infrastructure up and operating it for a small open source project, or even a mid-sized engineering team, is not a reasonable ask. It requires Kubernetes expertise, careful network configuration, and ongoing maintenance that most projects cannot sustain.

GitHub’s own artifact attestations, introduced in 2024, move in this direction within the Actions ecosystem, using Sigstore to sign artifacts with an OIDC token tied to the workflow run. This is genuinely useful, but it is limited to GitHub Actions, and the build environment is still a GitHub-hosted runner that the user does not fully control or audit.

The position Malus occupies, offering clean room environments that produce cryptographically attested artifacts as a managed service independent of a specific CI provider, has real value. The 1,000-plus upvotes on the Hacker News thread and the FOSDEM talk slot suggest the timing is right.

The trust question

Managed services in the supply chain security space have a fundamental tension: you are trusting the service itself. If Malus’s build infrastructure is compromised, every attestation it has ever produced is suspect. This is structurally identical to the trust problem certificate authorities face, and the industry has spent decades developing mitigations: Certificate Transparency logs, multi-party signing, auditable HSM-backed key management, public audit reports.

The work that would make “Clean Room as a Service” genuinely robust rather than just a shifted trust boundary is in the transparency and auditability of the service itself. That means publishing a transparency log of build operations, allowing customers to verify that the environment that produced their attestation matches published specifications, and ideally supporting third-party audits of the key management infrastructure.

Whether Malus has solved those problems, or has them on the roadmap, is the question I would want answered before relying on it for release signing of anything security-critical. The architectural direction is correct. Clean, hermetic, attested builds should be the default for any software that people depend on, not a luxury available only to projects with infrastructure teams large enough to run their own Tekton clusters.

The xz-utils attack was a wake-up call. The response from most teams was to add more code review. The more durable response is to make the build pipeline itself an explicit, auditable artifact, and that is what services like Malus are reaching for.