Please don't take this the wrong way: I'm not arguing for or against anything. I just present opinions that you'll see and read in the SBOM ecosystem. I don't have a fully formed opinion on most of these things myself.
One argument is that downstream consumers of libraries should build their own SBOMs as only they will know how something is actually used. In Java for example only the consumer will know if she excluded something or replaced a dependency or another "sibling" dependency has something that overrides ours, shading could happen, optional dependencies can be used or not etc. The "upstream" library SBOM is - in those cases - mostly useful for metadata (authorship, provenance maybe, signatures/hashes, licenses etc.) but other than that they can be "dangerous" to use. The whole SBOM ecosystem is still very immature in my opinion and all of these best practices are yet to emerge. The Cyber Resilience Act will probably speed that up a bit. On Mon, Feb 19, 2024 at 9:57 PM Gary Gregory <garydgreg...@gmail.com> wrote: > > I don't think that's fair or good. I see 2 purposes: > > 1) Ourselves knowing what we publish > 2) Use for downstream consumers > > For 1, I see an SBOM like a POM in a different format. We can run tools on > a POM or SBOM to maybe tell us interesting things. Like "you have a > (transitive) dependency on a CVE". > > For 2, there is no way of knowing, so I'll keep my life simpler and publish > whatever a plain Maven plug-in configuration gives me. > > If you think Apache Commons should do better or differently, please let me > know! > > Gary > > On Mon, Feb 19, 2024, 12:45 PM Lars Francke <lars.fran...@gmail.com> wrote: > > > There are some people saying that libraries should not publish SBOMs at all > > because they have no idea how they are going to be used and then publishing > > something could lead to a false sense of correctness. > > > > I'm not sure I agree but there is some truth in it. > > > > Gary Gregory <garydgreg...@gmail.com> schrieb am Mo., 19. Feb. 2024, > > 18:24: > > > > > This is something I've been thinking about for a while: a (Maven) project > > > should not have optional dependencies. It just makes a mess in the end > > and > > > usually surprises users with class not found errors at runtime. > > > > > > This makes more sense if you split up a project into a multi-module > > (Maven) > > > project to only bring in required dependencies in the module that > > actually > > > needs it. > > > > > > Then I can add a check (somehow) that warns me (or fails) if my POMs use > > > optional dependencies. Another informative check would be if transitive > > > dependencies have optional dependencies. > > > > > > Gary > > > > > > On Mon, Feb 19, 2024, 12:12 PM Piotr P. Karwasz <piotr.karw...@gmail.com > > > > > > wrote: > > > > > > > Hi Arnout, > > > > > > > > Wow, great job! Until recently I had to upload SBOMs to Dependency > > > > Track manually. I suppose you have some sort of script for that? > > > > > > > > On Mon, 19 Feb 2024 at 15:20, Arnout Engelen <enge...@apache.org> > > wrote: > > > > > More and more Apache projects are producing SBOMs as part of their > > > > release > > > > > process. Challenges producing and consuming SBOMs are definitely > > > on-topic > > > > > for this list, and ideally we can consolidate that knowledge on the > > > > wiki[0] > > > > > > > > The first challenge that comes to mind is what version of our > > > > transitive dependencies should libraries specify in their SBOMs. I > > > > stress out the case of libraries, because for applications it is > > > > easier: they list the libraries they embed in their distribution. > > > > > > > > I am a big fan of Maven's dependency management, so whenever our > > > > direct dependency `foo` depends on a vulnerable `bar-1.0.0`, I bump > > > > the version of `bar` in the dependency management section of my > > > > project to `1.0.1` and the problem is solved! My test suite will run > > > > using `bar-1.0.1`, my SBOM will contain `bar-1.0.1` and Dependency > > > > Track will not complain. > > > > > > > > However this is just a trick: users of my library will still have > > > > `bar-1.0.0` on their classpath, unless they also bump the version of > > > > `bar` or the `foo` project releases a version that depends on > > > > `bar-1.0.1`. > > > > > > > > There is also another solution in Maven: I could add `bar` as a direct > > > > dependency of my project and bump its version to `1.0.1`. This way > > > > users can also benefit from the version bump, but this adds additional > > > > maintenance work: Dependabot will track new versions of `bar` and the > > > > list of project dependencies becomes long and messy. > > > > > > > > What do you think we should do in this case? > > > > > > > > > If you know of any other projects to include, would like help setting > > > up > > > > > SBOM publishing for your project, contribute 'nightly' SBOM > > snapshots, > > > or > > > > > discuss other things SBOM, I'm all ears! > > > > > > > > It would be nice to integrate Dependency Track into our release > > > > process. If the process of uploading SBOMs to Dependency Track is > > > > simplified, I could: > > > > > > > > * compile a snapshot, > > > > * check if there are dependency alerts (Dependabot gives us alerts > > > > for direct dependencies, but not the transitive ones), > > > > * bump the vulnerable transitive dependency versions (if possible), > > > > * prepare a release candidate. > > > > > > > > Piotr > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: > > > security-discuss-unsubscr...@community.apache.org > > > > For additional commands, e-mail: > > > > security-discuss-h...@community.apache.org > > > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org For additional commands, e-mail: security-discuss-h...@community.apache.org
