Release Profile

Signing improved. Handoff did not.

Binary, SBOM, provenance, signature — scattered across emails, CI artifacts, and vendor portals. PX bundles them into one verifiable pack. Recipients open Lens to confirm everything in five seconds.

The problem with scattered artifacts

Binary and SBOM arrive separately

Recipients cannot tell which SBOM corresponds to which binary without manual cross-referencing.

Provenance is buried in CI

Build provenance exists, but recipients cannot easily find or verify it outside the CI platform.

No starting point for verification

Files may all be present, but without a verification entry point, trust cannot be confirmed.

Adding the handoff layer on top of signing

Individual signing and attestation tools are mature. What is missing is a portable handoff package that bundles everything for the recipient.

Sigstore / GitHub Attestations PX Release Pack
Binary signing Supported Included + hashed
SBOM attachment Generated separately Included + format check
Provenance Attestation Included + binary binding
Bundle as a set One portable pack
Recipient verification — CLI required Lens (browser only)
Offline verification Individual files Full set offline
Release lineage parent_manifest_refs

software-release-v1 profile

The profile defines what must be included, what is recommended, and what is optional.

ClassRequiredVerification
binary Required At least one distributable binary present
sbom Required SPDX or CycloneDX JSON format
provenance Recommended SLSA provenance subject digest matches binary SHA-256
signature Recommended Sigstore bundle or detached signature
changelog Optional Change log
license Optional License file
vex Optional Vulnerability Exploitability eXchange
scan_result Optional Vulnerability scan result (JSON)

Missing a required item triggers FAIL-CLOSE — the pack is not created. Missing a recommended item triggers WARN — the pack is created with a warning.

GitHub Action

Add three lines to your release workflow. Packs are generated automatically after build.

# .github/workflows/release.yml - name: PX Pack uses: ./.github/actions/px-pack with: evidence-path: ./dist profile: software-release-v1

Self-test CI (running on main)

TestFixtureResult
Full release binary + SBOM + provenance + signature + changelog + LICENSE PASS 7/7
Minimal binary + SBOM only WARN 5/7 + 2 recommendations

GitHub Actions →

Release lineage

Each pack can reference its predecessor via parent_manifest_refs[]. Recipients can verify that v2.1 follows v2.0. This builds a chain of trust across releases, not just within a single one.

EU Cyber Resilience Act (CRA)

The CRA entered into force on December 10, 2024. Reporting obligations begin September 11, 2026. Full obligations apply from December 11, 2027. Maximum penalty: €15M or 2.5% of global annual revenue, whichever is higher.

SBOM obligation

PX packs require SBOM (SPDX/CycloneDX). Format-validated. Delivered to recipient as part of the pack.

Vulnerability management trail

Include VEX and scan results in the pack to provide a complete vulnerability response trail.

Update continuity

Release lineage proves continuous security updates across versions — evidence that the CRA requires.

Start with sample data.

$ npx px-pack init --demo

Then add PX to your release workflow.

$ npx px-pack pack --profile=software-release-v1 --evidence=./dist/

Reads files only. Writes to ./px/output/. No upload. No telemetry.