chore: add sbom generation and upload workflow #470
Conversation
Adds stand-alone workflow to automatically generate and publish an SBOM following a GitHub release (release event). The workflow can also be triggered manually (workflow_dispatch event) for testing, or to generate SBOMs for previous releases. **Caveat:** When creating an SBOM for a previous release, the workflow checks out the repository at the corresponding tag. This means that the used SBOM schema version, bumped to 1.6 in the current patch, will be reverted back to 1.4. **Recommendation:** Move full SBOM configuration from pom.xml to the command line invocation in the workflow file added in this patch, to avoid surprising behaviour. NOTE: The existing execution goal in pom.xml does not seem to work (see "Skipping CycloneDX goal, because module skips deploy" in build logs of recent releases). Please reach out to the security team for assistance! Signed-off-by: Lukas Puehringer <lukas.puehringer@eclipse-foundation.org>
|
We agree with fully transitioning to this approach for generating SBOMs. Up until now, our SBOMs have been stored in the Maven repository. In our view, it is not ideal to maintain this information in two different locations. Therefore, we propose to remove the SBOM plugin configuration entirely from our build and rely solely on generating SBOMs through the provided GitHub Action. |
Great! Happy to update the PR. |
Removed CycloneDX Maven plugin configuration from the POM file, including its executions and associated settings.
| <outputReactorProjects>true</outputReactorProjects> | ||
| <outputFormat>all</outputFormat> | ||
| <outputName>Eclipse-Store-Sbom</outputName> | ||
| <outputDirectory>${project.build.directory}/sbom</outputDirectory> |
There was a problem hiding this comment.
The workflow expects custom outputName and outputDirectory defined here. So we need to pass it in the cli invocation in the workflow file.
There was a problem hiding this comment.
Note: Sticking to a custom path, instead of updating the workflow to use the default, allows us to run the workflow over previous tags, which would bring back the config in pom.xml.
There was a problem hiding this comment.
I’ve updated the workflow to pass the custom outputName and outputDirectory in the CLI invocation, so it now aligns with the configuration in the pom.xml. Could you please confirm if this looks good to you?
Thanks! I suggested some minor changes above:
With those it should work. I tried the patch (lukpueh@01b8c44) in my fork, to create test sboms for the main branch (without pom.xml config) and for the last release (which brings back the pom.xml config), and both succeeded. |
Co-authored-by: Lukas Pühringer <luk.puehringer@gmail.com>
|
Looks great to me! Thanks for the quick action |
|
Ok, after the merge I ran the action for the latest release 3.0.1. |
Thanks! You can browse the results at https://sbom.eclipse.org/projects/e8598e0a-02a6-4bec-bd11-922d407bbe92 |
|
There is also the question of what to do with the second related project, the Eclipse Serializer, which is used as a core component of the Eclipse Store project. Should we migrate it right away as well, or wait? Another question concerns the public availability of this data. Our initial goal was to provide potential users with a complete overview of the dependencies used through the SBOM. Now this option is hidden behind the Eclipse login – what is the plan going forward? |
Yes, by all means, please feel free to migrate Serializer as well! You should be able to just copy-paste the workflow (minus the dependency version patching, and with project/product names updated). We are more than happy to assist. Also, I will follow up shortly with a new Dependency Track parent project ID that you can use for Serializer.
That's a great question! We launched our DependencyTrack instance only recently and are in an early, experimental phase. Currently, we are facing technical constraints with regards to its public access. That said, we're committed to providing the best possible experience for users interested in exploring SBOMs, and we will definitely keep you posted, when we find a suitable solution. |
@zdenek-jonas, please use the following values in the projectName: 'serializer'
parentProject: '8fe715dc-b201-45e0-b6e0-5eb8da2ff4cf' |
|
@lukpueh |
This PR aims to bootstrap the EF Security Team initiative of generating and publishing SBOMs for project releases, with the goal of enhancing software supply chain security.
To not interfere with your existing release processes, this PR proposes a new workflow to generate and publish SBOMs autonomously, following GitHub releases of the store product. The workflow respects the existing SBOM plugin configuration in
pom.xml, which is updated to use the latest SBOM schema version.1In addition to the release event, the workflow can be triggered manually to test SBOM generation, or to generate SBOMs for past releases.
Following a workflow run, the EF self-service system automatically publishes the SBOM on our DependencyTrack instance, under the Eclipse Store → store entry. To view the uploaded results, you can log into DependencyTrack by using your EF account credentials.
If the PR is merged, we kindly ask you to run the workflow once, so that we can confirm a successful SBOM upload from your repository. You can find instructions to trigger a workflow manually in the GitHub documentation:
Also note that edits by maintainers are enabled for this PR, so feel free to update the workflow as you see fit, and do let us know if you have any questions!
More details about our SBOM Early Adopters initiative at EF can be found in our Security Handbook.
Footnotes
We recommend removing the SBOM configuration from
pom.xml, and defining necessary (non-default) options only in the new workflow to avoid surprising behaviour. ↩