You are viewing a plain text version of this content. The canonical link for it is here.
Posted to security-discuss@community.apache.org by Arnout Engelen <en...@apache.org> on 2024/02/19 14:20:39 UTC
Apache SBOM tracking in DependencyTrack
Hello security-discuss,
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]
If you're interested, we've set up a DependencyTrack[1] instance collecting
SBOMs for various Apache projects at [2]. You can log in with your Apache
id. Note that this is all experimental, we may drop all data at any time ;).
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!
Kind regards,
Arnout
[0]:
https://cwiki.apache.org/confluence/display/SECURITY/Software+Bill+of+Materials+SBOM
[1]: https://dependencytrack.org/
[2]: https://security-tools-ec2-va.apache.org
Re: Apache SBOM tracking in DependencyTrack
Posted by Andrea Cosentino <an...@gmail.com>.
Thanks for this Arnout, I'm planning to help by adding the weekly SBOMs we
are producing at Apache Camel and subprojects.
Please keep me in the loop if you need any help!
Il giorno lun 19 feb 2024 alle ore 15:21 Arnout Engelen <en...@apache.org>
ha scritto:
> Hello security-discuss,
>
> 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]
>
> If you're interested, we've set up a DependencyTrack[1] instance collecting
> SBOMs for various Apache projects at [2]. You can log in with your Apache
> id. Note that this is all experimental, we may drop all data at any time
> ;).
>
> 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!
>
>
> Kind regards,
>
> Arnout
>
> [0]:
>
> https://cwiki.apache.org/confluence/display/SECURITY/Software+Bill+of+Materials+SBOM
> [1]: https://dependencytrack.org/
> [2]: https://security-tools-ec2-va.apache.org
>
Re: Apache SBOM tracking in DependencyTrack
Posted by Lars Francke <la...@gmail.com>.
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 <la...@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 <ga...@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 <la...@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 <ga...@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.karwasz@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 <en...@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-unsubscribe@community.apache.org
> > > > > > For additional commands, e-mail:
> > > > > > security-discuss-help@community.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> > For additional commands, e-mail:
> > security-discuss-help@community.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Apache SBOM tracking in DependencyTrack
Posted by Jarek Potiuk <ja...@potiuk.com>.
> 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 <la...@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 <ga...@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 <la...@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 <ga...@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.karwasz@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 <en...@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-unsubscribe@community.apache.org
> > > > > For additional commands, e-mail:
> > > > > security-discuss-help@community.apache.org
> > > > >
> > > > >
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> For additional commands, e-mail:
> security-discuss-help@community.apache.org
>
>
Re: Apache SBOM tracking in DependencyTrack
Posted by Lars Francke <la...@gmail.com>.
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 <ga...@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 <la...@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 <ga...@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.karwasz@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 <en...@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-unsubscribe@community.apache.org
> > > > For additional commands, e-mail:
> > > > security-discuss-help@community.apache.org
> > > >
> > > >
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Apache SBOM tracking in DependencyTrack
Posted by Gary Gregory <ga...@gmail.com>.
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 <la...@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 <ga...@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.karwasz@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 <en...@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-unsubscribe@community.apache.org
> > > For additional commands, e-mail:
> > > security-discuss-help@community.apache.org
> > >
> > >
> >
>
Re: Apache SBOM tracking in DependencyTrack
Posted by Lars Francke <la...@gmail.com>.
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 <ga...@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 <pi...@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 <en...@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-unsubscribe@community.apache.org
> > For additional commands, e-mail:
> > security-discuss-help@community.apache.org
> >
> >
>
Re: Apache SBOM tracking in DependencyTrack
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
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-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Apache SBOM tracking in DependencyTrack
Posted by Jarek Potiuk <ja...@potiuk.com>.
> Wow, great job! Until recently I had to upload SBOMs to Dependency
Track manually. I suppose you have some sort of script for that?
I looked briefly at it before, but yes I hope that finally this and next
week I will be able to refresh and re-upload all the few hundreds (or even
thousands) of SBOMS for Airflow + our ~90 providers we have :) - see below
- via API (which I already got credentials from Arnout that need
refreshing). We are a bit extreme case, but I think it can show what can be
done when you have a lot of interconnected components released by a PMC
each with own set of dependencies and with the need of those components to
be able to be installed together (including optionality).
> 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.
> 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?
> 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.
I can share a complete experience on how we are doing it all in Airflow.
We have had a solution for it for a long time - and perfected over time (I
introduced it some 4 years ago, before we started releasing Airflow 2). We
are using the mechanism of constraints of pip for that. Together with every
release of Airflow (Airflow is rather special because it is both
application and library) we produce a complete set of dependencies
(including transitive) frozen at release time [1]. This is all fully
automated and built-in our CI - the constraints are upgraded and
automatically committed after every successful CI "canary" build and those
are the frozen dependencies most of our PRs are tested against (so that new
versions of released dependencies are not impacting regular PRs. Whenever
we release Airflow we freeze the constraints with a tag in GitHub. For
example [2] are the frozen constraints for Airflow 2.8.1
Those are the "golden set" of dependencies which were available at the
moment of release of Airflow X.Y.Z and provider(s) N.M.O. We now have a
mechanism to generate SBOMS for past versions of Airflow using those (and
this is how we are going to continue also in the future). So basically our
SBOM is a snapshot of all the "highest non-conflicting" versions of
dependencies at the moment of release of a given component version. I think
that's the most reasonable approach for us, maybe it can be applied for
others. And what's interesting - those constraints are a complete set of
dependencies for Airflow + ALL OPTIONAL sets of dependencies. In our case -
every provider we release is such an optional set of dependencies.
Note - those "golden" constraints are also the mechanism we recommend our
users to install Airflow in reproducible way [3] (because we want to keep
our upper-bound limits mostly opened, allowing the users to upgrade to new
versions of dependencies released after we release Airflow, but since they
can break Airflow we also wanted to have a way to be able to install
Airflow in a reproducible way by our users even if someone releases future
version of dependency that breaks Airflow). So choosing those "frozen"
constraints as source of SBOMS is very good for us - because those are also
user-facing and the actual way we recommend users to install airflow is
with those versions. Also reference images we publish (and freeze at
release time [4]) use the very same set of constraints.
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..
> 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.
[1] https://github.com/apache/airflow/commits/constraints-main/
[2] https://github.com/apache/airflow/commits/constraints-2.8.1/
[3]
https://airflow.apache.org/docs/apache-airflow/stable/installation/installing-from-pypi.html
[4]
https://airflow.apache.org/docs/docker-stack/index.html#fixing-images-at-release-time
On Mon, Feb 19, 2024 at 6:24 PM Gary Gregory <ga...@gmail.com> wrote:
> 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 <pi...@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 <en...@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-unsubscribe@community.apache.org
> > For additional commands, e-mail:
> > security-discuss-help@community.apache.org
> >
> >
>
Re: Apache SBOM tracking in DependencyTrack
Posted by Gary Gregory <ga...@gmail.com>.
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 <pi...@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 <en...@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-unsubscribe@community.apache.org
> For additional commands, e-mail:
> security-discuss-help@community.apache.org
>
>
Re: Apache SBOM tracking in DependencyTrack
Posted by Arnout Engelen <en...@apache.org>.
On Mon, Feb 19, 2024 at 6:12 PM Piotr P. Karwasz <pi...@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 <en...@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
Re: Apache SBOM tracking in DependencyTrack
Posted by "Piotr P. Karwasz" <pi...@gmail.com>.
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 <en...@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-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Apache SBOM tracking in DependencyTrack
Posted by Arnout Engelen <en...@apache.org>.
On Mon, Feb 19, 2024 at 3:43 PM Gary Gregory <ga...@gmail.com> wrote:
> Can the view deal with components that have BOTH CDX and SPDX like Commons
> components do?
>
Unfortunately as Lars linked it seems currently DependencyTrack doesn't
support SPDX
> What is the refresh rate? For example, I just pushed out (last night
> GMT-5) Apache Commons Compress 1.26.0 for two CVE fixes. But, the view
> still shows 1.25.0.
>
Currently it is "whenever I feel like it" :D. I just added 1.26.0.
> If not, will the view for 1.25.0 currently on display be updated to show
> the CVEs automatically?
>
I think DependencyTrack will only show CVEs for dependencies: so
https://security-tools-ec2-va.apache.org/projects/9137d80e-c379-4b8e-a58c-4f39fb457451
shows nothing 'itself', but for example
https://security-tools-ec2-va.apache.org/projects/da8dba92-c62c-4a8e-97b2-c5376dcf1c17/findings
does show 'this library uses commons-compress which has an advisory'.
Arnout
>
> On Mon, Feb 19, 2024 at 2:21 PM Arnout Engelen <en...@apache.org> wrote:
> >
> > Hello security-discuss,
> >
> > 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]
> >
> > If you're interested, we've set up a DependencyTrack[1] instance
> collecting
> > SBOMs for various Apache projects at [2]. You can log in with your Apache
> > id. Note that this is all experimental, we may drop all data at any time
> ;).
> >
> > 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!
> >
Re: Apache SBOM tracking in DependencyTrack
Posted by Gary Gregory <ga...@gmail.com>.
Thank you for the info Lars.
FYI over at Apache Commons, we use both CDX and SPDX through Maven
plugins, easy enough. Eventually one will win or we'll follow the
https://xkcd.com/927/ path ;)
Gary
On Mon, Feb 19, 2024 at 3:25 PM Lars Francke <la...@gmail.com> wrote:
>
> Hi Gary,
>
> sure, but it is specific to our use-case and to my experience.
> I understand some of this is subjective and I'm not looking to start a fight :)
>
> I found the CycloneDX community to be much easier to engage with.
> There is a Slack, I asked a bunch of questions and got help immediately.
> For SPDX I only found ways to "join" which led me to some Member
> Enrollment thing....I didn't look further.
>
> Then the SPDX standard is pretty "old" and hasn't seen much movement
> while there have been two or three CycloneDX releases with
> improvements since I started looking at it beginning of 2023.
> The community for SPDX seems to be much smaller and it seemed much
> harder to influence the spec. With CycloneDX there is a repo where I
> can just open issues
> - https://github.com/CycloneDX/specification/
> - https://github.com/CycloneDX/specification/issues/273
> - https://github.com/CycloneDX/specification/issues/349
>
> We need to generate SBOMs for Rust and CycloneDX has a list of tools
> they maintain themselves, amongst them a Rust SBOM generator. For SPDX
> I couldn't find any such thing.
>
> These are only the non-specification related reasons.
> I looked at both formats, they both seemed to (for a newcomer like I
> was) do more or less the same in the "core" so I picked the one that
> was easier in all regards for me.
> In addition CycloneDX supports more use-cases for the future.
> With the upcoming standardization of CycloneDX 1.6 by Ecma the
> argument of "but SPDX is standardized" should go away as well.
>
> We have since applied for and won (two times) money from the Sovereign
> Tech Fund to work on the Rust SBOM generator and more:
> https://www.sovereigntechfund.de/tech/rusty-sboms
>
> I really don't care too much about the format, I'd love it if one were
> to "win" and the other one were to go away.
> I can switch format if need be, the current situation is annoying.
>
> I hope it helps a bit, I can elaborate if needed.
>
> Cheers,
> Lars
>
> On Mon, Feb 19, 2024 at 4:11 PM Gary Gregory <ga...@gmail.com> wrote:
> >
> > Thanks for the feedback Lars.
> >
> > Can you share a bit more as to what guided you to choose CycloneDX over SPDX?
> >
> > TY,
> > Gary
> >
> > On Mon, Feb 19, 2024 at 2:48 PM Lars Francke <la...@gmail.com> wrote:
> > >
> > > As far as I know SPDX is not supported in DependencyTrack anymore but
> > > I might be wrong:
> > > - https://github.com/DependencyTrack/dependency-track/issues/1746
> > > - https://github.com/spdx/cdx2spdx/issues/35#issuecomment-1743546743
> > > - https://github.com/DependencyTrack/dependency-track/issues/1746#issuecomment-1942308273
> > >
> > > I may be biased but I consider CycloneDX to be "winning" in terms of
> > > mind-share and development speed.
> > > And I'm only biased after initially evaluating both formats for our
> > > own use and settling on CycloneDX after said evaluation.
> > >
> > > On Mon, Feb 19, 2024 at 3:43 PM Gary Gregory <ga...@gmail.com> wrote:
> > > >
> > > > TY Arnout.
> > > >
> > > > I was able to auth in and see Apache Commons, very cool.
> > > >
> > > > I see a column that says "BOM Foramt" and lists "CycloneDX" for all entries.
> > > >
> > > > Can the view deal with components that have BOTH CDX and SPDX like
> > > > Commons components do?
> > > >
> > > > Do you have any insight as to which format is winning or what other
> > > > formats we should consider supporting?
> > > >
> > > > What is the refresh rate? For example, I just pushed out (last night
> > > > GMT-5) Apache Commons Compress 1.26.0 for two CVE fixes. But, the view
> > > > still shows 1.25.0.
> > > >
> > > > Do I have to upload new BOMs for existing listings?
> > > >
> > > > If not, will the view for 1.25.0 currently on display be updated to
> > > > show the CVEs automatically?
> > > >
> > > > TY for your hard work! :-)
> > > > Gary
> > > >
> > > > On Mon, Feb 19, 2024 at 2:21 PM Arnout Engelen <en...@apache.org> wrote:
> > > > >
> > > > > Hello security-discuss,
> > > > >
> > > > > 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]
> > > > >
> > > > > If you're interested, we've set up a DependencyTrack[1] instance collecting
> > > > > SBOMs for various Apache projects at [2]. You can log in with your Apache
> > > > > id. Note that this is all experimental, we may drop all data at any time ;).
> > > > >
> > > > > 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!
> > > > >
> > > > >
> > > > > Kind regards,
> > > > >
> > > > > Arnout
> > > > >
> > > > > [0]:
> > > > > https://cwiki.apache.org/confluence/display/SECURITY/Software+Bill+of+Materials+SBOM
> > > > > [1]: https://dependencytrack.org/
> > > > > [2]: https://security-tools-ec2-va.apache.org
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> > > > For additional commands, e-mail: security-discuss-help@community.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> > > For additional commands, e-mail: security-discuss-help@community.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> > For additional commands, e-mail: security-discuss-help@community.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> For additional commands, e-mail: security-discuss-help@community.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Apache SBOM tracking in DependencyTrack
Posted by Lars Francke <la...@gmail.com>.
Hi Gary,
sure, but it is specific to our use-case and to my experience.
I understand some of this is subjective and I'm not looking to start a fight :)
I found the CycloneDX community to be much easier to engage with.
There is a Slack, I asked a bunch of questions and got help immediately.
For SPDX I only found ways to "join" which led me to some Member
Enrollment thing....I didn't look further.
Then the SPDX standard is pretty "old" and hasn't seen much movement
while there have been two or three CycloneDX releases with
improvements since I started looking at it beginning of 2023.
The community for SPDX seems to be much smaller and it seemed much
harder to influence the spec. With CycloneDX there is a repo where I
can just open issues
- https://github.com/CycloneDX/specification/
- https://github.com/CycloneDX/specification/issues/273
- https://github.com/CycloneDX/specification/issues/349
We need to generate SBOMs for Rust and CycloneDX has a list of tools
they maintain themselves, amongst them a Rust SBOM generator. For SPDX
I couldn't find any such thing.
These are only the non-specification related reasons.
I looked at both formats, they both seemed to (for a newcomer like I
was) do more or less the same in the "core" so I picked the one that
was easier in all regards for me.
In addition CycloneDX supports more use-cases for the future.
With the upcoming standardization of CycloneDX 1.6 by Ecma the
argument of "but SPDX is standardized" should go away as well.
We have since applied for and won (two times) money from the Sovereign
Tech Fund to work on the Rust SBOM generator and more:
https://www.sovereigntechfund.de/tech/rusty-sboms
I really don't care too much about the format, I'd love it if one were
to "win" and the other one were to go away.
I can switch format if need be, the current situation is annoying.
I hope it helps a bit, I can elaborate if needed.
Cheers,
Lars
On Mon, Feb 19, 2024 at 4:11 PM Gary Gregory <ga...@gmail.com> wrote:
>
> Thanks for the feedback Lars.
>
> Can you share a bit more as to what guided you to choose CycloneDX over SPDX?
>
> TY,
> Gary
>
> On Mon, Feb 19, 2024 at 2:48 PM Lars Francke <la...@gmail.com> wrote:
> >
> > As far as I know SPDX is not supported in DependencyTrack anymore but
> > I might be wrong:
> > - https://github.com/DependencyTrack/dependency-track/issues/1746
> > - https://github.com/spdx/cdx2spdx/issues/35#issuecomment-1743546743
> > - https://github.com/DependencyTrack/dependency-track/issues/1746#issuecomment-1942308273
> >
> > I may be biased but I consider CycloneDX to be "winning" in terms of
> > mind-share and development speed.
> > And I'm only biased after initially evaluating both formats for our
> > own use and settling on CycloneDX after said evaluation.
> >
> > On Mon, Feb 19, 2024 at 3:43 PM Gary Gregory <ga...@gmail.com> wrote:
> > >
> > > TY Arnout.
> > >
> > > I was able to auth in and see Apache Commons, very cool.
> > >
> > > I see a column that says "BOM Foramt" and lists "CycloneDX" for all entries.
> > >
> > > Can the view deal with components that have BOTH CDX and SPDX like
> > > Commons components do?
> > >
> > > Do you have any insight as to which format is winning or what other
> > > formats we should consider supporting?
> > >
> > > What is the refresh rate? For example, I just pushed out (last night
> > > GMT-5) Apache Commons Compress 1.26.0 for two CVE fixes. But, the view
> > > still shows 1.25.0.
> > >
> > > Do I have to upload new BOMs for existing listings?
> > >
> > > If not, will the view for 1.25.0 currently on display be updated to
> > > show the CVEs automatically?
> > >
> > > TY for your hard work! :-)
> > > Gary
> > >
> > > On Mon, Feb 19, 2024 at 2:21 PM Arnout Engelen <en...@apache.org> wrote:
> > > >
> > > > Hello security-discuss,
> > > >
> > > > 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]
> > > >
> > > > If you're interested, we've set up a DependencyTrack[1] instance collecting
> > > > SBOMs for various Apache projects at [2]. You can log in with your Apache
> > > > id. Note that this is all experimental, we may drop all data at any time ;).
> > > >
> > > > 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!
> > > >
> > > >
> > > > Kind regards,
> > > >
> > > > Arnout
> > > >
> > > > [0]:
> > > > https://cwiki.apache.org/confluence/display/SECURITY/Software+Bill+of+Materials+SBOM
> > > > [1]: https://dependencytrack.org/
> > > > [2]: https://security-tools-ec2-va.apache.org
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> > > For additional commands, e-mail: security-discuss-help@community.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> > For additional commands, e-mail: security-discuss-help@community.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> For additional commands, e-mail: security-discuss-help@community.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Apache SBOM tracking in DependencyTrack
Posted by Gary Gregory <ga...@gmail.com>.
Thanks for the feedback Lars.
Can you share a bit more as to what guided you to choose CycloneDX over SPDX?
TY,
Gary
On Mon, Feb 19, 2024 at 2:48 PM Lars Francke <la...@gmail.com> wrote:
>
> As far as I know SPDX is not supported in DependencyTrack anymore but
> I might be wrong:
> - https://github.com/DependencyTrack/dependency-track/issues/1746
> - https://github.com/spdx/cdx2spdx/issues/35#issuecomment-1743546743
> - https://github.com/DependencyTrack/dependency-track/issues/1746#issuecomment-1942308273
>
> I may be biased but I consider CycloneDX to be "winning" in terms of
> mind-share and development speed.
> And I'm only biased after initially evaluating both formats for our
> own use and settling on CycloneDX after said evaluation.
>
> On Mon, Feb 19, 2024 at 3:43 PM Gary Gregory <ga...@gmail.com> wrote:
> >
> > TY Arnout.
> >
> > I was able to auth in and see Apache Commons, very cool.
> >
> > I see a column that says "BOM Foramt" and lists "CycloneDX" for all entries.
> >
> > Can the view deal with components that have BOTH CDX and SPDX like
> > Commons components do?
> >
> > Do you have any insight as to which format is winning or what other
> > formats we should consider supporting?
> >
> > What is the refresh rate? For example, I just pushed out (last night
> > GMT-5) Apache Commons Compress 1.26.0 for two CVE fixes. But, the view
> > still shows 1.25.0.
> >
> > Do I have to upload new BOMs for existing listings?
> >
> > If not, will the view for 1.25.0 currently on display be updated to
> > show the CVEs automatically?
> >
> > TY for your hard work! :-)
> > Gary
> >
> > On Mon, Feb 19, 2024 at 2:21 PM Arnout Engelen <en...@apache.org> wrote:
> > >
> > > Hello security-discuss,
> > >
> > > 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]
> > >
> > > If you're interested, we've set up a DependencyTrack[1] instance collecting
> > > SBOMs for various Apache projects at [2]. You can log in with your Apache
> > > id. Note that this is all experimental, we may drop all data at any time ;).
> > >
> > > 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!
> > >
> > >
> > > Kind regards,
> > >
> > > Arnout
> > >
> > > [0]:
> > > https://cwiki.apache.org/confluence/display/SECURITY/Software+Bill+of+Materials+SBOM
> > > [1]: https://dependencytrack.org/
> > > [2]: https://security-tools-ec2-va.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> > For additional commands, e-mail: security-discuss-help@community.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> For additional commands, e-mail: security-discuss-help@community.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Apache SBOM tracking in DependencyTrack
Posted by Lars Francke <la...@gmail.com>.
As far as I know SPDX is not supported in DependencyTrack anymore but
I might be wrong:
- https://github.com/DependencyTrack/dependency-track/issues/1746
- https://github.com/spdx/cdx2spdx/issues/35#issuecomment-1743546743
- https://github.com/DependencyTrack/dependency-track/issues/1746#issuecomment-1942308273
I may be biased but I consider CycloneDX to be "winning" in terms of
mind-share and development speed.
And I'm only biased after initially evaluating both formats for our
own use and settling on CycloneDX after said evaluation.
On Mon, Feb 19, 2024 at 3:43 PM Gary Gregory <ga...@gmail.com> wrote:
>
> TY Arnout.
>
> I was able to auth in and see Apache Commons, very cool.
>
> I see a column that says "BOM Foramt" and lists "CycloneDX" for all entries.
>
> Can the view deal with components that have BOTH CDX and SPDX like
> Commons components do?
>
> Do you have any insight as to which format is winning or what other
> formats we should consider supporting?
>
> What is the refresh rate? For example, I just pushed out (last night
> GMT-5) Apache Commons Compress 1.26.0 for two CVE fixes. But, the view
> still shows 1.25.0.
>
> Do I have to upload new BOMs for existing listings?
>
> If not, will the view for 1.25.0 currently on display be updated to
> show the CVEs automatically?
>
> TY for your hard work! :-)
> Gary
>
> On Mon, Feb 19, 2024 at 2:21 PM Arnout Engelen <en...@apache.org> wrote:
> >
> > Hello security-discuss,
> >
> > 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]
> >
> > If you're interested, we've set up a DependencyTrack[1] instance collecting
> > SBOMs for various Apache projects at [2]. You can log in with your Apache
> > id. Note that this is all experimental, we may drop all data at any time ;).
> >
> > 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!
> >
> >
> > Kind regards,
> >
> > Arnout
> >
> > [0]:
> > https://cwiki.apache.org/confluence/display/SECURITY/Software+Bill+of+Materials+SBOM
> > [1]: https://dependencytrack.org/
> > [2]: https://security-tools-ec2-va.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> For additional commands, e-mail: security-discuss-help@community.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Apache SBOM tracking in DependencyTrack
Posted by Gary Gregory <ga...@gmail.com>.
TY Arnout.
I was able to auth in and see Apache Commons, very cool.
I see a column that says "BOM Foramt" and lists "CycloneDX" for all entries.
Can the view deal with components that have BOTH CDX and SPDX like
Commons components do?
Do you have any insight as to which format is winning or what other
formats we should consider supporting?
What is the refresh rate? For example, I just pushed out (last night
GMT-5) Apache Commons Compress 1.26.0 for two CVE fixes. But, the view
still shows 1.25.0.
Do I have to upload new BOMs for existing listings?
If not, will the view for 1.25.0 currently on display be updated to
show the CVEs automatically?
TY for your hard work! :-)
Gary
On Mon, Feb 19, 2024 at 2:21 PM Arnout Engelen <en...@apache.org> wrote:
>
> Hello security-discuss,
>
> 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]
>
> If you're interested, we've set up a DependencyTrack[1] instance collecting
> SBOMs for various Apache projects at [2]. You can log in with your Apache
> id. Note that this is all experimental, we may drop all data at any time ;).
>
> 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!
>
>
> Kind regards,
>
> Arnout
>
> [0]:
> https://cwiki.apache.org/confluence/display/SECURITY/Software+Bill+of+Materials+SBOM
> [1]: https://dependencytrack.org/
> [2]: https://security-tools-ec2-va.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org