[Proposal] SBOM Guidance for Cloud Native

[pxp928]

Description:

SBOM Guidance for Cloud Native

The goal of this proposal is to figure out the who, what, when, where and why for how SBOMs will be used in the cloud native space. Analyze the current SBOM formats to see if there are any gaps that need to be addressed.

Proposal:

• Who is our target audience (cloud vendors and end users) and what are their requirements and needs?
• Who, Where and how should we generate the SBOM (before compile or after image build)
• What should be included in the SBOM (code only, runtime environment, compiler environment, SaaS/cloud environment)
• How do we use the SBOMs (vulnerability scanners, ability to query for a package throughout the environment)
• When is it safe to delete the SBOM, is there a need to retain even after the image is removed from the registry for later auditing?

Note: SBOM distribution and signing are being discussed in the sigstore community.

Impact:

There needs to be a push to standardize the SBOM for the open-source community. Answering the questions in this proposal will help cloud native adoption of SBOM generation in more standard format.

Deliverable

A position paper that answers the above questions. This can be used by cloud native organizations for how they either need to produce or consume SBOMs.

Project Schedule

• 1 month for initial draft (gather information from vendors and end users)
• 1/2 month for peer review (comments/feedback)
• 1/2 month for revision and final document release (address comments and final release)

TO DO

• [x] Security TAG Leadership Representative: @lumjjb
• [ ] Project leader(s):
• [ ] Project Members:
• [ ] Fill in addition TODO items here so the project team and community can see progress!
• [ ] Scope:
• [x] Deliverable(s)
• [x] Project Schedule
• [ ] Slack Channel (as needed)
• [ ] Meeting Time & Day:
• [ ] Meeting Notes (link)
• [ ] Meeting Details (zoom or hangouts link)
• [ ] Retrospective

[sudo-bmitch]

I'd be interested in including the lifecycle of the SBOM too. Few things I'm thinking of:

• when and how should we generate the SBOM (before compile or after image build)
• what should be included in the SBOM (code only, runtime environment, compiler environment, SaaS/cloud environment)
• aggregating multiple SBOMs from different sources or producers
• how do we ship the SBOM (on an image registry? do we need to support non-container use cases)
• how do we use the SBOMs (vulnerability scanners, ability to query for a package throughout the environment)
• signing and providing authenticity of SBOMs from producer to consumer

Edit: Also when is it safe to delete the SBOM, is there a need to retain even after the image is removed from the registry for later auditing?

[pxp928]

I'd be interested in including the lifecycle of the SBOM too. Few things I'm thinking of:

• when and how should we generate the SBOM (before compile or after image build)
• what should be included in the SBOM (code only, runtime environment, compiler environment, SaaS/cloud environment)
• how do we ship the SBOM (on an image registry? do we need to support non-container use cases)
• how do we use the SBOMs (vulnerability scanners, ability to query for a package throughout the environment)
• signing and providing authenticity of SBOMs from producer to consumer

Agreed @sudo-bmitch . I will update the proposal to reflect this.

Other updates based on the meeting -

@nadgowdas - Determine how we can aggregate when multiple SBOMs are created. How can they be linked together for analysis and verification?

Apply this to a real project like Tekton which would create multiple SBOMs. Currently we have no method to aggregate them together for the project.

@hectorj2f - Use case with build packs having a SBOM per layer. Hector mentioned there is a tool to collect the SBOM from every single layer. @hectorj2f Can you link this tool you are using?

[hectorj2f]

how do we ship the SBOM (on an image registry? do we need to support non-container use cases)

We started a discussion at sigstore/cosign about a recommendation to ensure tamper-proof SBOMs, so users are aware of the suggested methods that ensure the authenticity of a SBOM. https://github.com/sigstore/cosign/issues/1742

[hectorj2f]

@pxp928 I am sharing a link to the current public repo https://github.com/sclevine/cnb-sbom. We have another internal version but it does not differ much from this implementation.

[stevespringett]

Many projects will create multiple SBOMs but currently there is no way to link or aggregate them to create the complete picture of the various components of a project.

Untrue statement

• The CycloneDX CLI can aggregate via a merge command
• CycloneDX BOMs can link to each other via BOM-Link

Possible of interest to the group is "SBOM" should not exist! Long live the SBOM where I argue that software alone is insufficient for BOM use case and that services and other types of components should be included.

I think some this work described in the ticket overlaps with what the OWASP Software Component Verification Standard (SCVS) is currently doing with designing a BOM Maturity Model. The basic premise is to provide orgs a taxonomy of things they may care about and provide them a way to measure and improve their maturity by taking advantage of more and more capabilities of the (S)BOM formats over time.

[lumjjb]

Next steps here @pxp928 is to fill in details of project (as follows) and discuss with STAG rep before sharing with community and getting next steps.

 Scope:
 Deliverable(s)
 Project Schedule

[puerco]

Many projects will create multiple SBOMs but currently there is no way to link or aggregate them to create the complete picture of the various components of a project.

SPDX can reference documents externally, Kubernetes Release Engineering SBOM tool has a beta feature in development to piece micro SBOMs together.

As @hectorj2f already mentioned, a lot of the answers to the questions regarding SBOM distribution and signing are being discussed in the sigstore community. Some of the answers to these questions deal with distribution/delegation of trust, expected artifact locations, tracking of build pipelines etc and, in my view, they go beyond the SBOM itself.

[pxp928]

Based on the comments and feedback provided by the community, I have changed the above proposal to be more condensed. Going on the route of what @sudo-bmitch proposed, it will now be more about answering some open question regarding SBOMs in cloud native space. Removing aggregation, signing and distributing as those are handled in other communities. Added deliverable and timeline based on this revised proposal.

[lumjjb]

Topics discussed during 06/09 meeting:

• Compliance questions around SBOMs (who is this enforcable on? etc.)
• Reliability and trustworthiness of SBOMS - How does this tie to concepts like SLSA?

[JonZeolla]

https://github.com/cncf/tag-security/issues/845 may also come into play regarding assessing whether or not an environment has/uses a SBOM, and how to present that information to the right people asking compliance questions (such as auditors or assessors)

[pxp928]

Comments based on 06/15 Meeting:

• Note distribution of OCI work, to be considered in the work
• NTIA minimum elements: have been expressed that this will increase in scope in the future. Min requirements for fedRAMP
• SBOMs is not linkable to what they are describing (i.e. hashes missing - make sure that its there - linking to the image in oci for example)
• SPDX discussing content chunks as first class elements with mandatory hashes

[brandtkeller]

I would be interested in participating in this discussion.

To (maybe) add a new perspective i was thinking about the intersection of these items:

What should be included in the SBOM (code only, runtime environment, compiler environment, SaaS/cloud environment)

How do we use the SBOMs (vulnerability scanners, ability to query for a package throughout the environment)

With something like the VEX format - which has already been shown to have the ability to be included inside or colocated with SBOM's.

[stale[bot]]

This issue has been automatically marked as inactive because it has not had recent activity.

[stevespringett]

For reference, the attached deck was presented at the CISA SBOM Cloud meeting last week. I believe that group is going to be defining SBOM use cases and guidance for cloud.

OWASP CycloneDX - SBOM Cloud.pdf

[stale[bot]]

This issue has been automatically marked as inactive because it has not had recent activity.

[mlieberman85]

Following up with @pxp928 on this. It might be worthwhile to include in some of the real world policy guidance work that @jkjell is working on.

[stale[bot]]

This issue has been automatically marked as inactive because it has not had recent activity.

[anvega]

Closing issue as this has been taken up by the Supply Chain WG as advancement of SBOMs evolves.

[sudo-bmitch]

@anvega are we tracking the progress on that somewhere?

[mnm678]

It might be nice for us to have a place to collect issues that are covered by the working groups. We generally work on one thing at a time, but open issues in the backlog (maybe tagged for the working group) would help with planning.

[anvega]

To answer the question, I'm not actively involved in the workgroup at the moment. It's really up to the WG how they organize. I only see minimal discussion here with a single update of what was discussed in a meeting over a year ago, so it's not being tracked here.

Maybe it’s time to create readme files in the directory for each subgroup with the meeting notes, calendar, slack channel, and a roadmap file.

We do this for the spiffe project:

https://github.com/spiffe/spiffe/blob/main/community/sig-spec/README.md https://github.com/spiffe/spiffe/blob/main/community/sig-spire/README.md https://github.com/spiffe/spire/blob/main/ROADMAP.md

To Marina's point, open issues in the backlog seem fine to be as long as there is an indication the issue is either being worked on or planned to be worked on. It is not uncommon workstreams often get reprioritized or punted at later time, but we end up with a large board of inactive issues. If a proposed workstream is not moving for a while and its just historic discussion, we should probably archived it by moving it as an entry to the readme doc or repo wiki as in the radar but not roadmapped work. Same goes if the aspiration from the proposal is more a static goal or outcome as a result of broader workgroup efforts.

[sudo-bmitch]

I'm okay with this being closed if there are no plans for the supply chain working group to work on this. I was just confused because the message above indicated that we were working on it when we aren't. If there are plans to have the supply chain working group take this up, then reopening and tagging the issue for the working group and in the backlog seems like a good way to track the progress while keeping it separate other TAG-Security work.

[anvega]

It would fall under the working group if it were to be worked on.