Software Bill of Materials
- Robert Heinemann
Team Members
Where in the current ONAP Release Package should Software BOMs be placed?
We looked at the structure of releases. There isn't a bundled release per se. In other words there isn't a single archive that contains all the code / binaries for a release like Casablanca or say Honolulu. Each release is by project. So current thinking is that a BOM should be created per project. and included in the GitHub repo.
What is the structure of the Software BOM?
NTIA Software BOM References
| 1 | Landing Page | https://www.ntia.doc.gov/SBOM |
| 2 | NTIA Software Component Transparency | https://www.ntia.gov/SoftwareTransparency |
| 3 | Software Identification Challenges and Guidance | https://www.ntia.gov/files/ntia/publications/ntia_sbom_software_identity-2021mar30.pdf |
| 4 | Comments on Software Bill of Materials Elements and Considerations | https://www.ntia.gov/other-publication/2021/comments-software-bill-materials-elements-and-considerations |
| 5 | The Minimum Elements for a Software Bill of Materials (SBOM) | https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom |
| 6 | SBOM Formats | https://www.ntia.doc.gov/files/ntia/publications/ntia_sbom_formats_and_standards_whitepaper_-_version_20191025.pdf |
How do we generate the Software BOM?
Our first step in determining this was to try to understand the current CI/CD infrastructure. With that in mind we met with Jessica Gonzalez on 8/26/2021 to understand the LFN build chain and the Nexus products. During the tour of the different components involved there appeared to be two files included in every build that may have the information we need to generate a software BOM. Those are the INFO.yaml and pom.xml files.
POM files are XML files used for maven and they contain details about dependencies.
INFO.yaml files provides information for anyone that is interested in the repository. In the INFO.yaml contains specific information to the main PTL, committers with contact details, meeting information and real time communication and list of repositories under the same control.
Committer Management Automation via INFO.yaml - Developer Wiki - Confluence (onap.org)
Jessica also suggested that we should reach out to Kenny Paulto discuss further and solicit his thoughts on what we are trying to accomplish.
As part of the build infrastructure Jessica called out Nexus 2 for Java Artifacts, Nexus 3 for Docker image delivery, NEXUS IQ for dependency scanning and Sonar cloud for code scanning.
According to this sonatype Blog "Nexus Vulnerability Scanner" already creates a BOM
If you’re not already creating SBOMs, and want to see what’s inside your application, start by using our free service, the Nexus Vulnerability Scanner, to generate one for your application.
Creating an SBOM and knowing what’s in your applications is the first step to better understanding what open source and third party components have been flowing into and through your software supply chains. --Why You Need a Software Bill of Materials More Than Ever (sonatype.com)
(From Muddasar Ahmed )
I think we can get a BOM report in Cyclone SDX format from Nexus, depending on the feature bought by ONAP. Still need to figure out “How to”.
Also there are other options from open source.
https://spdx.dev
https://spdx.github.io/spdx-spec/1-rationale/
https://spdx.org/licenses/
https://cyclonedx.org/tool-center/
https://github.com/CycloneDX/cyclonedx-maven-plugin
Supports Cyclone DX format
https://www.globenewswire.com/en/news-release/2021/05/13/2229342/22212/en/Sonatype-Embraces-CycloneDX-Standard-for-Integrating-Software-Bills-of-Materials-SBOMs.html
Sonatype NVS (Nexus Vulnerability Scanner)
https://www.sonatype.com/products/vulnerability-scanner-upload
https://github.com/flexera/sca-codeinsight-reports-project-vulnerabilities