trivy.db not downloaded although file not there

[tom1299]

Description

When the trivy.db has been deleted but the metadata.json has not, and the database has not yet expired, the database is not downloaded, wich may result in a failed scan. Steps and logs to reproduce:

1. Download db only
2. Delete trivy.db
3. Download db only again:

$ trivy -d --cache-dir /tmp/trivy-cache image --download-db-only -
-db-repository ghcr.io/aquasecurity/trivy-db
2025-08-21T14:49:46+02:00       DEBUG   No plugins loaded
2025-08-21T14:49:46+02:00       DEBUG   Default config file "file_path=trivy.yaml" not found, using built in values
2025-08-21T14:49:46+02:00       DEBUG   Cache dir       dir="/tmp/trivy-cache"
2025-08-21T14:49:46+02:00       DEBUG   Cache dir       dir="/tmp/trivy-cache"
2025-08-21T14:49:46+02:00       INFO    Adding schema version to the DB repository for backward compatibility     repository="ghcr.io/aquasecurity/trivy-db:2"
2025-08-21T14:49:46+02:00       DEBUG   Parsed severities       severities=[UNKNOWN LOW MEDIUM HIGH CRITICAL]
2025-08-21T14:49:46+02:00       DEBUG   Ignore statuses statuses=[]
2025-08-21T14:49:46+02:00       DEBUG   DB update was skipped because the local DB is the latest
2025-08-21T14:49:46+02:00       DEBUG   DB info schema=2 updated_at=2025-08-21T06:28:10.725857663Z next_update=2025-08-22T06:28:10.725857382Z downloaded_at=2025-08-21T07:37:40.764772374Z
$ rm /tmp/trivy-cache/db/trivy.db
trivy -d --cache-dir /tmp/trivy-cache image --download-db-only --db-repository ghcr.io/aquasecurity/trivy-db
2025-08-21T14:50:38+02:00       DEBUG   No plugins loaded
2025-08-21T14:50:38+02:00       DEBUG   Default config file "file_path=trivy.yaml" not found, using built in values
2025-08-21T14:50:38+02:00       DEBUG   Cache dir       dir="/tmp/trivy-cache"
2025-08-21T14:50:38+02:00       DEBUG   Cache dir       dir="/tmp/trivy-cache"
2025-08-21T14:50:38+02:00       INFO    Adding schema version to the DB repository for backward compatibility     repository="ghcr.io/aquasecurity/trivy-db:2"
2025-08-21T14:50:38+02:00       DEBUG   Parsed severities       severities=[UNKNOWN LOW MEDIUM HIGH CRITICAL]
2025-08-21T14:50:38+02:00       DEBUG   Ignore statuses statuses=[]
2025-08-21T14:50:38+02:00       DEBUG   [vulndb] There is no db file
2025-08-21T14:50:38+02:00       DEBUG   DB update was skipped because the local DB is the latest
2025-08-21T14:50:38+02:00       DEBUG   DB info schema=2 updated_at=2025-08-21T06:28:10.725857663Z next_update=2025-08-22T06:28:10.725857382Z downloaded_at=2025-08-21T07:37:40.764772374Z

Note the debug messages:

2025-08-21T14:50:38+02:00       DEBUG   [vulndb] There is no db file
2025-08-21T14:50:38+02:00       DEBUG   DB update was skipped because the local DB is the latest

As a result the database is not downloaded.

Desired Behavior

If the trivy.db could not be found it should be downloaded regardless whether metadata.json expiration has not yet been reached.

Actual Behavior

trivy-db was not downloaded

Reproduction Steps

1. trivy -d --cache-dir /tmp/trivy-cache image --download-db-only --db-repository ghcr.io/aquasecurity/trivy-db
2. rm /tmp/trivy-cache/db/trivy.db
3. trivy -d --cache-dir /tmp/trivy-cache image --download-db-only --db-repository ghcr.io/aquasecurity/trivy-db

Target

Container Image

Scanner

Vulnerability

Output Format

None

Mode

Standalone

Debug Output

See above

Operating System

Fedora

Version

$ trivy --version
Version: 0.65.0

Checklist

• Run trivy clean --all
• Read the troubleshooting

[tom1299]

Looking at the code here in db.go, I would say that the method should return true in any case even if the metadata.json is still there and the database does not need to be renewed yet. Or is there something I am not aware about ?

[simar7]

It's an interesting edge case. Re-downloading the DB regardless might not be so straightforward as there's the case to be made for the air gap setup. In such a scenario what you have described might actually be the case if the user is supplying the DB themselves.

[tom1299]

We are using the trivy-operator and have configured it to run multiple scan jobs in parallel if needed. The jobs share a volume for the databases so that it is not downloaded every time. Sometimes the operator starts multiple jobs at nearly the same time. And I suspect that in the case when the database has expired and multiple jobs run in parallel, the condition occurred where trivy.db was deleted while metadata.json was updated.
I think that the logic in the method NeedsUpdate leaves the system in an inconsistent state when trivy.db is not there but metadata.json still is and has not yet expired. Is that anyway a state which would be valid ?
But actually I would be happy already if there would be a log message. It would make troubleshooting much easier 🙂

[simar7]

I suspect that in the case when the database has expired and multiple jobs run in parallel, the condition occurred where trivy.db was deleted while metadata.json was updated.

Would you know why the db is deleted in this case?

[tom1299]

Unfortunately I can not say exactly why the database was deleted and the metadata file remained. I saw that the old database and metadata file is deleted here before the download starts. So I would suspect a race condition where several jobs tried to downlaod the database and one deleted the new database file after it had already been downloaded by another job. It's really an edge case since the metadata file was not deleted.

[tom1299]

@simar7 I created a draft PR #9393 with a possible fix. I also added a test case for this edge case. Would that be an appropriate way to solve this problem ?