Trivy Overloaded When Multiple Projects Are Uploaded Without Delay

[LaVibeX]

Current Behavior

When uploading 200 projects sequentially via the API without introducing any delay, the analyzers successfully assign vulnerabilities to the components, Trivy takes significantly longer—sometimes exceeding 10 minutes per project.

Adding a reasonable delay between uploads (e.g., 50 seconds in my case) allows Trivy to react and function properly.

Steps to Reproduce

1. Sequentially upload 200 projects via the API, waiting for a server response after each upload.
2. Observe that vulnerabilities are assigned to components initially, but Trivy becomes stuck after some time.
3. Retry with a delay (e.g., 50 seconds) between uploads.
4. Observe that Trivy processes all projects successfully.

Expected Behavior

Trivy should handle sequential project uploads with processing times comparable to other analyzers.

Actual Behavior

Trivy takes significantly longer to process projects than other analyzers when handling sequential uploads without delay. This creates a bottleneck in vulnerability assignment and slows down the overall process.

Dependency-Track Version

4.12.2

Dependency-Track Distribution

Executable WAR

Database Server

PostgreSQL

Database Server Version

No response

Browser

Mozilla Firefox

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this defect was already reported

[nscuro]

When you say:

Trivy becomes unresponsive and fails to process further

Do you mean the Trivy integration, or specifically Trivy itself? As in we are likely sending too many requests? Is it getting stuck or is it just slowing down?

[LaVibeX]

Hi @nscuro,

I was referring to the Trivy integration as a whole, not Trivy itself. Actually, after observing the behavior more closely, I noticed that Trivy doesn’t get stuck but slows down significantly compared to other analyzers.

For example, while most analyzers finish processing in seconds, Trivy took over 10 minutes or more per project in some cases. This happens when a lot of sequential requests are sent.

[valentijnscholten]

So we are the delays. Inside Dependency Track or inside Trivy? Are you running a self hosted Trivy?

[LaVibeX]

Yes, I’m running a self-hosted Trivy instance. What I’ve observed is that vulnerabilities from other analyzers appear significantly faster in Dependency Track Project than those from Trivy. How can I know from where the delays are coming?

[nscuro]

Given the current threading model, uploading 200 BOMs in short succession could lead to all worker threads performing Trivy analysis at the same time. On a system with a 4 core CPU you have 16 worker threads per default (workerThreadCount = cpuCoreCount * 4).

I have never personally tested if Trivy has any limitations on that front. But of course we can't exclude our analyzer being the culprit.

@fnxpt Did you encounter this before in your usage?

[fnxpt]

Not sure, we recently imported 2000 projects and it took a while but from what I could see the issue was not trivy it self, maybe there is some improvements we can do to improve this...