Skip to main content
Version: 1.9.x

Sbom

Sbom

A software bill of materials (sbom) declares the inventory of components used to build a software artifact such as a software application. Components in the SBOMs define "what" gets transferred. SBOM files are referenced by a Manifest YAML file to allow multiple deliverables to be combined into a single product.

CycloneDX SBOMs

CycloneDX standard is the SBOM format we're using to define Software Bill of Materials (sboms).

Reference

SBOM Generation Tools

There are a number of tools that can generate a CycloneDX SBOM for your project, the CycloneDX Tool Center is a great place to start looking.

Component Scope

Scope is an optional field within a component that sets the desired scope of that component. Hoppr uses this field to understand how to handle the various components found in the provided sbom(s)

According to the CycloneDX specification Scope can be set to three options:

  • Required:
    • The default if scope not specified for a given component. Meaning if a components scope is not specified in the sbom, Hoppr will treat that component as required and will fail if that component fails to be collected. Even if the desired collector plugin is not included in the transfer.yml.
  • Optional:
    • Hoppr will attempt to collect this component via the appropriate collector. Currently handled the same as 'required' (described above).
  • Excluded:
    • No attempt to collect this component will be made. Hoppr does not send this component to any collector. The job output will document the excluded items for visibility.

Example Component with Scope field:

{
"type": "library",
"name": "go-gitlab",
"version": "0.81.0",
"purl": "pkg:golang/github.com/xanzy/go-gitlab@v0.81.0",
"scope": "excluded"
}

Delta Sbom

Delta Sbom is a plugin to remove SBOM components that are specified by a previously defined manifest.yml or tar bundle. This plugin will take an input of an manifest.yml or tar bundle, compare it to the previous, and create a delta sbom. It checks for updates and if the component has been updated, will deliver. For example, take 2 bundles. Bundle 2 has everything with the exact same versions from Bundle 1, except 4 new containers. These 4 new containers, also now known as deltas, would create the delta sbom.

Using the -pd or --previous-delivery flag represents the previous delivery for the path to manifest or tar bundles.