Generate and publish a CycloneDX SBOM as a release artifact

[dgenio]

Summary

Produce a CycloneDX software bill of materials during the release workflow and attach it to the GitHub Release (and optionally to the published distribution), so adopters can ingest ChainWeaver's dependency provenance into their own supply-chain tooling.

Why this matters

SBOMs are increasingly expected by security-conscious and regulated adopters (EU CRA momentum), and ChainWeaver already invests in trustworthy releases (OIDC trusted publishing, Dependabot). A published SBOM closes the loop: it lets downstream consumers verify exactly what a release pulls in, which is a meaningful adoption signal for enterprise users evaluating the library.

Current evidence

• .github/workflows/publish.yml / release.yml exist (release + trusted publishing), but no SBOM/CycloneDX step is present (verified by grep).
• pyproject.toml declares a small, deliberately-minimal runtime dependency set — an SBOM is cheap to generate and easy to verify against.
• Open Pin release-critical GitHub Actions to commit SHAs and add build attestations #346 (pin release Actions to SHAs + build attestations) is the adjacent supply-chain hardening issue; an SBOM is the complementary artifact (note the relation).

External context

CycloneDX provides Python tooling (cyclonedx-py) to generate SBOMs from an environment or pyproject.toml; attaching SBOMs to releases is a common practice.

Proposed implementation

1. Add a release-workflow step generating a CycloneDX SBOM (cyclonedx-py) from the built distribution / locked environment.
2. Upload it as a Release asset (and consider including it in the sdist/wheel metadata directory if appropriate).
3. Document where to find the SBOM and how to verify it in docs/distribution.md / SECURITY.md.
4. Coordinate with Pin release-critical GitHub Actions to commit SHAs and add build attestations #346's attestation work so SBOM + attestation ship together.

AI-agent execution notes

Inspect .github/workflows/publish.yml and release.yml, docs/distribution.md, SECURITY.md, open #346. Do not weaken the existing OIDC trusted-publishing flow; add the SBOM step without granting extra write scopes beyond release-asset upload. Keep SBOM generation deterministic where possible.

Acceptance criteria

• Each release attaches a CycloneDX SBOM asset.
• The SBOM lists ChainWeaver's runtime dependencies and versions.
• docs/distribution.md/SECURITY.md document its location and verification.

Test plan

A dry-run of the release workflow on a tag in a fork/branch producing the SBOM asset; schema-validate the generated SBOM against CycloneDX.

Documentation plan

docs/distribution.md, SECURITY.md, CHANGELOG (release-artifact note).

Migration and compatibility notes

Not expected to require migration.

Risks and tradeoffs

Slight release-workflow complexity; SBOM tooling versions need maintenance. Coordinate with #346 to avoid two overlapping supply-chain PRs.

Suggested labels

security, ecosystem, documentation