Failing a --download-db-only run, deletes db/metadata.json, causing consequent --skip-db-update scans to fail.

[Mikael-Gustavsson]

Description

Trying, and failing, to update the database removes the file metadata.json from the database folder. This is a problem in airgapped scenarios, where db-update is separate from scans. After which, all regular scans will fail with error:

ERROR	[vulndb] The first run cannot skip downloading DB

Desired Behavior

Leave the file metadata.json as is, on disk, until it can be refreshed with new valid content.

Actual Behavior

The file metadata.json is removed from disk.

Reproduction Steps

Prerequizite: db-folder contains a database file and the file metadata.json. Disconnect computer from the internet.

1. Initialize update using commandline:
    trivy.exe sbom  --download-db-only --cache-dir .
2. Let command time out.
3. Review content of the db folder, the file db/metadata.json is gone.
4. Any regular scans after the fact will fail with error

    ./trivy.exe sbom  --cache-dir . --offline-scan  --skip-db-update --skip-java-db-update mySbomFile
    ERROR	[vulndb] The first run cannot skip downloading DB

Target

SBOM

Scanner

Vulnerability

Output Format

Table

Mode

Standalone

Debug Output

./trivy.exe sbom --download-db-only --cache-dir . --debug

2025-04-28T11:16:13+02:00	DEBUG	No plugins loaded
2025-04-28T11:16:13+02:00	DEBUG	Default config file "file_path=trivy.yaml" not found, using built in values
2025-04-28T11:16:13+02:00	DEBUG	Cache dir	dir="d:\\trivy"
2025-04-28T11:16:13+02:00	DEBUG	Cache dir	dir="d:\\trivy"
2025-04-28T11:16:13+02:00	DEBUG	Parsed severities	severities=[UNKNOWN LOW MEDIUM HIGH CRITICAL]
2025-04-28T11:16:13+02:00	DEBUG	Ignore statuses	statuses=[]
2025-04-28T11:16:13+02:00	INFO	[vulndb] Need to update DB
2025-04-28T11:16:13+02:00	INFO	[vulndb] Downloading vulnerability DB...
2025-04-28T11:16:13+02:00	INFO	[vulndb] Downloading artifact...	repo="mirror.gcr.io/aquasec/trivy-db:2"
2025-04-28T11:16:43+02:00	FATAL	Fatal error
  - init error:
    github.com/aquasecurity/trivy/pkg/commands/artifact.Run
        /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:383
  - DB error:
    github.com/aquasecurity/trivy/pkg/commands/artifact.NewRunner
        /home/runner/work/trivy/trivy/pkg/commands/artifact/run.go:120
  - failed to download vulnerability DB:
    github.com/aquasecurity/trivy/pkg/commands/operation.DownloadDB
        /home/runner/work/trivy/trivy/pkg/commands/operation/operation.go:41
  - OCI artifact error:
    github.com/aquasecurity/trivy/pkg/db.(*Client).Download
        /home/runner/work/trivy/trivy/pkg/db/db.go:172
  - failed to download vulnerability DB:
    github.com/aquasecurity/trivy/pkg/db.(*Client).downloadDB
        /home/runner/work/trivy/trivy/pkg/db/db.go:221
  - failed to download artifact from mirror.gcr.io/aquasec/trivy-db:2:
    github.com/aquasecurity/trivy/pkg/oci.Artifacts.Download
        /home/runner/work/trivy/trivy/pkg/oci/artifact.go:238
  - OCI repository error:
    github.com/aquasecurity/trivy/pkg/oci.(*Artifact).populate
        /home/runner/work/trivy/trivy/pkg/oci/artifact.go:97
  - 1 error occurred:
	* Get "https://mirror.gcr.io/v2/": net/http: TLS handshake timeout

Operating System

windows server 2019

Version

Version: 0.61.0

Checklist

• Run trivy clean --all
• Read the troubleshooting

[DmitriyLewen]

Hello @Mikael-Gustavsson
thanks for your report!

IIUC there was a reason why we remove metadata.json before downloading trivy-db.

But now we use go-getter, which downloads to temp dir and then copies to cache dir.
if i understand correctly we can no longer delete metadata before downloading.

I have tried skipping the removal metadata.json - it looks like works correctly (but I haven't checked it thoroughly)

@knqyf263 am i missing something?

[knqyf263]

If the database copy is canceled in the middle and the database becomes corrupted, a panic will occur (it will be recovered, though).

$ trivy image debian:11
2025-05-07T15:46:10+04:00 FATAL    Fatal error     run error: init error: DB error: error in vulnerability DB initialize: db corrupted: runtime error: invalid memory address or nil pointer dereference

We currently determine whether the previous download was successful by checking for the presence of metadata.json. If we can avoid this issue by another method, we won’t have to delete metadata.json.

[DmitriyLewen]

I forgot about that. Thanks for explaining!

[knqyf263]

Since DownloadedAt is only updated after a successful download, it might be better to check whether DownloadedAt is empty instead of checking the presence of metadata.json. This approach should also handle cases where metadata.json was downloaded correctly, but the database download (specifically, the copy from tmp) was interrupted and ended up corrupted.

And in cases like this report, where the download completely fails while offline, the previous metadata.json remains and the DownloadedAt field is still populated, so if you specify --skip-db-update, the database will not be re-downloaded.

[DmitriyLewen]

created #8864