Generate more extensive CVE reports (e.g. for managers)

[terriko]

I put this originally in #267 but it occurs to me that it's worth filing as a separate issue so it can be discussed outside of GSoC's context:

• Generate full reports with CVE descriptions, etc. We don't currently store these in the database and probably don't want to for speed/space reasons, so you'd have to grab from the json. This was a feature that used to exist in cve-bin-tool before it was open sourced. The idea, I believe, is that you'd have something you could easily attach to an email or send in a meeting agenda so decisions could be made prioritizing fixes. In practice it wasn't getting used much which is why it wound up dropped before release, but it could still be useful for folk who need more info to send to their colleagues.

As I said in #324 (Adding a GUI), all signs I've had from our known users point to them wanting as little GUI as possible -- things are running on the command line, probably in CI systems like Github Actions or Travis. So we get requests for machine readable output, or we get requests for no output at all, only a pass-fail so a known cve will "break the build" as it were and alert people that something's wrong.

But I don't think that necessarily means people don't want good human readable output, just that it's probably not going to be desired in a "single user at a computer running a report for themselves" context. It's more likely "the build system will do the checks on its own time" and "maybe when the build fails we'll want to generate a report that can be emailed to the guilty parties" or "maybe when we investigate we'll need some nice reports to take to management so they can assign people to fix issues with appropriate priorities." I'm... honestly not sure what people are going to want here, but juding from what I see in similar tools, here's some ideas:

• What files are affected
• What packages/versions were found
• What CVEs were found
• Some sort of colourized output to show you which CVEs are most scary by severity rating
• Maybe show more of the severity data? (We're using only the summary number but there's more there)
• Maybe a longer report with the short CVE description text
• Make the whole thing possible to generate from one of those machine readable logs (see Machine-readable output #262) so it could be done after the fact only as needed and you wouldn't have to re-run scans
• Maybe some graphs ?
• Maybe some ability to track changes vs a previous log if one's available? (probably needs to go with machine readable logs Machine-readable output #262 )

I'm guessing they'll want this in a format that can easily be emailed around, so probably html is the easiest if we're going past the plain-text output we have now (+svg for graphs?). But I'm not tied to that idea.

[terriko]

It would also be awesome if whatever we do here could also be used by csv2cve!

[FReeshabh]

Sounds interesting, I'll look into it

[SinghHrmn]

@terriko I want to know if you are talking about CSV and JSON as the machine-readable logs?

If yes.
As we are now able to generate both of them do we need to generate a detailed descriptive report only from those outputs? I want to know if we can add descriptive reports as an output type. So, the user can specify before scanning the files to generate a detailed report. Also, I can't figure out how we can scan the previous log? -- Do we need a specific name for the file so we can first check if the file already exists then we can create a duplicate of that file and then overwrite that with the new one and after that, we can scan for differences in the new(having the fixed defined name) and duplicate file(old one)? --or can we do something better?

If no.
Then, what type of logs do we want to use?

[terriko]

• yes, the CSV and JSON will be our machine readable logs. (And no other formats are planned at this time)
• this report generator will likely be another command line program (like csv2cve) that you run with a filename to specify the log you want to generate from
• for this report-only mode, you likely want to generate an entirely new report and never edit the original.
• But if we combine this with the triage stuff, you could maybe have the option to write triage data to the file? I don't know what the best option will be there.
• maybe we'd want to specify a bunch of log files and track changes over time, too. that would likely be phase two, though.

[SinghHrmn]

The Project will consist of 3 parts

• Getting the data
• Generating Graphs
• Generating Templates
  joining the data and then displaying it on the browser.

I'll start working on this project. I'll first get to know how the control will flow and which data I want to use.

[SinghHrmn]

@terriko @pdxjohnny I want to share some screenshots of the template with dummy data. Please review

This is the main dashboard for the output.

After that, we will have a list of all the products with known vulnerability and on clicking any Product we will get list of CVEs present

We will have an option "more info" which will show other details of the CVE

[SinghHrmn]

I want to correct one thing List of CVEs will be replaced by List of Products with Known Vulnerability

[darcyshx]

From my use case of the cve-bin-tool, which is using it to scan whole repositories from several different projects, the most beneficial improvement to the report would be for it to indicate what files the CVEs are found in.

For example, I use the cve-bin-tool to scan /repo-root/ , which contains /repo-root/versionx/cross-packages/package.tar.xz , which contains /versionx/subdir1/subdir2/ccl , which contains zlib 1.2.8
The current report for that scan will simply let me know that somewhere under /repo-root/ some file contains zlib 1.2.8.
It would be much more beneficial for the report to indicate that zlib 1.2.8 was found in file /versionx/subdir1/subdir2/ccl which was found in file /repo-root/versionx/cross-packages/package.tar.xz

Currently to generate a usable report from the cve-bin-tool I have written the following wrapper script

#!/bin/bash

parse_tmp_paths() {
awk '$1~"^cve_bin_tool.TempDirExtractorContext" {
       if ($6~"^/tmp") {
         match($6,"^/tmp.*extracted",KEY) ;
         TMPHASH[$8]=TMPHASH[KEY[0]]" contains "gensub("^/tmp.*extracted","",1,$6) }
       else {TMPHASH[$8]=$6} }
     $7~"^/tmp" {match($7,"^/tmp.*extracted",KEY) ; sub(KEY[0],TMPHASH[KEY[0]]" contains ",$7)}
     $5~"^/tmp" {match($5,"^/tmp.*extracted",KEY) ; sub(KEY[0],TMPHASH[KEY[0]]" contains ",$5)}
     {print}' $1
}

DATE=`date +%F`

cve-bin-tool -x -l debug /srv/scan/repo 2>&1 | tee /srv/results/repo-debug-$DATE.log
parse_tmp_paths /srv/results/repo-debug-$DATE.log | grep -A1 -B1 "Known CVE" > /srv/results/repo-found-$DATE.log

This generates a report with entries like

cve_bin_tool.Scanner - INFO - /srv/scan/drupal/01.org/docroot/sites/default/files.tar.gz contains /files/libxml2-x86_64-3eaedba1b64180668fdab7ad2eba549586017bf3.zip contains /libxml2-x86_64/bin/libxml2.dll contains xml2 2.9.2

Instead of what is currently reported
cve_bin_tool.Scanner - INFO - /tmp/cve-bin-tool-kgwyjp6r/libxml2-x86_64-3eaedba1b64180668fdab7ad2eba549586017bf3.zip.extracted/libxml2-x86_64/bin/libxml2.dll contains xml2 2.9.2

[terriko]

Thanks, that's really helpful feedback. We aren't currently storing the filename anywhere so it can't percolate easily to the html report, but we could definitely store it in the data. @SinghHrmn did you want to take a stab at figuring out how best to do that? Maybe a second file -> component table stored during the scans (since obviously we output it we know at least that much) and then combined with the final data to give a list of affected files somewhere?

[SinghHrmn]

@terriko I'll look into the issue and figure out what's the best way. I guess we have this as our priority

[SinghHrmn]

@darcyshx @terriko I have been working on this enhancement and it looks like I'm on the right track. Here is an example output for given file structure

file structure

• tar_files.tar.gz
  • .
    • tar_files
      • python3.8.rpm
      • nessus.rpm
      • python-tests.rpm

Console Log

           INFO     cve_bin_tool.VersionScanner - ../tar_files.tar.gz contains /tar_files/nessus-libraries-2.2.11-16.fc29.aarch64.rpm    version_scanner.py:176
                    contains /usr/lib64/libnessus.so.2.2.11 is nessus 2.2.11
[21:39:09] INFO     cve_bin_tool.VersionScanner - ../tar_files.tar.gz contains /tar_files/python3-3.8.2_rc1-1.fc33.aarch64.rpm contains  version_scanner.py:176
                    /usr/bin/python3.8 is python 3.8.2

Example Screenshot

Is that what we want? Needs Opinions.

[Niraj-Kamdar]

@SinghHrmn you can also unpack directory tree instead of just unpacking extractable files.

../tar_files.tar.gz contains /tar_files/nessus-libraries-2.2.11-16.fc29.aarch64.rpm contains /usr/lib64/libnessus.so.2.2.11 is nessus 2.2.11

can be look like following

../tar_files.tar.gz contains tar_files contains nessus-libraries-2.2.11-16.fc29.aarch64.rpm contains usr contains lib64 contains libnessus.so.2.2.11 is nessus 2.2.11

Since that don't look visually appealing we can denote contains by ->.

'../tar_files.tar.gz -> tar_files -> nessus-libraries-2.2.11-16.fc29.aarch64.rpm -> usr -> lib64 -> libnessus.so.2.2.11 is nessus 2.2.11'

We may have different color for directory, archive and file so that we can distinguish that.

[terriko]

@SinghHrmn 's gsoc project has covered this extensively!