Hi Jarek, On Mon, 19 Feb 2024 at 18:47, Jarek Potiuk <ja...@potiuk.com> wrote: > I know it's a Python world so it might be a bit different, but I think a > similar approach can be - I think used for all libraries as well in > different languages. Over the last few years when we released (long before > SBOMS and CRA) I've managed to work out a very nice and pretty > interconnected approach - where everything revolves around knowing what > complete set of dependencies is "golden" at the moment of release. And this > is great to see how it nicely fits now with SBOMS (and we have years of > history that we can reliably tap in to produce SBOMS for all historical > versions of Airflow 2 and all providers, which is pretty cool..
Apparently this also exists in the Maven world: there is a `<flattenDependencyMode>` in the Maven Flatten Plugin[1]. So maybe a recommendation we could add in the Wiki is to flatten all transitive dependencies as direct ones? Without doing this I don't see a point in publishing an SBOM. This will have some side effects: many sites like MvnRepository[3] started to integrate vulnerability warnings. Right now MvnRepository only lists the vulnerabilities of direct dependencies, if we were to flatten our dependency graphs, there will be many more warnings. There are Maven plugins that can check that the resolved version of a dependency is the upper bound of all the versions in the dependency tree (e.g. Maven Enforcer plugin [3]). The usage of such plugins should be recommended to all SBOM consumers, although I am not sure how popular this could be. We use Dependabot to upgrade our deps, so our dependencies are always bleeding edge. If an application using Log4j wants to have deps at least as recent as ours, it must upgrade several dozens dependencies at each release. That is scary, especially for applications with a low test coverage. > > 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: > > Oh we absolutely plan to do it as well and publish SBOM by release managers > automatically at the moment of release :D. And we are not far from that. Our SBOMs are published together with a release, but we don't have automatic tools to use them for any kind of verification. The result is that PMC members don't verify the SBOMs, when they vote. Piotr [1] https://www.mojohaus.org/flatten-maven-plugin/flatten-mojo.html#optional-parameters [2] https://mvnrepository.com/artifact/org.apache.flume/flume-ng-core/1.11.0 [3] https://maven.apache.org/enforcer/enforcer-rules/requireUpperBoundDeps.html --------------------------------------------------------------------- To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org For additional commands, e-mail: security-discuss-h...@community.apache.org
