Summary table

[knqyf263]

Description

Initially, Trivy was developed with the goal of being a very small tool, adhering to the Unix philosophy. Following the principle that silence is golden, especially when no vulnerabilities were found, Trivy didn't output anything. However, this approach led many users to feel anxious, wondering if the scanning process was being performed correctly.

• fix(report): hide empty tables if all vulns has been filtered #6352
• Vulnerabity scan produces report without summary and for json without "Results/Vulnerabities" node #6487
• fix(lang): Always include the "Results" section in the output JSON even if no vulnerabilities are detected #6081
• newb question about reporting #6282
• Table output shows no summary if no vulnerability is detected #4277

To address this concern, we made a change to display the results for OS packages even when there were zero vulnerabilities. Unfortunately, this decision caused further confusion due to the differences between OS packages and language-specific packages. The reason behind this decision was that language-specific packages could potentially generate a large amount of output. Displaying a separate table for each file, even if there were zero vulnerabilities, would result in an overwhelming amount of output.

Therefore, what if introducing a summary table at the beginning of all the tables, like the one shown below? In this summary table, we would display the results even when there are zero vulnerabilities, while keeping the individual tables hidden as before.

Summary Report for Vulnerabilities
+======================================================+========+=================+
|                         Name                         |  Type  | Vulnerabilities |
+======================================================+========+=================+
| debian:11                                            | os     |              52 |
+------------------------------------------------------+--------+-----------------+
| app1/package-lock.json                               | npm    |               2 |
+------------------------------------------------------+--------+-----------------+
| app2/package-lock.json                               | npm    |               0 |
+------------------------------------------------------+--------+-----------------+
| app/app.jar/BOOT-INF/lib/foo1.jar                    | jar    |               0 |
+------------------------------------------------------+--------+-----------------+
| app/app.jar/BOOT-INF/lib/foo2.jar                    | jar    |               0 |
+------------------------------------------------------+--------+-----------------+
| app/app.jar/BOOT-INF/lib/foo3.jar                    | jar    |               0 |
+------------------------------------------------------+--------+-----------------+
| python3.8/site-packages/bar-1.1.1.dist-info/METADATA | python |               1 |
+------------------------------------------------------+--------+-----------------+
| python3.8/site-packages/baz-2.2.2.dist-info/METADATA | python |               0 |
+------------------------------------------------------+--------+-----------------+

In the above example, separate tables are shown only for debian:11, app1/package-lock.json and python3.8/site-packages/bar-1.1.1.dist-info/METADATA. Others are hidden.

Target

None

Scanner

Vulnerability

[knqyf263]

@aquasecurity/trivy @DmitriyLewen @nikpivkin Please let me know if you have any feedback.

[simar7]

Nice! I like it but since we are talking on broader terms, how about we extend this discussion to make the same argument for other scanners? I can also see the misconfiguration scanner showing similar output. The same argument if "Trivy has actually scanned something or not" is present in misconfiguration scanner as well, especially when people have mixed IaC codebases.

[knqyf263]

Yes, I wanted to hear your thoughts regarding misconfiguration. I mention vulnerability because I have seen the question many times, especially in vulnerability, but if it is useful to show it in misconfiguration, then, of course, we should add it.

On the other hand, as for secret scanning, it is impossible to display such a table because all plaintext files are scanned.

Licensing is even more complicated, so let's leave it at that for once and see how the community reacts 😄 For example, I added --show-suppressed for vulnerability scanning, but the community is now trying to apply it to secret and license scanning.
#6483

[DmitriyLewen]

+------------------------------------------------------+--------+-----------------+
| app/app.jar/BOOT-INF/lib/foo1.jar | jar | 0 |
+------------------------------------------------------+--------+-----------------+
| app/app.jar/BOOT-INF/lib/foo2.jar | jar | 0 |
+------------------------------------------------------+--------+-----------------+
| app/app.jar/BOOT-INF/lib/foo3.jar | jar | 0 |
+------------------------------------------------------+--------+-----------------+
| python3.8/site-packages/bar-1.1.1.dist-info/METADATA | python | 1 |
+------------------------------------------------------+--------+-----------------+
| python3.8/site-packages/baz-2.2.2.dist-info/METADATA | python | 0 |
+------------------------------------------------------+--------+-----------------+

I'm thinking about packet aggregation again. We may also need to use our logic to aggregate package for this table.
for example, when user scans your system or image using Java application, this table can be very long.

The rest looks great.
As next update, we can hide file tables by default and add a flag to show those tables.

[knqyf263]

for example, when user scans your system or image using Java application, this table can be very long.

One file is one line, which I think is tolerable. One table per file can be too long, though.