Software Bill Of Materials (SBoM) Vision - Secure and Protect - Software and Container Dependencies
Software Bill Of Materials (SBoM) Vision - Secure and Protect - Software and Container Dependencies
- Product Category Vision Page
- Secure Vision Page
- Secure Maturity NOT A CATEGORY
Goal: Shared understanding of needs, expectations, and scope for the SBOM work.
What is SBOM?
A Software Bill of Materials is a list of all the things that went into a software package.
An SBOM is an output of various processes that assess a project which can be a combination of provided and detected components.
Nicole’s POV - An SBoM itself does not make you more secure, generally it is required as a compliance element, however the process of creating an SBoM involves evaluating all of the things within your project. This process of discovery and evaluation does generally make you more aware of the risks within your project, as well as gives you a list of things to check for known issues, and can make you more secure as a result of this process.
There are many SBoM formats, we today have our own format (https://xkcd.com/927/) that we will continue to have (but may change) but we plan to allow export in SPDX to start and then CycloneDX in the near future.
What categories and groups will be impacted by sbom?
Today the SBoM includes the items discovered using dependency scanning and license compliance. Very soon container components will also be included from container scanning.
What is the long term vision?
Users of GitLab will create an SBoM artifact for all detected application dependency and container components, and also include provided data, as a release artifact with each build where it is requested or required. This file will be part of the software package for future reference and assessment of the software at various points in time (versions).
Users of GitLab will also be able to view, search, and export the current detected components for a selected branch. Notes about further information (security or compliance concerns) will be visible here and will allow users to go to the correct location to find out more.
CycloneDX + Containers?
What is our current scope-
Include Containers into Dependency list - Current plan is to rename the Packager column to “Source” and include the Container Scanning packages in the existing list. Protect:Container Security will do this work -
Export to CycloneDX for dependency scanning - Export to Cyclone DX for containers
- Short TTL (auto cleanup). Can users auto adjust build artifact ttl today?
Next
Reduce Noise
- How to reduce noise with both container scan and dependency scan results
Database
- enable future features
useability improvements
-
UX to decide if we need to add a tab or filter to differentiate containers vs not [iconography added] - Clarity on what is included: Users get very confused (understandably) about what is included here - i think we should enable a way to make it clearer (i.e. unmerged vs merged which branch what specific timestamp etc etc?) where do we say this? How do we summarize? Where and how do we allow them to get more specificity if desired? From comments below also look into note-ing if it’s from package manager vs file scan etc (may need to move this to a backlog issue for DS not sbom)
- Pipeline selection
- Allow / add Search (
Package name (59 74.9%)
,Version (32 40.5%)
,License (15 20%)
,Vulnerabilities (10 12.6%)
andRelated/Nested Dependencies 8 (10.1%)
) - Allow / add Filter [scanner, source, introduced or upstream etc]
- Enhanced grouping choices
- download all sbom by project (compressed file)
- download all sbom by selected scope (compressed file for group / namespace etc)
Namespaces migration
- Prep for Workspaces
Workspaces adoption
- Allow Group/SubGroup/Workspace view/aggregation (search etc works here, need to add “projects/groups/etc” column of some sort)
Later+
- Allow / enable automatic creation of a specific sbom (i.e. ours or spdx or in future others) on specific builds (tag? Branch? variable?)
- Allow putting as release artifact
- Allow export of SPDX (with loading pattern). We need to enhance the export today which is just our format, we need to let them pick SPDX or ours (and in future, others too)
- Clearly mark dependencies introduced/direct vs transient/indirect and which are vulnerable. And allow grouping by above
- Provide some policy info and link out
- Provide some vuln info and link out to vuln list
- Signing of SBOM
- Allow adjustment of TTL
- Allow marking out of test/qa/dev dependencies
- Allow marking out of transitive dependencies
- Allow pointing at lock files of specific formats for inclusion (no build). Need to allow add / remove (bulk) and conditions to be considered
- Allow inclusion (import) of SPDX from upstream. Need to allow add / remove (bulk) and conditions to be considered
- Allow inclusion (import) of cycloneDX from upstream. Need to allow add / remove (bulk) and conditions to be considered.
- Allow alternate branch other than main/default
- Allow enforcement by rules I.e. all builds with this tag or branch must generate etc Look at SPIFFE and SPIRE and in-toto
- Scheduled creation. Related-ish: enhanced policies related to dependencies and licenses and warnings (visual) of deviation and allow comments on deviations
What work is needed for the current scope?
- What does the new Dependency List look like?
- Should we call it a dependency list or an sbom?
- What changes are needed on the policy list and vuln list to accommodate that?
- Are changes needed on the container registry (and are they planned)?
- Can we also do the same for the “sooner” bucket? Without too much extra
- Can we validate the page with users?
SBOM further reading:
- https://www.ntia.gov/SBOM
- https://github.com/spdx
- https://www.linuxfoundation.org/blog/generating-a-software-bill-of-materials-sbom-with-open-source-standards-and-tooling/
- https://cyclonedx.org/
- https://csrc.nist.gov/projects/software-identification-swid/
- https://www.openchainproject.org/
- https://fossa.com/blog/software-bill-of-materials-formats-use-cases-tools/
- https://cyclonedx.org/tool-center/
Related to sbom issues and epics:
- &858 (closed)
- https://gitlab.com/groups/gitlab-org/-/epics?label_name[]=Software%20Bill%20of%20Materials%20(SBoM)
- https://gitlab.com/gitlab-org/gitlab/-/issues?scope=all&state=opened&label_name[]=Software%20Bill%20of%20Materials%20(SBoM)
- gitlab#218517 (comment 427965209)
- gitlab#218521 (comment 427964876)
- gitlab#321183 (comment 608479525)
- Show closed items