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 <jan....@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 <enge...@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 <enge...@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-unsubscr...@solr.apache.org > >>> For additional commands, e-mail: dev-h...@solr.apache.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
