Skip to main content
Version: main

ADR 012: SBOM as part of the release process

Status​

In Progress

Context​

The ServiceNow SDK for Go currently has no mechanism to generate or verify a Software Bill of Materials (SBOM) as part of the release pipeline. Without an SBOM, consumers and maintainers have no visibility into the third-party components and their licenses included in released artifacts, which is increasingly required by compliance frameworks and artifact scanning tools.

Decision​

We will integrate SBOM generation into the release process with the following approach:

  1. Tooling: Use syft (via chaosproject/syft or equivalent) to generate a SBOM (SPDX or CycloneDX format) from the built Go modules and dependencies during the CI pipeline.
  2. Artifact Publishing: The generated SBOM file will be published as an artifact alongside the release tarball/container image, with a predictable path (e.g., sbom.json or sbom-spdx.json).
  3. Verification: Optionally, include a checksum or signature of the SBOM to ensure integrity, leveraging existing CI signing mechanisms.
  4. Documentation: Update the release notes and contributing guide to reference the SBOM artifact and how consumers can inspect it.

Alternatives considered:

  • Skip SBOM generation: Leaves the project without compliance visibility and fails artifact scanning checks.
  • Use go-licenses only: go-licenses can generate license reports but not a full SBOM with dependency trees; insufficient for tooling that expects SPDX/CycloneDX format.
  • Generate SBOM only on demand: Would require manual invocation and would not be part of the automated release pipeline, reducing reliability and adoption.

Consequences​

  • Provenance: Release artifacts will include a complete dependency inventory, enabling tooling (e.g., GitHub Dependabot, Container Scanning) to accurately report components and licenses.
  • Tooling overhead: CI pipeline will require syft (or similar) as a build dependency; adds a small fixed time cost per release.
  • Artifact size: The SBOM file is typically small (KB range) and negligible impact on total release size.
  • Maintenance: The SBOM generation step must be kept in sync with dependency updates; ideally automated via CI on every push to main/release branches.
Was this page helpful?