Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stage 2 criteria for available SBOM #173

Open
mxmehl opened this issue Dec 10, 2024 · 4 comments
Open

Stage 2 criteria for available SBOM #173

mxmehl opened this issue Dec 10, 2024 · 4 comments

Comments

@mxmehl
Copy link
Member

mxmehl commented Dec 10, 2024

When working on the security requirements for stage 2, I noticed that - to my knowledge - we didn't speak about SBOMs so far.

Would it make sense to ask stage 2 projects to provide sufficient SBOMs, at least for each release? Our own compliance-assistant is able to produce good results which also contain sufficiently OK licensing information.

We already have some related documentation on this for the licensing review: https://github.com/OpenRailAssociation/technical-committee/blob/main/project-handbook/license-review.md

/cc @cornelius @flomonster

@flomonster
Copy link
Contributor

What's the objective behind it?
Here we talked about having a process to detect vulnerabilities automatically. It could be done using an SBOM or other.

@mxmehl
Copy link
Member Author

mxmehl commented Dec 11, 2024

You raise a good point. However, more and more organisations are interested in having SBOMs for the software they use, and interest will increase with CRA and similar regulations. Thanks to OpenRail projects being Open Source, one can create this SBOM themselves. However, if the project already provided a well-crafted (and ideally tested) SBOM, this benefits at least the users.

Also see this Sonatype article:

Increasingly, SBOMs are a necessary element of deliverables. For example the recent guidance for developers from the National Security Agency (NSA), Cybersecurity and Infrastructure Security Agency (CISA), and the Office of the Director of National Intelligence (ODNI) recommended that producers of open source projects provide an SBOM as a mitigation and assurance of good development practice. Simply, by providing an SBOM in your repository, you make a good-faith gesture that helps a user efficiently verify and vet your project.

In short, dependency scanning as implemented in #174 rather works internally, while SBOM generation and publication works externally.

@cornelius
Copy link
Member

It's worth noting that technically we already have a SBOM for all projects we host on GitHub via the GitHub generated dependency list, e.g. https://github.com/OpenRailAssociation/osrd/network/dependencies. If this is well-crafted is up for discussion and it's certainly not tested.

@cornelius
Copy link
Member

Conclusion from TC meeting: Put it in the release requirements as recommendation for stage 2 and a requirement for stage 3. To be documented in #144.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants