Skip to content

Software Bill of Materials

A software bill of materials (SBOM) is a machine-readable inventory of components discovered in a software artifact. Indian Hill Labs uses SBOMs to support vulnerability analysis, dependency review, license analysis, incident response, and consumer transparency.

Published container SBOMs use an identified version of either SPDX or CycloneDX. The release record identifies the format and version; consumers should not assume that fields or semantics are interchangeable across formats.

Artifact association

An SBOM is useful only when its subject is clear. Published SBOM material should identify the immutable OCI digest and relevant release metadata. If the image is rebuilt—even from the same source revision—the resulting digest and SBOM may differ.

Expected content

Depending on artifact type and tooling, an SBOM may include:

  • component names, versions, package identifiers, and suppliers;
  • package URLs or other ecosystem identifiers;
  • file or layer relationships;
  • direct and transitive dependency relationships;
  • license information; and
  • creation-tool and timestamp metadata.

Limits

SBOM generation is a discovery process. Statically linked code, vendored dependencies, dynamically retrieved modules, ambiguous package metadata, or unsupported ecosystems may create incomplete or uncertain results. An SBOM is not proof of secure behavior and does not replace vulnerability assessment, provenance, tests, or signature verification.

Where a material limitation is known, assurance documentation should state it rather than present the inventory as exhaustive.

Current candidate-pipeline implementation

The following describes the private engineering candidate pipeline. It is implementation evidence, not a claim that a public release or SBOM endpoint exists.

GitLab report metadata

The candidate pipeline preserves Syft's raw CycloneDX output and creates separate GitLab report variants that comply with the GitLab CycloneDX property taxonomy. Those variants add the GitLab schema version, a repository-relative source Dockerfile, and container image identity properties required for GitLab ingestion. The enrichment changes report metadata only; it does not add, remove, or reinterpret discovered components or licenses.

CycloneDX ingestion supplies GitLab's component and license views; it is not the container vulnerability-report format. The candidate pipeline therefore also runs GitLab Container Scanning for each image and uploads the native container-scanning report. On the default branch, those reports populate the project Vulnerability report, while the CycloneDX reports continue to populate dependency and SBOM information.