ppkarwasz commented on PR #3929: URL: https://github.com/apache/solr/pull/3929#issuecomment-5150686346
Hi @epugh, Sorry: I must have missed the notification for your comment. I recently cleared a rather large notification backlog by dismissing everything and promising myself I would keep up better in the future. :wink: > Sleuthing back in history, did this close because of lack of traction? Yes. It was closed automatically because of inactivity; there were no technical objections recorded on the PR. > Is `bom.json` now something that most projects distribute, and Solr is lacking there? Not exactly. Including a `bom.json` file in the **root of the binary distribution** is my own proposal, loosely inspired by [PEP 770](https://peps.python.org/pep-0770/). The main advantage is that the SBOM travels with the artifact and is less likely to become detached or lost. The filename itself is not entirely arbitrary: `bom.json` is one of the [recognized CycloneDX filename patterns](https://cyclonedx.org/specification/overview/#recognized-file-patterns). There are at least two other reasonable publication models: 1. Publish a file such as `solr-1.0.0.tgz.cdx.json` alongside the release artifacts on `downloads.apache.org`, similarly to the existing `.asc` and `.sha512` files. This approach was discussed on the Apache Trusted Releases Slack channel. 2. As a possible evolution of that model, embed the SBOM in an `intoto.jsonl` attestation bundle alongside other attestations the project may produce, such as SLSA provenance. I do not think there is yet a single universally adopted convention here. > Do projects ship their own SBOM, or do people produce them from the raw artifacts using tools like `syft`? Both approaches coexist, but they produce different kinds of SBOMs. An SBOM generated by tools such as `syft` or `cdxgen` by inspecting the finished artifact is an **Analyzed SBOM** in [CISA’s SBOM type classification](https://www.cisa.gov/resources-tools/resources/types-software-bill-materials-sbom). The SBOM proposed in this PR would be a **Build SBOM**, because it is generated during the build using the dependency information available to the build system. Each approach has different strengths: * A Build SBOM has access to the complete dependency metadata known to Gradle, including relationships and metadata that may not be recoverable from the final archive. * However, it describes the build’s intent: it tells us which dependencies the build was configured to include, but it does not independently verify that every declared component actually ended up in the distribution. * An analyzed SBOM generated by `syft` or `cdxgen` examines the finished artifact, so it can help verify what was actually shipped. * Conversely, artifact analysis may miss metadata or dependency relationships that are available only during the build. In that sense, the two approaches are complementary rather than mutually exclusive. A Build SBOM provides authoritative build-time metadata, while an independently generated analyzed SBOM can act as a useful verification step. The SBOM in this PR was generated directly by the CycloneDX Gradle Plugin. Because of the complexity of Solr’s build, the plugin misidentifies a number of components. I plan to open a new PR that post-processes the generated SBOM to produce the most accurate result currently possible. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
