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 Field | Description | Scope | NTIA minimum |
|---|---|---|---|
| SBOM Author | Author who created the SBOM itself. This may be an individual, organization, or SBOM creation tool. | SBOM metadata | Yes |
| Creation Timestamp | Date and time the SBOM was created | SBOM metadata | Yes |
| Name | Name of the SBOM element (package, file, library, etc.) | Component metadata | Yes |
| Version | Version of the SBOM element (package, file, library, etc.) | Component metadata | Yes |
| Supplier | Supplier of the SBOM element (package, file, library, etc.) This may be an individual, organization, or technology such as package manager or registry. | Component metadata | Yes |
| Package URL (PURL) | A unique identifier used to fully identify packages including type, namespace, name, version. Please see the full PURL spec for additional details | Component metadata | No |
| 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 details | Component metadata | No |
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 Field | Description | NTIA Minimum |
|---|---|---|
| cycloneDX allowed | Allow import of SBOMs in the cycloneDX specification | Yes |
| Minimal cycloneDX version | Allow import of SBOMs based on a minimum cycloneDX version. | Yes |
| Dependencies | Ensure a "dependencies" array exists within the cycloneDX SBOM and that each component in the components array has at least one corresponding dependency relationship. | Yes |
| Vulnerabilities | Ensure 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 allowed | Allow import of SBOMs in the spdx specification | Yes |
| Minimal spdx version | Allow import of SBOMs based on a minimum spdx version. | Yes |
| Relationships | Ensure 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.
Updated 2 months ago