I think you misunderstood what I said. Or I don't understand your answer. But it is off-topic anyway. I'm sorry for derailing the conversation.
On Mon, Feb 19, 2024 at 11:49 PM Jarek Potiuk <ja...@potiuk.com> wrote: > > > 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 > > Quite agree on both accounts (immature + CRA). I think however that even > such "imperfect" SBOM from libraries has it's value as it can indicate that > "some dependencies" are involved - and I think this will partially solve > itself when the release cycle speeds up for many libraries (which will be > pretty inevitable effect of CRA IMHO) + VEX. > From my experience I always see the dependencies a bit similar to the > "eventually consistent" concept. The more "Fresh" information you have the > more accurate it is - asymptotically approaching the "true state" (i.e > least number of false positives and negatives). > > The older information/SBOMS you have, the bigger the number of both > "falsey" information you will get increases. It will not negate the value > of the whole SBOM, but it will make it less reliable over time - that's why > also in Airflow we have this "SBOM/images frozen at release time" concept, > It's 100% accurate at release time, but a month from then, the dependency > of your library will be updated and some CVEs fixed there (and announced > about the version of library you "Froze" at your release time. It does not > make your software insecure, but it makes the SBOM information less > accurate and shows the false positive. VEX should - to some extent - > mitigate that, but I am of the opinion that we only should keep VEX > reflecting the "latest released" version of software (per maintained line)- > so that it "fixes" such false positives only for the most recently released > version of the software. But VEX should "reset" at the moment the new > release is out (and we should have only one VEX updated - always pointing > to the last released version in the maintained line). > > I think this SBOM deterioration over time and "freezing" all dependencies > at release time has one great property overall. It will - even more - > increase people's incentives to spend time and energy on upgrading to the > latest software, because the older software they will have the less they > will be able to rely on even the SBOM of htat software and the more > potential false positives they will have to deal with. With all the > regulations in place and with us - producers of the software - agreeing on > the fact that "old SBOMS should be fixed in point in time" and all of us - > producers of the software - agreeing that it is OK for SBOMS to deteriorate > over time, and that we are not going to address this deterioration by VEX > except the last available release, it might help to make sure that users > will in-fact upgrade their software. > > Simply speaking - as an industry we have to create an incentive for our > users to see how cost connecting with "not upgrading" grows with time (by > having to analyse and handle growing number of true and false positives) - > up to the point that the cost of not upgrading is bigger than the cost of > upgrading. So far we lived in a world where the cost of not upgrading was > close to 0 in most cases for most users and we need to change it. We need > to make absolutely sure that the users are painfully aware that their cost > of not upgrading is growing constantly - starting from 0 at the moment of > upgrading to the latest version. > > So having a "dangerous" SBOM for something that was released, 3 versions > ago - yes. I very much like the idea. It should be more and more dangerous > to rely on it the older it gets. > > J. > > On Mon, Feb 19, 2024 at 10:50 PM Lars Francke <lars.fran...@gmail.com> > wrote: > > > 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org For additional commands, e-mail: security-discuss-h...@community.apache.org
