SBOM Policy

Overview

A SBOM policy in FOSSA is a collection of required fields and file formats that enables control over which attributes of an imported SBOM will be checked for compliance. These ultimately power the SBOM analysis within the project summary of any imported SBOM. You can access SBOM policies next to our other product policy offerings (License, Security, Quality) by navigating to Policies at the top of the FOSSA application.

Policies are then applied either at an Organization level via Organization settings > Projects > Issues enabling you to apply any policy as the default policy for all current or future SBOMs.

Alternatively you can apply any policy to a specific project via Project Settings > Policies.

"Enabling" an SBOM policy will allow the SBOM Analysis to begin surfacing policy violations.

Required fields

Required fields are attributes of an SBOM that must exist in order to be compliant with the SBOM policy. In order to enable ease of use, FOSSA can quickly ensure your policy easily complies with the data fields category of the NTIA minimum elements for an SBOM. For a detailed understanding of NTIA minimum elements please review FOSSA's blog or NTIA publication

Please see the below table for breakdown of each required field.

Required FieldDescriptionScopeNTIA minimum
SBOM AuthorAuthor who created the SBOM itself. This may be an individual, organization, or SBOM creation tool.SBOM metadataYes
Creation TimestampDate and time the SBOM was createdSBOM metadataYes
NameName of the SBOM element (package, file, library, etc.)Component metadataYes
VersionVersion of the SBOM element (package, file, library, etc.)Component metadataYes
SupplierSupplier of the SBOM element (package, file, library, etc.) This may be an individual, organization, or technology such as package manager or registry.Component metadataYes
Package URL (PURL)A unique identifier used to fully identify packages including type, namespace, name, version. Please see the full PURL spec for additional detailsComponent metadataNo
Common Platform Enumeration (CPE)CPE is a structured naming scheme for information technology systems, software, and packages used to associated vulnerabilities. Please see NIST website for additional detailsComponent metadataNo

File Format

File format checks are attributes of the SBOM file itself including spec format (cycloneDX or spdx) , minimum version, and dependency relationship information. In order to enable ease of use, Similarly to required fields, FOSSA can quickly ensure your policy easily complies with the data fields category of the NTIA minimum elements for an SBOM. For a detailed understanding of NTIA minimum elements please review FOSSA's blog or NTIA publication


File Format FieldDescriptionNTIA Minimum
cycloneDX allowedAllow import of SBOMs in the cycloneDX specificationYes
Minimal cycloneDX versionAllow import of SBOMs based on a minimum cycloneDX version.Yes
DependenciesEnsure a "dependencies" array exists within the cycloneDX SBOM and that each component in the components array has at least one corresponding dependency relationship.Yes
VulnerabilitiesEnsure a "vulnerabilities" array exists within the cycloneDX SBOM. This includes checking for a unique identifier, such as CVE, exists for each vulnerability, more commonly known as the Vulnerability Disclosure Report (VDR) . As well an "analysis" object, more commonly known as the Vulnerability Exploitability Exchange (VEX) .No
spdx allowedAllow import of SBOMs in the spdx specificationYes
Minimal spdx versionAllow import of SBOMs based on a minimum spdx version.Yes
RelationshipsEnsure a "relationships" array exists within the spdx SBOM and that each package in the packages array has at least one corresponding dependency relationship.Yes

SBOM Analysis

When importing any SBOM with an enabled SBOM policy a user will be able to review results via the Analysis section in the project summary page. Navigating to any SBOM import will bring you directly to this page.

Each analysis will result in a pass, fail, or neutral result as follows:

  • Pass - All attributes meet the criteria defined in the SBOM policy
    • Denoted by a green checkmark
  • Fail - One or more of the attributes in the SBOM are in violation of the SBOM policy
    • Denoted by a red X
  • Neutral - Attribute is not required by the SBOM policy
    • Denoted by a grey hyphen

🚧

SBOM Policy to SBOM Analysis

Please note the attributes in the SBOM policy may inform more than one attribute in the SBOM analysis. For example the "vulnerabilities" attribute in SBOM policy informs the "Includes vulnerability" , "Includes unique vulnerability ID", and "Vulnerablility analysis state(VEX)" attributes.

📘

SBOM Issues

Please note, unlike other FOSSA policies, the SBOM policy does not directly create "Issues" in FOSSA and only informs the "SBOM analysis". This means an issue scan is not necessary to obtain updated results when changing SBOM policies.