Support different SBOMs types
In April 2024, CISA published this document describing different types of SBOMs: https://www.cisa.gov/resources-tools/resources/types-software-bill-materials-sbom
While implementing all these types would be challenging, distinguishing "Source" and "Build" types is more straightforward but also useful.
For example, in our own SBOM for gitlab-core, we clean-up some reports to create this distinction. This is because these reports are created for parts of the application not running in production (used for test purposes only).
Ignoring these paths (with DS_EXCLUDED_PATHS) isn't an option because we still want to scan their dependencies. We just don't want to include them in the final SBOM.
Quoted from the CISA document:
| SBOM Type | Definition | Data Description |
|---|---|---|
| Design | SBOM of intended, planned software project or product with included components (some of which may not yet exist) for a new software artifact. | Typically derived from a design specification, RFP, or initial concept. |
| Source | SBOM created directly from the development environment, source files, and included dependencies used to build an product artifact. | Typically generated from software composition analysis (SCA) tooling, with manual clarifications. |
| Build | SBOM generated as part of the process of building the software to create a releasable artifact (e.g., executable or package) from data such as source files, dependencies, built components, build process ephemeral data, and other SBOMs. | Typically generated as part of a build process. May consist of integrated intermediate Build and Source SBOMs for a final release artifact SBOM. |
| Analyzed | SBOM generated through analysis of artifacts (e.g., executables, packages, containers, and virtual machine images) after its build. Such analysis generally requires a variety of heuristics. In some contexts, this may also be referred to as a “3rd party” SBOM. | Typically generated through analysis of artifacts by 3rd party tooling. |
| Deployed | SBOM provides an inventory of software that is present on a system. This may be an assembly of other SBOMs that combines analysis of configuration options, and examination of execution behavior in a (potentially simulated) deployment environment. | Typically generated by recording the SBOMs and configuration information of artifacts that have been installed on systems. |
| Runtime | SBOM generated through instrumenting the system running the software, to capture only components present in the system, as well as external call-outs or dynamically loaded components. In some contexts, this may also be referred to as an “Instrumented” or “Dynamic” SBOM. | Typically generated from tooling interacting with a system to record the artifacts present in a running environment and/or that have been executed. |
Typically, only "Source" is currently supported in GitLab. While we do have SCA running on build projects (like https://gitlab.com/gitlab-org/omnibus-gitlab, or https://gitlab.com/gitlab-org/gitlab-build-images), we don't process or expose these SBOMs yet.
Proposal
Let users specify the type of SBOM report for the one generated by Dependency Scanning.
Note that it's not a trivial setting, because we don't know in advance where reports are going to be created.