Reduce internet traffic

[AvdeevArtem]

Hello. I use trivy-operator and it uses a lot of outbound traffic to internet because every time when scan job runs it ALWAYS updating vulnerability database. I read Readme in https://github.com/aquasecurity/trivy-db repo and I saw that it automatically update vulnerability database in trivy-db image(this workflow does it).
trivy-operator in my configuration is in a standalone mode. For reducing outbound traffic I've already cached image public.ecr.aws/aquasecurity/trivy-db:2 on my nodes and use VPC Endpoint to ECR(This is AWS feature to reduces internet traffic)
Is it possible not to update vulnerability db every time?(I can't override it there

trivy-operator version - [v0.26.1](https://github.com/aquasecurity/trivy-operator/releases/tag/v0.26.1)
kubernetes version - 1.32
trivy version - 0.62.1
command for scanning - filesystem (it's reduce outbound traffic neither, because scan job run exactly where it detected new image and use node images local cache)

This is scan job init container logs.

scan-vulnerabilityreport-58cd6b6f75-s7s4c 2025-05-28T05:29:01.286214913Z 2025-05-28T05:29:01Z	INFO	[vulndb] Need to update DB
scan-vulnerabilityreport-58cd6b6f75-s7s4c 2025-05-28T05:29:01.286272324Z 2025-05-28T05:29:01Z	INFO	[vulndb] Downloading vulnerability DB...
scan-vulnerabilityreport-58cd6b6f75-s7s4c 2025-05-28T05:29:01.286279414Z 2025-05-28T05:29:01Z	INFO	[vulndb] Downloading artifact...	repo="public.ecr.aws/aquasecurity/trivy-db:2"
scan-vulnerabilityreport-58cd6b6f75-s7s4c 2025-05-28T05:29:13.264834920Z 13.02 MiB / 64.37 MiB [------------>________________________________________________] 20.23% ? p/s ?25.73 MiB / 64.37 MiB [------------------------>____________________________________] 39.97% ? p/s ?37.17 MiB / 64.37 MiB [----------------------------------->_________________________] 57.75% ? p/s ?48.42 MiB / 64.37 MiB [------------------------------------>___________] 75.23% 60.10 MiB p/s ETA 0s57.42 MiB / 64.37 MiB [------------------------------------------>_____] 89.21% 60.10 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 60.10 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 57.93 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 57.93 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 57.93 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 54.19 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 54.19 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 54.19 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 50.70 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 50.70 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 50.70 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 47.43 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 47.43 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 47.43 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 44.37 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 44.37 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 44.37 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 41.50 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 41.50 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 41.50 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 38.83 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 38.83 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 38.83 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 36.32 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 36.32 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 36.32 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 33.98 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 33.98 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 33.98 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 31.79 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 31.79 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 31.79 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 29.73 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 29.73 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 29.73 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 27.82 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 27.82 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 27.82 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 26.02 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 26.02 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 26.02 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 24.34 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 24.34 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 24.34 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 22.77 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 22.77 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 22.77 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 21.30 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 21.30 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 21.30 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------->] 100.00% 19.93 MiB p/s ETA 0s64.37 MiB / 64.37 MiB [---------------------------------------------------] 100.00% 5.93 MiB p/s 11s2025-05-28T05:29:13Z	INFO	[vulndb] Artifact successfully downloaded	repo="public.ecr.aws/aquasecurity/trivy-db:2"

Can you give me advice how to reduce outbound traffic for that?
if it updates trivy-db every 6 hours why we should download db every time?
Thank you!

[simar7]

hi @AvdeevArtem - thanks for the question. I think we need to rethink the strategy of how the db is used today. As you mentioned it's redownloaded each time, which is quite wasteful as the DB doesn't update more than every 6 hours.

@afdesk and I will think about potential ways to solve this. We can keep this discussion open to discuss that.

[AvdeevArtem]

What if we add templating for this part of the code -

trivy-operator/pkg/plugins/trivy/filesystem.go

Line 136 in aabc9ab

"--download-db-only",

?

If users don't want to upgrade their database each time, they could just override a variable in the Helm chart like "trivy.skipVulnerabilityDatabaseUpdate = true" and if it true use --skip-db-update. This would mean that the Trivy init container would just use the trivy-db database cache from the image which it downloads.

[afdesk]

@AvdeevArtem that's an interesting idea. thanks

However, the Trivy scan cannot function without the database, so we need a method to deliver it.

[itaysk]

this is similar to the "airgap" scenario with trivy, where users are responsible for obaining and maintaining an up to date db. If we want to support an airgap scenario for operator, the operator should just support the --skip-db-update flag (or better, a functioning --offline-scan flag), and the user should use whatever means (e.g trivy --downloads-db-only / docker pull) to obtain the latest db.

[simar7]

I think the discussion drifted a bit into discussing how we can store the db longterm.

From my understanding, downloading the DB on each operator scan is a bit excessive and adds to the strain on the availability for trivy-db for all other users. Given trivy-operator today supports large environments, this can add up over time.

Trivy CLI standalone today caches the db on disk. A similar analogy in a Kubernetes setup would be to cache the db within the cluster. This is a bit different from an air gap solution as the user isn't supplying the db but instead we're reducing the amount of times the db will be downloaded.

Of course as part of this improvement, we could add the support for an air gap operator setup, where the user can directly supply the DB themselves.

[itaysk]

I just think we have other priorities rn besides maintaining an in cluster registry to host the database. since there is a workaround -following the airgap model (not for the sake of restricting internet connectivity), I think this can be a good compromise. BTW just to make it clear what I mean, it's essentially that the user will maintain a shared volume for cache and mount it to trivy jobs