Generate SBOM during build/release process

[tylerbenson]

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:

• https://github.com/open-telemetry/community/discussions/1741
• https://github.com/security-slam/metrics/blob/main/cncf/2023/mechanizer.md

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.05%. Comparing base (97609a9) to head (8293786).
Report is 18 commits behind head on main.

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.
📢 Have feedback on the report? Share it here.

[trask]

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 opentelemetry-api)?

[tylerbenson]

@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.

[jack-berg]

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?

[cartersocha]

We're going to have some SBOM experts come present to the maintainers call post KubeCon

[jack-berg]

Questions about this PR that came up during the maintainers meeting:

• Does the SBOM contain only the dependencies which are bundled, or also transitive dependencies which the user technically brings in? Should probably only include dependencies which are bundled, which is essentially none for most of the artifacts in this repo.
• Is there one SBOM that describes all artifacts, or one SBOM per artifact? My interpretation is that either could be acceptable, but one SBOM per artifact is probably preferable so we can publish each to maven central along side the artifact jar.
• How to publish? Should probably be published to maven central along with each artifact. Also, it sounds like there is a requirement to publish with the github release. Can bundle together in an archive to prevent attaching 1 file per artifact.

[jack-berg]

Now that the boms are part of the maven publication, do we actually need to publish them as *.zip?

[tylerbenson]

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.

[jack-berg]

👍 seems reasonable to me. @open-telemetry/sig-security-maintainers can we codify this advice somewhere?

[jack-berg]

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?

[jack-berg]

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

[trask]

Added an item to the 3/28/24 java SIG to discuss the merits of publishing both spdx and cyclonedx

can we get official guidance published somewhere by @open-telemetry/sig-security-maintainers? I suspect we would just follow their recommendation?

[jack-berg]

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.

[cartersocha]

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.

[tylerbenson]

PR on the java instrumentation side:
open-telemetry/opentelemetry-java-instrumentation#11075