Feature: Detect if SBOMs generated

[david-a-wheeler]

Is your feature request related to a problem? Please describe.

Past problems, including the
log4j vulnerability Log4Shell, have made it abundantly clear to many people that it's important
to be able to quickly figure out what is included in some software.
It's be good to be able report on whether or not a project provides a software bill of material (SBOM),
because that tells potential users that the developers are trying to help by providing this info.
We might even look at the White House Executive Order on Cybersecurity to see
if there are other things projects could provide to help users respond to a problem.

Describe the solution you'd like

Detect if SBOMs are present for all the dependencies in use.
I'm sure there are many options, let's talk about those in the comments.
I just want to record the idea so we can discuss it.

[surendrapathak]

@david-a-wheeler I am interested in this feature for a set of open-source tools we are building to improve the current state of available SBOMs (Quality scoring tool sbomqs released, others in the pipeline).

For our needs, we need a set of conventions for :

1. Declaring if a project builds/signs SBOMs and declaring tools, format, and location of the generated SBOM
2. Guidelines for the use of the generated SBOM (considerations for inaccuracy in generation tools or component drift)
3. Method applied towards checking the accuracy of SBOM (if any)

I suspect there are other considerations, such as how the presence of an SBOM interacts with existing Security policies / Advisories.

Please let me know where I can follow the discussion on this feature, and I am happy to participate as well.

[david-a-wheeler]

Hmm, larger questions.

I think the SPDX community would be the right place for that, and similarly the CycloneDX developers for that.

@kestewart - can you tell us more re: SPDX?

For some of the declarations that may be more a work in progress. I think SLSA, S2C2F, and security-insights.yml might be relevant OpenSSF projects at least.

There's a paper about-to-be-released that talks about different types of SBOMs (e.g., source SBOMs vs. build SBOMs and so on).

[stevespringett]

There's going to be a lot of commonality on how SBOMs are generated irrespective of format. For example:

• Integrated into build manifest (pom.xml/parent pom, package.json, webpack config, etc)
• Integrated into build processes (GH actions, Circle CI, GitLab runners, Jenkins, etc)
• Non-integrated standalone tools (Syft, MS tool, JBom, etc)

IMO, there are too many variables to be able to capture all possible ways SBOMs are generated. What we may want to focus on is not whether or not its generated, but whether or not its published.

Would could theoretically identify publishing to:

• Package repositories (Maven has a standard, OCI, npm.js, etc)
• SBOM saved by build process (saved artifacts from GH Actions, Jenkins, etc)
• SBOM artifact that is included in a GH release

Both CycloneDX and SPDX have conventions, so I think it would be easy to write something to identify the existence of files that meet those conventions to determine if the project produced an SBOM or not.

My two cents.

[david-a-wheeler]

@stevespringett - I completely agree, focusing on SBOMs that are published is what matters, and there are already existing conventions. I think it's okay to start with a few common conventions, then expand as we learn of others if they become common and/or recommended.

[behnazh-w]

It would be great to detect that SBOMs are published, but we also need to be able to verifiably link them to the published artifact. That could be something that the SLSA provenances generated by the same release pipeline can attest to.
cc @laurentsimon

[laurentsimon]

re: SLSA-attested SBOMs: We're working with anchor for this @wagoodman and we have a SLSA3-compliant sbom builder PoC at https://github.com/laurentsimon/sbom-action/blob/feat/slsa-trw/.github/workflows/slsa3.yml

[david-a-wheeler]

Note: this is related to issue #2605

[surendrapathak]

FWIW - There is very little SBOM present in repositories and very little consistency in where in the repository it is being published: https://docs.google.com/spreadsheets/d/1Ok4JupcLrTvoLbaIJ0wSfD7wKx6hgE5V1SQrqfRyPss/edit?usp=sharing

IMHO, SBOM can be thought of representation of a specific state of the main and/or a part of a release and, therefore, a convention for path in both the branch (e.g., .sbom/<package>/sbom.<format>) and the release page(e.g., releases/download/<version>/sbom.<format> could be a reasonable start.

[laurentsimon]

I don't expect SBOMs to become prevalent in repositories (even for their releases), since most repositories are libraries with unresolved library versions.

What are the applications of SBOMs for a main branch? Is it to cover binaries present in the repo or for the source code itself?

[naveensrinivasan]

I don't expect SBOMs to become prevalent in repositories (even for their releases), since most repositories are libraries with unresolved library versions.

What are the applications of SBOMs for a main branch? Is it to cover binaries present in the repo or for the source code itself?

👍

[surendrapathak]

I don't expect SBOMs to become prevalent in repositories (even for their releases), since most repositories are libraries with unresolved library versions.

Agree. However, it is worth keeping in mind that majority of conventions naturally gets copied over to closed source ecosystem as well. Therefore any convention developed here help OSS tools such as scorecard as well as other commercial tools look for SBOM in a consistent location across both open and closed repositories.

What are the applications of SBOMs for a main branch? Is it to cover binaries present in the repo or for the source code itself?

It's to cover the source code. A typical development pattern is to keep main branch up-to-date with changes reviewed and approved for upcoming release. This is equivalent to "pre-build SBOM" as suggested in Software Supplier Playbook: SBOM Production and Provision.

The generation of the source-level SBOM (“pre-build” SBOM) can be part of a version control system or can be created by tools that mine the inputs to the product-build pipeline. Effective hashing of the source files (and hashes of any binaries) that go into a build pipeline is useful for ensuring the identification of key components. This is most important when looking for vulnerabilities before a product has been created.

So SBOM on main can be a good source for risk assessment on the source and compliance while SBOM with releases can be a good source for new vulnerability assessment against released products.

[laurentsimon]

Thanks for the info. My worry on the source SBOM is that it's additional work for maintainers, will require pre-submit / tooling, and often times it provides little to no benefits to existing manifest files already present in source code - package.json, etc. From a maintainer's perspective, this feels like duplicate work. Source-code manifest files are already used for vuln scanning and work well (except for certain ecosystems - see https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/using-the-dependency-submission-api).

I understand these manifest files don't cover other information like license information, but arguably this could be handled by other tools.

I'm not against source code SBOMs, but it would be useful to understand its benefits and the usability implications for maintainers.

Some high-assurance and safety-critical use cases may require traceability from the build to the source-file level; having an SBOM of the source code, associated data, and artifacts incorporated in the build may be required Effective hashing of the source files (and hashes of any binaries).
This feels like SLSA to me. What are the overlaps?

[surendrapathak]

I should clarify. My expectation is to see a set of conventions around publishing SBOM for main and releases only if the project is interested in publishing those SBOMs. I completely understand that it is added maintenance, and it is likely that some, if not most, projects do not get to that in the near future (and as you mentioned, some of the underlying data is decipherable with manifests).
I am not very familiar with scorecard requirements but If the scorecard inclusion requires SBOM generation, then it is likely to run into adoption challenges. But from David's original description of the issue, I assume we want to get to a state of 'recommended' not 'required' state.

[laurentsimon]

But from David's original description of the issue, I assume we want to get to a state of 'recommended' not 'required' state.

If we're able to tell that a project is an "application", then this works fine. This is not always obvious, is my worry... and it could lead to a lot of false positives. I'm open for suggestions how to tackle this

[laurentsimon]

I think we need a way for scorecard to indicate "something to look at / think about", instead of a results that penalizes projects. Today. I think we could do that thru an Info:, even though that's for positive things and users may miss it in the results unless they look closely (it would not be reported by the SARIF integration with GitHub dashboard).

As part of the work on #1874, I'll keep this in mind that we need a better way to indicate more than just "positive", "negative" results.

Any ideas / feedback on what we could call this kind of results? "recommendation" still feels like we're asking users to do something.

[surendrapathak]

I think we need a way for scorecard to indicate "something to look at / think about", instead of a results that penalizes projects.

That's exactly it! I wasn't aware of Info: part but something along those lines would make sense if no sbom is found in 'expected' locations.

Any ideas / feedback on what we could call this kind of results? "recommendation" still feels like we're asking users to do something.

Thoughts on 'Voluntary' / 'Desirable' / 'Preferred' / 'Improvement'?

[varunsh-coder]

I have created an issue at secure-repo to transform specific GitHub Actions workflows/ configuration files to generate SBOM. Many maintainers use secure-repo to apply security best practices to get a higher Scorecard score. The SBOM related issue has two easy scenarios 1. build-push-action, which supports a sbom attribute, and 2. goreleaser config which also supports a sbom section.

Please let me know if you have any feedback about this.

[github-actions]

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