Jump to: navigation, search

FLOP:CVE Monitoring

1,364 bytes added, 1 year ago
no edit summary
|Source URI=
= <tt>cver</tt>: A Tool for Monitoring CVEs =
== Summary ==
Ultimately, not all ebuilds are created equal. Hence they are updated at different rates according to their popularity in the tree of available packages and this is generally fine: packages with a lot of use get updated frequently, and vulnerabilities are generally dealt with. Unpopular ebuilds can languish, and no one really cares. However, unpopular ebuilds with a significant vulnerability should be updated, popular or not, as they represent a potential vector for attack, if they can be installed.
Identifying ebuilds with an associated CVE will bring them to 'head of the queue' for pull requests and updates, which should often be trivial, as the vulnerability is dealt with upstream and released as a new hotfix version. Or, we can fork and provide our own mitigation, merging with upstream again when a new release comes out (if at all).
The <tt>cver </tt> (pronounced ''ça-veer'') tool is built around redis and cached mongodb collections that are regularly updated with newly filed CVEs. The tool queries the collections to produce a set of text data appropriate to fill fields on a newly created security vulnerability issue on the Funtoo bug tracker. The data can be output in various formats (current just formatted text on stdout), and eventually input directly to the bug tracker via its REST api.
== Architecture ==
Thus, filtering packages by CVE requires a map between package names and CPE. The current algorithm is the simplest possible: if a CVE has a list of CPEs, each CPE is interpreted to yield a single token and an exact match with package name is attempted for the whole meta-repo using {{Package|app-portage/eix}}. If there is a match, then a <tt>jira</tt> issue can be constructed and reported. Even this simple algorithm produces quite a few matches, but it also misses very significant issues if the CPEs are not added properly to the CVE database for the issue. [ FL-6938] is a case in point: it was not filed with a CPE for {{package|sys-apps/portage}} (does it exist?) so the algorithm skipped right over it. A more sophisticated algorithm would have done regular expression matching on the <tt>summary</tt> key of the issue, perhaps matching on the string 'Gentoo Portage,' and producing a report for ''discussion'', and eventual posting to <tt>jira</tt>.
Once a match is made, the <tt>cve-search</tt> collection and the portage package database (via {{package|app-portage/eix}}) can be combined to produce the data appropriate for a report.
== State ==
The <tt>cver</tt> tool is currently stateless: it takes some bytes and it makes some bytes. Of course, <tt>jira</tt> and <tt>mongoDB</tt> are not, and their states must be kept in sync. Does <tt>cver</tt> require its own set of <tt>mongoDB</tt> collections to maintain the sync? This probably the most challenging aspect of the proposal.
- every update of the <tt>cve-search</tt> database must trigger an update of <tt>jira</tt>
- every CRUD path of <tt>cve-search</tt> must have an equivalent CRUD path of <tt>jira</tt>
- the sync of <tt>cve-search</tt> and <tt>jira</tt> must be always provable
However, we don't need to deal with <tt>cve-search</tt> directly: we can transform it into an intermediate state associated with <tt>cver</ver> that has its own paths, and then make the equivalent <tt>jira</tt> path from those. We may just 'bulk transform' the <tt>cve-search</tt> to a (probably much simpler) schema more directly related to that of a <tt>jira</tt> issue. We just need a collection of what are essentially <tt>jira</tt> records, with meta data to control the sync.

Navigation menu