Add Trivy Version, Trivy-DB date/version, Java-DB date/version to output

[wagner-robert]

Description

All, It will be difficult for an assessment team to accept the output from Trivy while it lacks some basic information - Add Trivy Version, Trivy-DB date/version, Java-DB date/version and Check details.
There will be considerable difference for disconnected systems running an old report/version versus a current version. I don't know if the detection will change from version to version.
An organization that requires monthly scans, using a current version (latest - .1), with current trivy-db files (within the last week) will not be able to tell if any of those requirements are being met. I don't see that data in the JSON output, so I don't know if those fields are available to templates.
We are looking at this tool for compliance scans, but it cannot be used without this data.

Target

None

Scanner

Vulnerability

[nikpivkin]

HI @wagner-robert !

Do you want to see information about component versions in the report (table or json)?

[wagner-robert]

The JSON would be a good start (for machine ingestion), followed by the table template (for human review). From there we will customize an internal template to include the data (I just need to know the field names).
Thanks in advance for any assistance in this matter.

[simar7]

It's not in the report as you mentioned but you could get it all by running the trivy version command.

trivy version --format json
{"Version":"0.64.0-54-g50bc4c2b1","VulnerabilityDB":{"Version":2,"NextUpdate":"2025-08-27T18:26:23.952100722Z","UpdatedAt":"2025-08-26T18:26:23.952100882Z","DownloadedAt":"2025-08-26T23:06:32.941928Z"},"CheckBundle":{"Digest":"sha256:6127ec64475c78cd2b044cc0acd585584f8386136f9f78353f151300192fdf59","DownloadedAt":"2025-08-27T01:11:17.861989Z"}}

trivy version  
trivy Version: 0.64.0-54-g50bc4c2b1
Vulnerability DB:
  Version: 2
  UpdatedAt: 2025-08-26 18:26:23.952100882 +0000 UTC
  NextUpdate: 2025-08-27 18:26:23.952100722 +0000 UTC
  DownloadedAt: 2025-08-26 23:06:32.941928 +0000 UTC
Check Bundle:
  Digest: sha256:6127ec64475c78cd2b044cc0acd585584f8386136f9f78353f151300192fdf59
  DownloadedAt: 2025-08-27 01:11:17.861989 +0000 UTC

[itaysk]

I think it's a good idea

[wagner-robert]

@simar7 Thanks for the option. I am aware of running the version information to get those details, but it would be more eloquent if this information was included in the image scan output - that way we don't need to request a second file or second command line run. This would also be useful for integration into down-stream tools that could detect old, obsolete version of Trivy running. As everyone knows, having a scanner that someone forgot to update may mislead one into believing there are no issues, when there may be several critical flaws that need remediation. Thanks again for looking into this.

[knqyf263]

It makes sense to me, although I don’t really like adding too much information to JSON because it makes it harder for users to see what they actually need. Having said that, I also don’t want to add a CLI flag just for this. So I think it will end up being the default output when --format json is specified.
@simar7 @nikpivkin @DmitriyLewen What do you think?

[DmitriyLewen]

I already thought about this earlier.
If the json report includes the trivy/trivy-db version, it will help us detect problems more easily and work with users.

Also, I think we can improve the JSON structure a little for this info:
we can check the enabled scanners and include only the required info:

• always include Trivy version
• include trivy-db and trivy-java-db versions for vuln scanner
• include trivy-checks for misconfig scanner and misconfig image-config-scanner

[simar7]

Yeah I agree with what @DmitriyLewen said. We can selectively show/omit the version fields that are relevant to the scan being performed for brevity.

[knqyf263]

I checked to see if it could be implemented easily, but I realized that the vulnerability database can be on the server side. In this case, the server needs to return the database information via the API. Also, Java DB in the future.
On the other hand, since the misconfiguration bundle is stored locally, it seems necessary to merge this information and include it in the report. In other words, because this involves modifying the API, it was not as simple as I initially thought.

[wagner-robert]

From a debugging standpoint, I am not sure if something like the binary hash or other metadata added to the JSON file would allow you to determine exactly which binary they are using (self-compiled vs Linux 86 vs Linux 64 vs MacOS etc...). This may assist with determining if there is a systemic issue with a particular pre-built or user-built binary.