Re: Publishing dependency vulnerability information

[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

[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
>
>