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
