feat: add report summary table

[knqyf263]

This PR introduces a summary table that displays all scan results, including those with zero findings, such as vulnerabilities and misconfiguration, to improve visibility and reduce user anxiety about the scanning process.

Background

Historically, Trivy followed the Unix philosophy where "silence is golden" and didn't output anything when no vulnerabilities were found. However, this led to user confusion about whether scans were working correctly. While we previously addressed this by showing results for OS packages with zero vulnerabilities, the inconsistency between OS and language-specific package outputs has created new confusion.

Proposed Changes

This PR adds a summary table at the beginning of the output that:

• Shows all scanned targets regardless of security finding count
• Maintains the current behavior of only showing detailed tables for items with findings
• Provides a clear overview of the entire scan scope

Example output:

trivy fs . --scanners vuln,misconfig,secret --skip-dirs pkg,integration --severity CRITICAL,HIGH

Considerations

1. Aggregated Results for Individual Files

   • Currently, archive files (like JARs) and individual files (like .gemspec) show aggregated results without displaying vulnerability counts for individual files
   • Implementing per-file vulnerability counts would require significant changes
   • Proposal: Address this enhancement in a separate PR to keep the current changes focused

2. Result Aggregation Strategy

   • Current implementation shows separate rows for different finding types (e.g., vulnerabilities and secrets) in the same file
   • We could potentially aggregate these into a single row
   • However, this raises questions about:
     • How to represent multiple types in a single row
   • This PR maintains the current separation to keep the implementation straightforward

3. Default Behavior

   • Proposal: Enable summary table by default with an opt-out flag (e.g. --no-summary-table)
   • Rationale: Reduces user confusion and provides immediate feedback about scan coverage
   • Alternative: Opt-in approach with --show-summary-table

Implementation Notes

• This is a minimal PoC implementation focused on establishing the basic functionality
• Future enhancements can build upon this foundation to address the discussion points above

TODOs

• Add summary table
• Add --no-summary-table
• Add tests
• Update documentation

Related issues

• Summary table #6501

Checklist

• I've read the guidelines for contributing to this repository.
• I've followed the conventions in the PR title.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).

[knqyf263]

@DmitriyLewen @nikpivkin Before further development, I'd like to hear your thoughts.

[DmitriyLewen]

Aggregated Results for Individual Files
Proposal: Address this enhancement in a separate PR to keep the current changes focused

I agree with you. I think we need to discuss this. Initially (I may be wrong) Trivy was crippled by aggregating individual packages to avoid having too many tables in a report.
After adding summary table, we can consider removing the logic for aggregating packages entirely. This will simplify the code more and avoid difficulties when converting reports between formats.

Current implementation shows separate rows for different finding types (e.g., vulnerabilities and secrets) in the same file
This PR maintains the current separation to keep the implementation straightforward

It seems that having multiple types for a single file is rare, so I suggest using this logic and waiting for feedback from users.

Proposal: Enable summary table by default with an opt-out flag (e.g. --no-summary-table)

I prefer this way.

I also have one idea - some users don't need to see vulnerability/misconfiguration numbers (CVE etc). So we can hide other tables by default and show them only when using a new flag (--show-report-tables or something like that). Or vice versa hide them by flag if users only need summary numbers.
But I think we need to ask users about it.

---

As a future update:

• What if we check the enabled scanners and show only the required columns?
  eg by default the summary table will only include the vulnerability and secret columns.
  or for misconfig mode only the misconfigutation column.

[nikpivkin]

I like the idea, the summary table looks good. Should the results be sorted by file name or scan type?

I noticed that terraform scan results contain directories that we should get rid of.

[knqyf263]

After adding summary table, we can consider removing the logic for aggregating packages entirely. This will simplify the code more and avoid difficulties when converting reports between formats.

Exactly. It will simplify our logic. However, it will probably break something. We should carefully announce it. That's why I didn't want to add the change into this PR.

What if we check the enabled scanners and show only the required columns?

I already implemented it in this PR unless I'm making a mistake. In the screenshot, Vulnerabilities, Misconfigurations and Secrets are shown because --scanners vuln,misconfig,secret is specified.

[knqyf263]

Should the results be sorted by file name or scan type?

The current summary table is ordered by scanners, vulnerabilities -> misconfigurations -> secrets -> licenses. Do you want to sort by sub-scanners, such as terraform?

I noticed that terraform scan results contain directories that we should get rid of.

Yes, I actually saw . was detected as terraform-plan.

[DmitriyLewen]

I already implemented it in this PR unless I'm making a mistake. In the screenshot, Vulnerabilities, Misconfigurations and Secrets are shown because --scanners vuln,misconfig,secret is specified.

Great!

[itaysk]

looks great. this is very similar to the k8s summary report. Do you think we should consider reusing the experience, code or flags? (either way, new, existing or something in between)

[simar7]

Looks nice. What's the difference between a - and a 0?

I think I understand it as not evaluated and evaluated but nothing found respectively but I think we should make it explicit.

looks great. this is very similar to the k8s summary report. Do you think we should consider reusing the experience, code or flags? (either way, new, existing or something in between)

I think we should change k8s summary output to be more simpler rather than the other way around. To me the k8s summary output is a bit too much especially with so many numbers that it isn't very helpful.