-
-
Notifications
You must be signed in to change notification settings - Fork 61
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
Add Steward to the CycloneDX specficiation #503
Comments
Thanks for the suggestion and references. Is a BOM spec the correct place to identify the steward of a project or package? I would think the Common Lifecycle Enumeration (CLE) would be a better place as the steward may change over time or different stewards may exist for different major versions of a project. Refer to https://docs.google.com/document/d/1sRMS1IX0r7ZkYthDR0VY1bYyvp_6K_xw4sR1vZwla8E/edit for details on CLE. |
Thanks for the suggestion, Steve. Different stewards do present a challenge. I had in mind the idea that a steward.md file in the repo could be updated from time to time and when an SBOM is produced (hopefully) scanners would pick up the current steward listed in that file. But, you are correct that it doesn't solve for a steward that changes post-distribution. |
@Pizza-Ria where does this idea of a |
@jkowalleck The idea stemmed from other metadata markdown documents that I regularly utilize in open source repos like Notice.md. It doesn't currently exists (to my knowledge) but it would be an easy way for a person/entity to indicate that intent. If one no longer wishes to claim that responsiblity then they could file a pull request to be removed. |
Add Steward to the CycloneDX Specification
This is a suggestion to add a field in the specification to indicate if there is a steward (see, EU-CRA - Article 24 and https://linuxfoundation.eu/cyber-resilience-act for context) for the project. Ultimately, collection of this field (especially for automted scanners) may depend on an ecosystem adoption of a steward.md file within a repo so this field can be easily identified. There is a parallel issue filed with the SPDX standard at spdx/spdx-3-model#855.
Thank you!
The text was updated successfully, but these errors were encountered: