Add check for published sboms

[ashearin]

Is your feature request related to a problem? Please describe.
Recent zero-day vulnerabilities and the resultant WH executive order regarding cybersecurity are making sbom generation an increasingly important part of building/delivering a secure software product. There are a few different standards being created regarding where to publish an sbom for your product, making a check though scorecard more feasible.

Some of the standards we're seeing:

• Project release artifacts (github/gitlab)
• security insights 1.0.0 spec
• sbom-everywhere naming and directory conventions

Describe the solution you'd like
Adding a check for the mere existence of a published sbom in any of the standard locations listed above would be a great initial step to sbom support. Gives room to grow into more sophisticated checks surrounding sbom content/quality in the future.

There have been community members interested in the implementation and contribution of this feature, namely myself and Daniel Appelquist.

Additional context
Potential (-ly forgotten) duplicate: #1476
Related to: #2605

[idunbarh]

@torgo CC

[evverx]

There are a few different standards being created regarding where to publish an sbom for your product

Open source projects aren't products. Products are assembled by vendors and it would be great if more vendors provided SBOMs covering their products indeed.

Adding a check for the mere existence of a published sbom in any of the standard locations listed above would be a great initial step to sbom support

I think I've taken a look at all the issues here related to SBOMs one way or another and I'm curious what sorts of products people actually build if SBOMs generated by upstream open source projects make any sense. Given that projects responsible for, say, low-level infrastructure can be consumed and deployed in a gazillion different ways none of which can be controlled upstream my guess would be that it targets certain ecosystems where it probably makes sense to blindly take SBOMs from GitHub. If so I wonder what kind of projects are implied here?

[idunbarh]

The primary reason for this feature request is to drive consistency within OpenSSF efforts for SBOM guidance and ScoreCard checks.

• OpenSSF SBOM Everywhere SIG - SBOM Naming Conventions (Draft)
• OpenSSF Security Insights Spec - 1.0 release

This check would be for source/build sboms but not the content, and the conventions listed above make it machine discoverable.

The SBOM Everywhere SIG is also working a strike team proposal to go work with open source projects on SBOM adoption. I think getting a Scorecard check created allows OpenSSF efforts to track the impact.

There is a chicken/egg situation for SBOMs.

• No one can automate finding them, because there are no conventions for where to find them.
• Conventions can't be widely adopted without tooling.
• All of these can't be measured to see how impactful it is without conventions and tooling.

The first step in getting to an automated solution for discovering SBOMs is having known locations. OpenSSF SBOM Everywhere SIG and OpenSSF Security Insights provide recommendations. Next steps are to work with tooling and provides and educate developers. ScoreCard helps educate users and also allows measurement of success.

We're happy to contribute the feature and wanted this issue to start the discussion.

[evverx]

This check would be for source/build sboms but not the content

I think source SBOMs were discussed in #1476 (comment) and it didn't go anywhere. Build SBOMs can be provided only by projects that are built upstream and a lot of projects release tarballs consumed and built elsewhere and those projects have no control over that process.

The SBOM Everywhere SIG is also working a strike team proposal to go work with open source projects on SBOM adoption

I saw https://github.com/ossf/sbom-everywhere/pull/27/files and I think it's a good idea.

I think getting a Scorecard check created allows OpenSSF efforts to track the impact.

I think it makes sense but I look at it from projects' point of view and I'm concerned that this check can lead to weird side-effects like semi-automated PRs improving scorecard scores where it doesn't make any sense. There are projects where it doesn't make sense to generate SBOMs upstream and it would be great if scorecard could detect that and say that SBOM aren't applicable there or something like that.

[idunbarh]

I'm concerned that this check can lead to weird side-effects like semi-automated PRs improving scorecard scores where it doesn't make any sense.

Totally agree on this concern. my thought would be to approach this incrementally with future refinements. I think getting NTIA minimum fields makes sense, but thats a very USA centric view of the world.

Philosophically does it make more sense to have a incremental improved SBOM check that starts with its existence?

There are projects where it doesn't make sense to generate SBOMs upstream and it would be great if scorecard could detect that and say that SBOM aren't applicable there or something like that.

Make sense, interested in getting this defined to drive consensus.

[evverx]

Philosophically does it make more sense to have a incremental improved SBOM check that starts with its existence?

I'm not sure. I think it's kind of based on the assumption that open source projects are consumed directly with no patches on top with no vetting and it's generally possible to map every project to exactly one place where it can be downloaded and I'm not sure it's universally true. There are ecosystems where it can probably work but it depends.

Generally I'm not sure why upstream projects should generate SBOMs because consumers/downstreams are usually better equipped to do that as they see fit.

[evverx]

What's weird is that according to https://openssf.org/blog/2023/11/17/securing-the-software-supply-chain-report-recommends-sbom-consumption-practices-for-critical-infrastructure-providers/

OpenSSF Scorecard is reporting SBOM presence as one of the checks

It isn't the first time non-existent features have been announced there but it would be great if it could be either corrected or point to a place with more details.

[github-actions]

This issue is stale because it has been open for 60 days with no activity.

[github-actions]

This issue has been marked stale because it has been open for 60 days with no activity.