What goes into a signed release evidence bundle
When an auditor asks for the release record, most teams produce a collection of links. The question is what should go in the record itself, why it should be signed, and what each component actually proves.
Why a "bundle" rather than a collection of links
The default state of most engineering organisations is that a release record is a scavenger hunt. The SBOM lives in the artifact registry. The approvals live in the ticket tool. The policy decisions live in someone's spreadsheet. The signed build attestations live in CI logs that roll over every ninety days. Asked for "the release record", the team produces a wiki page of links, half of which return 404 by the time the auditor clicks them.
The defining shift is to make the bundle itself the system of record, not a pointer to it. The component artifacts are inputs to the bundle; the bundle is what survives. It is content-addressed, signed, and immutable. The bundle does not depend on any external dashboard remaining online to be valid.
Component 1 — SBOM
A Software Bill of Materials enumerates every component in the release, its version, and its license. CycloneDX and SPDX are the two formats that matter; both are accepted by every modern scanner and procurement gate. An SBOM proves what is in the release: dependencies, transitive dependencies, license posture.
On its own an SBOM does not prove who built the release, when, or from which source. That is the gap SLSA provenance fills. An SBOM without provenance is a parts list without a build record.
Component 2 — SLSA provenance
SLSA (Supply-chain Levels for Software Artifacts) is the framework procurement teams now reference. The framework defines four levels of build-pipeline integrity, with level 3 as the realistic enterprise floor. A level-3 build is isolated, hermetic, and produces a signed provenance attestation that records the source repository, commit, builder identity, and build inputs.
Provenance is the answer to "where did this come from". Paired with the SBOM's "what is in this", you have the two halves of a verifiable release. Without provenance, the SBOM is asserting something about an unverified artifact.
Component 3 — Approvals
Approvals are the human authorisation chain. The auditor's question is not "did anyone approve this" but "who approved this, against which version of policy, with which evidence shown, against which intent". Pull-request comments do not answer that question. A typed approval record does: it captures the actor identity, the policy version, the input shown to the actor, the decision outcome, and the timestamp.
The architectural shift is to record approvals as decisions against typed policy at typed boundaries, not as free-text comments at human-eyeballed checkpoints. The record then replays cleanly against the policy version that produced it.
Component 4 — Policy outcomes
Every stage transition in a governed lifecycle produces a policy decision: pass, fail, exception. Aggregated across the release, those decisions are the audit narrative. They tell the story of how the release moved from intent to deployable artifact, what was checked at each step, and what exceptions were granted by whom.
Crucially, policy outcomes are versioned. The decision is replayable against the exact policy version that produced it — so a policy change next quarter does not retroactively reinterpret last quarter's release record. The audit narrative is durable.
Why signing matters
A bundle without a signature is a JSON file. A bundle with a signature is a tamper-evident record. The two relevant primitives are cosign (single-artifact signing, simple to integrate) and the in-toto framework (composable attestations, used heavily in supply-chain pipelines).
The signing key matters as much as the signature. Long-lived keys held in a CI secret are not enough for serious procurement review. Short-lived keys issued by an OIDC-authenticated build identity (the Sigstore / keyless-signing pattern) are what mature pipelines use. The bundle records the verifier-relevant metadata so a future auditor can validate the signature without depending on a private trust store.
How GrowAppAI generates the bundle
GrowAppAI's release-packaging stage produces this bundle automatically as the closing step of every governed run. It aggregates the SBOM, the SLSA provenance, the typed approvals, and the policy outcomes from every prior stage; signs the aggregate; writes it to artifact storage; and links it into the canonical traceability graph as the release node.
The bundle is the system of record for that release. Every component dashboard remains useful for live operation. None of them are required for the release to be reconstructible. See the platform for the architectural detail, or read the deployment model if your evaluation is gated on where signing keys live and how they are rotated.
Reconstruct one of your releases end-to-end
Book a working session and we will walk a real release through the bundle structure — what your current pipeline produces, what it does not, what an auditor would accept.