Automated SBOM Generation from Build‑Intent Proposals

The hidden liability

Every vendored file that arrives without a licence header is a risk. Legal teams treat it as a debt that must be repaid before a release can ship. In practice the debt is a folder of hope: you guess the origin, you guess the licence, you hope the guess is right. When a compliance audit asks “who wrote this line?” the answer is “nobody knows”. That answer is a failure mode. It breaks licence compliance and stalls delivery.

Build‑Intent as the source of truth

A Build‑Intent proposal records exactly what an agent intends to write to the repository. The proposal is immutable: it passes the Build Intent gate, the licence and invariant checks run, and a terminal state is returned. Because the proposal is the first authoritative artefact, it can serve as the anchor for an SBOM entry.

Linking the proposal to an SBOM entry removes the guesswork. The SBOM record points to the proposal identifier, the proposal points to the source commit, and the certification harness records the verdict (CERTIFIED, PROVISIONAL, INCONCLUSIVE, FAILED). The chain is repeatable: the same proposal always yields the same SBOM entry, and the published checksums in the root of trust guarantee byte‑for‑byte reproducibility.

Generating an SBOM entry

The SDK exposes a single method that creates the SBOM record at the same time the Build‑Intent is registered.

import { ShpblClient } from '@shpbl/sdk'

const client = new ShpblClient({ token: process.env.SHPBL_TOKEN })

async function proposeAndRecord() {
  const intent = {
    id: 'intent-7f3c9a',
    repository: 'github.com/example/app',
    commit: 'a1b2c3d4',
    changes: [{ path: 'src/util.js', action: 'add' }],
    licences: [{ path: 'src/util.js', licence: 'MIT' }]
  }

  // Register the Build‑Intent; the gate returns a final state.
  const result = await client.registerBuildIntent(intent)

  // The SDK automatically creates an SBOM entry linked to the intent.
  const sbom = await client.fetchSbomEntry(result.intentId)

  console.log('SBOM entry:', sbom.id, sbom.status)
}
proposeAndRecord()

The call to registerBuildIntent performs the invariant checks and writes the proposal to the catalogue. Immediately after, fetchSbomEntry returns the SBOM record that contains:

• the intent identifier,
• the exact source commit hash,
• the licence mapping for each added file,
• the certification verdict from the harness.

Because the SDK, the HTTP API, the MCP chatbot and the offline edition all share the same gate, the provenance chain is identical regardless of the access method.

When the harness later executes the artefact, it records a verdict. If the verdict is CERTIFIED, the SBOM entry can be exported to downstream compliance tools with confidence. If it is PROVISIONAL, the entry still provides a traceable link that auditors can follow, and the missing correctness can be addressed in a later iteration.

Closing the loop on Monday

1. Open your CI pipeline and add a step that calls the SDK’s registerBuildIntent for every new vendored file.
2. Store the returned SBOM identifier alongside the artefact in your artifact repository.
3. Run the certification harness on the next build; if the verdict is CERTIFIED, mark the SBOM entry as final in your compliance dashboard.

By the end of the week you will have an immutable provenance chain for every vendored component, and the licence‑compliance folder of hope will be replaced by a concrete, auditable record.

For a deeper walk‑through of the same pattern, see the related post on linking SBOM records to Build‑Intent proposals.