We Sign Every Release. Here's What That Actually Proves.

If your product's whole job is proving what's actually inside somebody's software, it would be a strange gap if nobody could prove what's actually inside yours. Security tools are a specific kind of attractive target: customers trust them by design, which means a compromised update landing on someone's machine does more damage than almost anything else that could go wrong.

So before anything else in this post: none of what follows is public yet. There's no v1.0 release you can go check today. That's a real, dated milestone (2 October), not a soft "coming eventually." I'm writing about the commitment now because it's already built into how the pipeline works, not something we're planning to bolt on the week before launch.

Only CI gets to publish a release

No developer laptop uploads a binary directly, not even mine. The only path from a tagged commit to a published artifact runs through CI. That isn't about distrust of any one person. It's about removing a step where a stolen credential, a compromised laptop, or a rushed manual build could quietly become "the official release" without anyone noticing.

It sounds like a small rule. In practice it means there's exactly one place an attacker would need to compromise to slip in a bad build, and that place is the thing hardest to reach quietly: a CI pipeline, not somebody's laptop on a coffee shop network.

Signing and provenance, not just a checksum

Every release gets signed with cosign, and carries SLSA (Supply-chain Levels for Software Artifacts) provenance metadata describing exactly what built it and from which commit. A checksum tells you a file hasn't changed since someone else calculated the same checksum, which proves nothing about whether you trust that someone. A signature backed by CI-issued provenance tells you the artifact came from the pipeline it claims to have come from, and traces back to a specific, named source commit.

Once v1.0 ships, verifying a release will look like this:

$ cosign verify --certificate-identity-regexp 'https://github.com/bomwerk/.*' \
    --certificate-oidc-issuer https://token.actions.githubusercontent.com \
    ghcr.io/bomwerk/bomwerk:v1.0.0

Verification for ghcr.io/bomwerk/bomwerk:v1.0.0 --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The code-signing certificate was verified using trusted certificate authority certificates

That command doesn't exist yet for a real reader to run. It's what the commitment resolves to once there's something public to point it at.

What this proves, and what it doesn't

Signing proves the binary you're holding matches what CI built from a specific commit, and hasn't been altered since. It doesn't prove the code is free of bugs, and it isn't a defense against a vulnerability that was already in the source when it got signed. Vulnerability scanning of dependencies is a separate, ongoing job, and no amount of signing replaces it.

It's also worth saying plainly what signing is not for. It's not copy protection. bomwerk's core is Apache-2.0, so there's nothing to protect against copying in the first place. Code signing and DRM solve different problems, and treating the first as a substitute for the second is how you end up with a tool that's both annoying to use and no more trustworthy. The point of signing isn't to stop someone from having a copy. It's to let them check that the copy they have is the one we actually built.

Publishing our own SBOM

If a tool's whole job is producing an SBOM you can hand to an auditor, the first SBOM it should stand behind is its own. Every bomwerk release will ship with an SBOM of bomwerk itself, generated the same way a customer's would be, with the same scanner. Believing your own claims about your own output is a low bar. It's also a bar plenty of tools quietly never clear, because nobody outside the company ever checks.

Asking a customer to trust a compliance tool on faith is exactly the failure mode this whole category of software exists to prevent everywhere else. We'd rather not be taken on faith. We'd rather be checked, once there's something to check.