You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@solr.apache.org by Arnout Engelen <en...@apache.org> on 2022/11/30 11:14:15 UTC
Publishing dependency vulnerability information
Hi,
We regularly get questions asking whether Solr is affected by
vulnerabilities that were disclosed for a dependency. With all the
recent enthusiasm around vulnerability scanning and SBOM's, I think we
can expect the number of such questions to rise.
Solr already does a great job of collecting known false positives at
https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity#SolrSecurity-SolrandVulnerabilityScanningTools
. I think it would be interesting to experiment with sharing this
information in a machine-readable way. I've been reading up and
experimenting a bit, and it's clear that it is early days, and a lot
of work still needs to be done in the wider ecosystem: there are
various SBOM/VEX file formats, and even within a format most tools
rely on their own dialect.
That said, I've had some success generating a VEX file from the table
on the Solr wiki, attached. When I create an SBOM for solr 9.0.0 with
the gradle org.cyclonedx.bom plugin, load it into the OWASP
dependencytrack tool, and when I apply the VEX indeed it filters out
some of the reported CVE's and marks the Calcite problem
(CVE-2022-39135) as 'exploitable' - so that's at least a start. I
would be interested in pointing people with questions about
vulnerability scanner results to that, and working with them to gain
experience on what we can do to make this useful.
I would be happy to maintain a VEX file for Solr, be the contact point
for feedback and questions on how to use it, etc. It doesn't look like
the wiki allows file uploads, perhaps we could include it in the
solr-site repo? We could also expand the "Solr and Vulnerability
Scanning Tools" section on the wiki, explaining in more detail what to
do when their CVE scanning tool flags a problem in Solr. I'd also be
happy to propose a first draft of such a paragraph.
Curious to hear your thoughts!
Kind regards,
Arnout
Re: Publishing dependency vulnerability information
Posted by David Smiley <ds...@apache.org>.
Yeah, we want to maintain this in as few places as possible -- ideally one
place. But I think it's *adequate* albeit not ideal to have our more
pretty/user-consumably documentation refer to a raw file that a user would
have to search. We shouldn't let the ideal be the enemy of progress.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Wed, Nov 30, 2022 at 8:10 PM Jan Høydahl <ja...@cominvent.com> wrote:
> Good thoughts here.
>
> I have also thought about possibly moving the list of false positives from
> wiki to the website.
> It could be a JSON file or whatever parsable file, and we can parse it in
> Javascript and
> output it as a table. At the same time we could offer simple
> search/filtering both across
> known CVEs and false positives, so that if someone enters CVE-2022-123
> then they would
> quickly see what we know about that particular CVE.
>
> Jan
>
> > 30. nov. 2022 kl. 17:19 skrev Arnout Engelen <en...@apache.org>:
> >
> > On Wed, Nov 30, 2022 at 4:36 PM Mike Drob <md...@apache.org> wrote:
> >> From my understanding, SBOM are meaningful in the context of a release,
> not
> >> necessarily an arbitrary code point. VEX on the other hand could be
> updated
> >> between releases as information comes in about new CVEs and such. I
> think
> >> that’s an important duality to consider when it comes to storage of
> these.
> >
> > Yes, that's how I think about those as well
> >
> >> I’ll play with the VEX file you generated a little bit more later this
> >> week, definitely looking forward to it! Can you also put up a PR for how
> >> you generated the SBOM?
> >
> > Sure - I used
> https://github.com/apache/solr/commit/b1a49b5ea18ed9b28df877d2e7853477a63702ab
> > here, just rebased and turned into a draft PR at
> > https://github.com/apache/solr/pull/1203
> >
> >> I’m not sure we want to commit to that yet, but at
> >> least a draft state would be best to collaborate on.
> >
> > That makes sense! There's a number of different SBOM formats and ways
> > to generate them. My choice for org.cyclonedx.bom here was simply a
> > quick way to get started experimenting with VEX, I haven't looked at
> > the quality of the output or the relative merits of other formats yet.
> > I like having a tangible starting point to talk about and improve on
> > :).
> >
> >
> > Kind regards,
> >
> > Arnout
> >
> >> On Wed, Nov 30, 2022 at 3:15 AM Arnout Engelen <en...@apache.org>
> wrote:
> >>
> >>> Hi,
> >>>
> >>> We regularly get questions asking whether Solr is affected by
> >>> vulnerabilities that were disclosed for a dependency. With all the
> >>> recent enthusiasm around vulnerability scanning and SBOM's, I think we
> >>> can expect the number of such questions to rise.
> >>>
> >>> Solr already does a great job of collecting known false positives at
> >>>
> >>>
> https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity#SolrSecurity-SolrandVulnerabilityScanningTools
> >>> . I think it would be interesting to experiment with sharing this
> >>> information in a machine-readable way. I've been reading up and
> >>> experimenting a bit, and it's clear that it is early days, and a lot
> >>> of work still needs to be done in the wider ecosystem: there are
> >>> various SBOM/VEX file formats, and even within a format most tools
> >>> rely on their own dialect.
> >>>
> >>> That said, I've had some success generating a VEX file from the table
> >>> on the Solr wiki, attached. When I create an SBOM for solr 9.0.0 with
> >>> the gradle org.cyclonedx.bom plugin, load it into the OWASP
> >>> dependencytrack tool, and when I apply the VEX indeed it filters out
> >>> some of the reported CVE's and marks the Calcite problem
> >>> (CVE-2022-39135) as 'exploitable' - so that's at least a start. I
> >>> would be interested in pointing people with questions about
> >>> vulnerability scanner results to that, and working with them to gain
> >>> experience on what we can do to make this useful.
> >>>
> >>> I would be happy to maintain a VEX file for Solr, be the contact point
> >>> for feedback and questions on how to use it, etc. It doesn't look like
> >>> the wiki allows file uploads, perhaps we could include it in the
> >>> solr-site repo? We could also expand the "Solr and Vulnerability
> >>> Scanning Tools" section on the wiki, explaining in more detail what to
> >>> do when their CVE scanning tool flags a problem in Solr. I'd also be
> >>> happy to propose a first draft of such a paragraph.
> >>>
> >>> Curious to hear your thoughts!
> >>>
> >>>
> >>> Kind regards,
> >>>
> >>> Arnout
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >>> For additional commands, e-mail: dev-help@solr.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: Publishing dependency vulnerability information
Posted by Jan Høydahl <ja...@cominvent.com>.
Good thoughts here.
I have also thought about possibly moving the list of false positives from wiki to the website.
It could be a JSON file or whatever parsable file, and we can parse it in Javascript and
output it as a table. At the same time we could offer simple search/filtering both across
known CVEs and false positives, so that if someone enters CVE-2022-123 then they would
quickly see what we know about that particular CVE.
Jan
> 30. nov. 2022 kl. 17:19 skrev Arnout Engelen <en...@apache.org>:
>
> On Wed, Nov 30, 2022 at 4:36 PM Mike Drob <md...@apache.org> wrote:
>> From my understanding, SBOM are meaningful in the context of a release, not
>> necessarily an arbitrary code point. VEX on the other hand could be updated
>> between releases as information comes in about new CVEs and such. I think
>> that’s an important duality to consider when it comes to storage of these.
>
> Yes, that's how I think about those as well
>
>> I’ll play with the VEX file you generated a little bit more later this
>> week, definitely looking forward to it! Can you also put up a PR for how
>> you generated the SBOM?
>
> Sure - I used https://github.com/apache/solr/commit/b1a49b5ea18ed9b28df877d2e7853477a63702ab
> here, just rebased and turned into a draft PR at
> https://github.com/apache/solr/pull/1203
>
>> I’m not sure we want to commit to that yet, but at
>> least a draft state would be best to collaborate on.
>
> That makes sense! There's a number of different SBOM formats and ways
> to generate them. My choice for org.cyclonedx.bom here was simply a
> quick way to get started experimenting with VEX, I haven't looked at
> the quality of the output or the relative merits of other formats yet.
> I like having a tangible starting point to talk about and improve on
> :).
>
>
> Kind regards,
>
> Arnout
>
>> On Wed, Nov 30, 2022 at 3:15 AM Arnout Engelen <en...@apache.org> wrote:
>>
>>> Hi,
>>>
>>> We regularly get questions asking whether Solr is affected by
>>> vulnerabilities that were disclosed for a dependency. With all the
>>> recent enthusiasm around vulnerability scanning and SBOM's, I think we
>>> can expect the number of such questions to rise.
>>>
>>> Solr already does a great job of collecting known false positives at
>>>
>>> https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity#SolrSecurity-SolrandVulnerabilityScanningTools
>>> . I think it would be interesting to experiment with sharing this
>>> information in a machine-readable way. I've been reading up and
>>> experimenting a bit, and it's clear that it is early days, and a lot
>>> of work still needs to be done in the wider ecosystem: there are
>>> various SBOM/VEX file formats, and even within a format most tools
>>> rely on their own dialect.
>>>
>>> That said, I've had some success generating a VEX file from the table
>>> on the Solr wiki, attached. When I create an SBOM for solr 9.0.0 with
>>> the gradle org.cyclonedx.bom plugin, load it into the OWASP
>>> dependencytrack tool, and when I apply the VEX indeed it filters out
>>> some of the reported CVE's and marks the Calcite problem
>>> (CVE-2022-39135) as 'exploitable' - so that's at least a start. I
>>> would be interested in pointing people with questions about
>>> vulnerability scanner results to that, and working with them to gain
>>> experience on what we can do to make this useful.
>>>
>>> I would be happy to maintain a VEX file for Solr, be the contact point
>>> for feedback and questions on how to use it, etc. It doesn't look like
>>> the wiki allows file uploads, perhaps we could include it in the
>>> solr-site repo? We could also expand the "Solr and Vulnerability
>>> Scanning Tools" section on the wiki, explaining in more detail what to
>>> do when their CVE scanning tool flags a problem in Solr. I'd also be
>>> happy to propose a first draft of such a paragraph.
>>>
>>> Curious to hear your thoughts!
>>>
>>>
>>> Kind regards,
>>>
>>> Arnout
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>>> For additional commands, e-mail: dev-help@solr.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Publishing dependency vulnerability information
Posted by Arnout Engelen <en...@apache.org>.
On Wed, Nov 30, 2022 at 4:36 PM Mike Drob <md...@apache.org> wrote:
> From my understanding, SBOM are meaningful in the context of a release, not
> necessarily an arbitrary code point. VEX on the other hand could be updated
> between releases as information comes in about new CVEs and such. I think
> that’s an important duality to consider when it comes to storage of these.
Yes, that's how I think about those as well
> I’ll play with the VEX file you generated a little bit more later this
> week, definitely looking forward to it! Can you also put up a PR for how
> you generated the SBOM?
Sure - I used https://github.com/apache/solr/commit/b1a49b5ea18ed9b28df877d2e7853477a63702ab
here, just rebased and turned into a draft PR at
https://github.com/apache/solr/pull/1203
> I’m not sure we want to commit to that yet, but at
> least a draft state would be best to collaborate on.
That makes sense! There's a number of different SBOM formats and ways
to generate them. My choice for org.cyclonedx.bom here was simply a
quick way to get started experimenting with VEX, I haven't looked at
the quality of the output or the relative merits of other formats yet.
I like having a tangible starting point to talk about and improve on
:).
Kind regards,
Arnout
> On Wed, Nov 30, 2022 at 3:15 AM Arnout Engelen <en...@apache.org> wrote:
>
> > Hi,
> >
> > We regularly get questions asking whether Solr is affected by
> > vulnerabilities that were disclosed for a dependency. With all the
> > recent enthusiasm around vulnerability scanning and SBOM's, I think we
> > can expect the number of such questions to rise.
> >
> > Solr already does a great job of collecting known false positives at
> >
> > https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity#SolrSecurity-SolrandVulnerabilityScanningTools
> > . I think it would be interesting to experiment with sharing this
> > information in a machine-readable way. I've been reading up and
> > experimenting a bit, and it's clear that it is early days, and a lot
> > of work still needs to be done in the wider ecosystem: there are
> > various SBOM/VEX file formats, and even within a format most tools
> > rely on their own dialect.
> >
> > That said, I've had some success generating a VEX file from the table
> > on the Solr wiki, attached. When I create an SBOM for solr 9.0.0 with
> > the gradle org.cyclonedx.bom plugin, load it into the OWASP
> > dependencytrack tool, and when I apply the VEX indeed it filters out
> > some of the reported CVE's and marks the Calcite problem
> > (CVE-2022-39135) as 'exploitable' - so that's at least a start. I
> > would be interested in pointing people with questions about
> > vulnerability scanner results to that, and working with them to gain
> > experience on what we can do to make this useful.
> >
> > I would be happy to maintain a VEX file for Solr, be the contact point
> > for feedback and questions on how to use it, etc. It doesn't look like
> > the wiki allows file uploads, perhaps we could include it in the
> > solr-site repo? We could also expand the "Solr and Vulnerability
> > Scanning Tools" section on the wiki, explaining in more detail what to
> > do when their CVE scanning tool flags a problem in Solr. I'd also be
> > happy to propose a first draft of such a paragraph.
> >
> > Curious to hear your thoughts!
> >
> >
> > Kind regards,
> >
> > Arnout
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Publishing dependency vulnerability information
Posted by Mike Drob <md...@apache.org>.
Hi Arnout,
Thanks for starting this conversation, I have had similar thoughts recently
but hadn’t put them to action yet.
From my understanding, SBOM are meaningful in the context of a release, not
necessarily an arbitrary code point. VEX on the other hand could be updated
between releases as information comes in about new CVEs and such. I think
that’s an important duality to consider when it comes to storage of these.
I’ll play with the VEX file you generated a little bit more later this
week, definitely looking forward to it! Can you also put up a PR for how
you generated the SBOM? I’m not sure we want to commit to that yet, but at
least a draft state would be best to collaborate on.
Mike
On Wed, Nov 30, 2022 at 3:15 AM Arnout Engelen <en...@apache.org> wrote:
> Hi,
>
> We regularly get questions asking whether Solr is affected by
> vulnerabilities that were disclosed for a dependency. With all the
> recent enthusiasm around vulnerability scanning and SBOM's, I think we
> can expect the number of such questions to rise.
>
> Solr already does a great job of collecting known false positives at
>
> https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity#SolrSecurity-SolrandVulnerabilityScanningTools
> . I think it would be interesting to experiment with sharing this
> information in a machine-readable way. I've been reading up and
> experimenting a bit, and it's clear that it is early days, and a lot
> of work still needs to be done in the wider ecosystem: there are
> various SBOM/VEX file formats, and even within a format most tools
> rely on their own dialect.
>
> That said, I've had some success generating a VEX file from the table
> on the Solr wiki, attached. When I create an SBOM for solr 9.0.0 with
> the gradle org.cyclonedx.bom plugin, load it into the OWASP
> dependencytrack tool, and when I apply the VEX indeed it filters out
> some of the reported CVE's and marks the Calcite problem
> (CVE-2022-39135) as 'exploitable' - so that's at least a start. I
> would be interested in pointing people with questions about
> vulnerability scanner results to that, and working with them to gain
> experience on what we can do to make this useful.
>
> I would be happy to maintain a VEX file for Solr, be the contact point
> for feedback and questions on how to use it, etc. It doesn't look like
> the wiki allows file uploads, perhaps we could include it in the
> solr-site repo? We could also expand the "Solr and Vulnerability
> Scanning Tools" section on the wiki, explaining in more detail what to
> do when their CVE scanning tool flags a problem in Solr. I'd also be
> happy to propose a first draft of such a paragraph.
>
> Curious to hear your thoughts!
>
>
> Kind regards,
>
> Arnout
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org