Context
During the design of the release process (feature 006-release-process), we debated whether to include an SBOM with each release. The plugin is a Mode 3 reference-only distribution (11 files — markdown, shell scripts, JSON manifests) that does not bundle any external tools. Key findings:
- A syft-auto SBOM produces a file inventory that's largely redundant with the SLSA provenance's source tree hash
- The plugin's external runtime requirements (Kusari CLI, jq, bash) are declared in
plugins/kusari/prerequisites.json and enforced at install time — not bundled
- An SBOM with
HAS_PREREQUISITE relationships (SPDX) was prototyped but dropped because no consumers currently process SBOMs for Claude Code plugins, and the information is already available via prerequisites.json + provenance
What to explore
- When does an SBOM become genuinely useful for this artifact type? (compliance requirements, registry publishing, downstream tooling adoption)
- If/when the plugin bundles dependencies or installs external tools (Mode 1/2/4), the SBOM should expand — what triggers that transition?
- SPDX vs CycloneDX format preference for the Claude Code ecosystem
- Whether the
prerequisites.json → SPDX HAS_PREREQUISITE pattern (prototyped in the design docs at specs/006-release-process/) is the right shape when we do add it
- Constitution §III mandates SBOM per release — should this be amended for plugin-shaped artifacts, or should the SBOM be added once the ecosystem matures?
Design artifacts
The full design discussion (distribution scope = SBOM scope, Mode 3 framing, HAS_PREREQUISITE vs RUNTIME_DEPENDENCY_OF) is preserved in:
specs/006-release-process/research.md §2 and §12specs/006-release-process/data-model.md (Prerequisites declaration entity)specs/006-release-process/contracts/prerequisites-declaration.mdspecs/006-release-process/contracts/release-artifact-shape.md (SBOM content expectations — currently reflects the dropped design)
These can serve as the starting point when this work is picked up.
Extension point
The release workflow (.github/workflows/release.yml) has a post-version-bump extension point where SBOM generation would naturally land — after validation passes, before signing/provenance.
Context
During the design of the release process (feature 006-release-process), we debated whether to include an SBOM with each release. The plugin is a Mode 3 reference-only distribution (11 files — markdown, shell scripts, JSON manifests) that does not bundle any external tools. Key findings:
plugins/kusari/prerequisites.jsonand enforced at install time — not bundledHAS_PREREQUISITErelationships (SPDX) was prototyped but dropped because no consumers currently process SBOMs for Claude Code plugins, and the information is already available viaprerequisites.json+ provenanceWhat to explore
prerequisites.json→ SPDXHAS_PREREQUISITEpattern (prototyped in the design docs atspecs/006-release-process/) is the right shape when we do add itDesign artifacts
The full design discussion (distribution scope = SBOM scope, Mode 3 framing,
HAS_PREREQUISITEvsRUNTIME_DEPENDENCY_OF) is preserved in:specs/006-release-process/research.md§2 and §12specs/006-release-process/data-model.md(Prerequisites declaration entity)specs/006-release-process/contracts/prerequisites-declaration.mdspecs/006-release-process/contracts/release-artifact-shape.md(SBOM content expectations — currently reflects the dropped design)These can serve as the starting point when this work is picked up.
Extension point
The release workflow (
.github/workflows/release.yml) has apost-version-bumpextension point where SBOM generation would naturally land — after validation passes, before signing/provenance.