二種類の認証

The word “attestation” now means two unrelated things in open source, and the people using it in each sense don’t seem to be talking to each other much.

npm and PyPI have both shipped build provenance attestations using Sigstore over the past couple of years. When you publish a package from GitHub Actions with trusted publishing configured, the CI environment signs an in-toto attestation binding the artifact to the source repository, commit, and workflow that built it, and the signature goes into a public transparency log that anyone downstream can verify without trusting the registry. PyPI has had this on by default for trusted publishers since late 2024, npm generates provenance automatically, and the cost to publishers is close to zero. I wrote about how this fits into the broader reproducible builds picture recently.

Meanwhile the EU Cyber Resilience Act, which grew out of product safety regulation originally written for things like toasters, introduced “open source stewards” as a legal concept, and Article 25 gives the European Commission power to create voluntary security attestation programmes for them. At FOSDEM this year, Æva Black presented work with the Eclipse Foundation on what such a programme might look like. The proposed model has manufacturers funding stewards who issue attestations about the projects they support, with a tiered approach where the light tier asks whether a project has functional tests, a vulnerability reporting contact, and an end-of-life policy. Æva noted a maintainer could fill it out in minutes. So this is a checklist about project hygiene, filled out by a human, attesting to things like whether a CONTRIBUTING.md exists, which has almost nothing in common with a cryptographic proof logged in a transparency ledger except that both are called attestations.

Madalin Neag at OpenSSF wrote an excellent piece in January working through the details of how steward attestations relate to the projects they cover, since stewards don’t control technical decisions or releases, and a point-in-time attestation may not reflect the state of a component by the time a manufacturer integrates it. These are the kind of design questions that need working out as the delegated act takes shape.

This isn’t the first time naming has caused confusion at the boundary between open source and compliance. The CRA itself calls anyone who places software on the EU market a “manufacturer,” which is product safety language from the world of toasters and power tools. Daniel Stenberg got a taste of what that framing produces when a company sent him a compliance questionnaire demanding he account for Log4j in curl, treating him as a vendor with SLA obligations for a project that has never used Java.

Both SPDX and CycloneDX have a “supplier” field for each component, and SBOM generators routinely fill it with the maintainer’s name, even though the maintainer has no contractual relationship with the consumer and is not a supplier in any commercial sense. These words carry legal connotations that don’t match the relationships they’re describing, and now that they’re codified in standards and regulation they’re difficult to undo.

What I keep thinking about is the maintainer who enables trusted publishing, whose CI generates Sigstore provenance on every release, and who then gets contacted by a foundation about a CRA attestation programme asking them to fill out a form about whether they have a security policy. The cryptographic attestation infrastructure already exists and already generates machine-verifiable supply chain metadata at scale, and continuous signals like CSAF advisories and VEX documents provide ongoing security posture rather than point-in-time snapshots. The Article 25 delegated act hasn’t been written yet and the Commission is still taking input. It would be nice if the two communities compared notes before then, if only so that maintainers don’t end up navigating two unrelated things with the same name.

Naming is hard, but it matters more than usual when the names carry assumptions about what’s actually in place. “Attested” sounds rigorous whether or not it is, and “supplier” implies a contractual relationship that doesn’t exist. Once these words are in standards and regulations, people downstream build processes around what they think the words mean, and unpicking those assumptions later is much harder than getting the names right in the first place. Toaster regulations at least have the advantage that everyone agrees on what a toaster is.