-
Notifications
You must be signed in to change notification settings - Fork 239
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
🔌 Plugin: CycloneDX SBOM #234
Comments
any one wants to take a stab at this? |
Hi @testn this is currently open for grabs, would you like to be assigned? Unfortunately, I don't have the time at the moment, just wanted to throw the idea out there to see if there was any interest/feedback. Docker now actually has a sbom plugin that generates a CycloneDX SBOM in JSON. Felt this plugin would come in handy to visualize the SBOM report at the component level. The cyclonedx-javascript-library looks to provide a JSON normalizer, that supports all shipped data models with an example |
Hi there. If you want to use custom properties in CycloneDX, then you might want to register your namespace here: https://github.com/CycloneDX/cyclonedx-property-taxonomy/ |
I did some work on a proof-of-concept CycloneDX plugin back in early 2022 before much tooling existed for CycloneDX, I'll see what I can contribute back and if it's still relevant but my approach/ideas on a plugin can be summarised below: SBOMs are living documents that should be updated regularly, so they should be linked to rather than captured within a component yaml. They could be stored within a repository such as https://github.com/CycloneDX/cyclonedx-bom-repo-server or potentially within VCS alongside the code, For my initial attempt I just got it working with harvesting from Git using the default URLReader and relying on the established auth mechanism. I added a tab on each software component page to summarise some of the information contained within an SBOM, e.g. loop through the dependencies and list the number of each license within the SBOM etc, but with the CycloneDX library mentioned there could be a more informative/browsable UI. Some inspiration for the UI could be taken from plugins like https://github.com/backstage/backstage/blob/master/plugins/fossa/README.md or https://github.com/snyk-tech-services/backstage-plugin-snyk/blob/main/README.md as similar information may be contained in the SBOM. |
@DJDANNY123 Would love to see what you built so far, I agree that sboms are living/always changing documents and pulling from git is definitely a great start, given sboms are generated during build time, was thinking it would great to be able to post the sbom report similar how the code-coverage plugin accepts a coverage report. |
Had a meeting yesterday to progress getting permission from third party to open source this. Waiting for formal confirmation from them to release it. That being said I think I would want to rewrite some of the work I did to use the library above to process the SBOM rather than manually decode it using the JSON schemas etc. I was also returning the entire SBOM to the front-end which is probably not the approach I'd like to take, as it would be good to process that on the backend and then return the extracted information on the frontend, or get data from a report as well as a raw SBOM, do you have an example of any existing SBOM report data structures? |
Agreed, here are some SBOM sample reports @jkowalleck would you happen to have any samples using the latest 1.4 spec? The cyclonedx-javascript-library also has a example of how to serialize a SBOM to JSON here Let me know if you would like to be assigned to this one! |
Ah maybe I misunderstood the terminology of 'report', I was viewing there would be a raw SBOM which is based on the CycloneDX standard, or a 'report' which contains a more minimal representation of the information contained within this, such as a list of licenses, vulnerabilities etc. I was thinking the backend component would retrieve a full CycloneDX SBOM and process this in the backend to a more minimal JSON structure or 'Report' that provides information extracted from the SBOM (e.g. metadata, list of contained licenses, vulnerabilities etc.) to be displayed in Backstage in addition to a link to the raw SBOM. I don't know if there are other services that produce/expose the processed information from an SBOM or a format around this which we could also use, but maybe thats beyond the scope of a CycloneDX plugin. |
if it might help you, there is now a list of CycloneDX guides : https://cyclonedx.org/guides/ |
SPDX support could also be important. If SPDX support is somehow easier to get, I'd be happy to have it first. |
Regarding the storage location for the SBOM (in CycloneDX, SPDX or any other format), it could make more sense to store it as an OCI artifact alongside the container images (ORAS can be used to attach supply-chain artifacts to container images). Indexing all SBOMS would also be great for searching. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
@BethGriggs you closed this by referring to it in a list, how does it address the issue? The close resolution is not clear, I'm new to the topic and was wondering if I can use Backstage to render my SBOMs |
I did not close this issue, the stalebot did:
#1229 was opened to track historic plugin requests. |
I am not sure I understand what would the objective of the plugin? Would that be an annotation handler at As part of the SCA concerns, I guess it make sense to have per component a SBOM but not sure of the exact way to create the most value out of the SBOM inside Backstage vs referring to a third party service like DependencyTracker, Aikido .... Keen to chat about it |
Suggesting a plugin to display a CycloneDX Software Bill of Materials (SBOM) Composition Report. CycloneDX is a commonly used standard across a number of tools that supports both JSON and XML schemas.
CycloneDX is the SBOM format created by the Open Web Application Security Project (OWASP) and was built with cybersecurity in mind. The largest benefit of CycloneDX is the ability to include vulnerability information in the SBOM or link to a separate Vulnerability Exploitability Exchange (VEX) which lets you indicate false positives alongside component vulnerability information. The schema also supports a Package URL (PURL) which standardizes how software package metadata is represented so that packages can universally be located regardless of what vendor, project, or ecosystem the packages belongs to.
Thinking the plugin will work similar to the dependency-track plugin
metadata: annotations: backstage.io/sbom: enabled
A tab called SBOM to be shown at the component, system and even resource level with sub tabs with the SBOM provider name i.e Sonatype, syft or any tool that supports the Cyclone specification standard.
CycloneDX/cyclonedx-javascript-library#215
Unfortunately i don’t have time to contribute right now but wanted to throw the idea out there and get feedback from the community!
The text was updated successfully, but these errors were encountered: