On Mon, Feb 19, 2024 at 6:12 PM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote:
> Wow, great job! Until recently I had to upload SBOMs to Dependency > Track manually. I suppose you have some sort of script for that? > Yes - it's very crude for now, but we can iterate on that when it works out. > 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 think that's exactly the kinds of questions we should be asking! > 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`. > Indeed! And even for your direct dependencies, your users' dependencies or dependencyManagement might pull in other versions - or they might use other build tools that behave different still. > 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? > First and foremost I think we should discover and document these limitations of the various approaches and tools. For example, the above nicely illustrates SBOMs being available for libraries is no substitute for doing your own analysis in a project using those libraries. Vice-versa, however, ignoring the SBOMs for your dependencies also seems imperfect: say that dependency 'vendored in' some code from another project, and nicely expressed that in their SBOM - if you then just throw away that information if you generate yours 'purely' based on the maven artifacts in your dependency tree. > > 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. > Doing this during the release seems somewhat late - perhaps it would make sense to do this in some nightly/weekly/... CI job? Kind regards, -- Arnout Engelen ASF Security Response PPMC member on Apache Pekko Committer on NixOS Independent Open Source consultant
