-
Notifications
You must be signed in to change notification settings - Fork 801
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
Generate SBOM during build/release process #5948
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #5948 +/- ##
============================================
+ Coverage 91.03% 91.05% +0.01%
- Complexity 5714 5732 +18
============================================
Files 622 625 +3
Lines 16733 16748 +15
Branches 1711 1713 +2
============================================
+ Hits 15233 15250 +17
+ Misses 1007 1003 -4
- Partials 493 495 +2 ☔ View full report in Codecov by Sentry. |
is it typical for SBOM to contain everything that was used across the whole repository as opposed to being scoped to specific published artifacts (e.g. SBOM for |
@trask I think being overly thorough is fine as long as those extra dependencies aren't too noisy from a vulnerability perspective. Having this is better than the current state of having nothing. Later on if the extra dependencies are problematic we can explore how to filter them out with additional configuration. |
Talked about this in the 11/2 Java SIG. Discussed that it would be good to understand how folks typically use SBOMs to ensure that what we produce matches expectations. Maybe @open-telemetry/sig-security-maintainers can chime in with some document on SBOMs to help maintainers come up to speed? |
We're going to have some SBOM experts come present to the maintainers call post KubeCon |
Questions about this PR that came up during the maintainers meeting:
|
e20b7e5
to
4d6d74a
Compare
This has been requested by customers to enable better security practices. When run in a build job, it uploads the generated SBOM as a build artifact `opentelemetry-java-build.spdx.json`. When run as a release, it will also upload the SBOM to the github release. I tested the build part on a different repo, but didn't verify the release part.
Execute task on `assemble` and upload results as github build artifact
4d6d74a
to
e9946eb
Compare
71b43db
to
56f4683
Compare
f17e0a6
to
19ea419
Compare
find . -path ./sboms -prune -o -name "*.cyclonedx.json" -exec mv {} ./sboms/ \; | ||
find . -path ./sboms -prune -o -name "*.spdx.json" -exec mv {} ./sboms/ \; | ||
zip SBOM.zip sboms/* | ||
cp SBOM.zip /tmp/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that the boms are part of the maven publication, do we actually need to publish them as *.zip
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it makes sense to have a way to gather SBOM's consistently within OTel. This way folks don't have to check NPM, Maven, etc to evaluate SBOM's across OTel.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 seems reasonable to me. @open-telemetry/sig-security-maintainers can we codify this advice somewhere?
Can you update the PR description to reflect the current status with publishing both spdx and cyclonedx formats, and publishing them as artifacts to maven? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added an item to the 3/28/24 java SIG to discuss the merits of publishing both spdx and cyclonedx, but this looks good to me. Thanks @tylerbenson
can we get official guidance published somewhere by @open-telemetry/sig-security-maintainers? I suspect we would just follow their recommendation? |
Discussed in the 4/4/24 SIG meeting. We're going to delay until we here back from the security SIG on whether publishing SBOMs for libraries is relevant / useful. |
Here's a link to our SBOM guidance. I'll provide an update in the next maintainer call. After consulting with some OpenSSF contributors we determined SBOMs are not material for SDKs / APIs but are for things like auto-instrumentation agents or other components. We can close this PR and will open a similar one for the Java agent. |
PR on the java instrumentation side: |
This has been requested by customers to enable better security practices.
Adds the spdx-gradle-plugin and the cyclonedx-gradle-plugin to published projects to generate SBOM files for the build.
When run in a build job, the various generated SBOMs are collected into
SBOM.zip
and uploaded as a build artifact . When run as a release, it will also upload the SBOM to the github release.The release part has been verified: https://github.com/tylerbenson/opentelemetry-java/releases/tag/v1.37.0
(Notice the
SBOM.zip
file attached. This was done automatically by the workflow.)The SBOM's are also attached to the publication so they are individually uploaded to Maven Central as part of the release process. This process was verified with the
publishToMavenLocal
task.Related links: