[Java/Maven] Filesystem scan runs into 429 - Too many requests

[AB-xdev]

Description

Trivy frequently runs into the following (hidden) error when scanning a pom.xml and resolving dependencies:

2026-05-18T08:00:32Z    DEBUG   [pom] Failed to fetch   url="https://repo.maven.apache.org/maven2/io/micronaut/platform/micronaut-parent/4.10.14/micronaut-parent-4.10.14.pom" statusCode=429

Desired Behavior

Retry on 429

Actual Behavior

2026-05-18T08:00:32Z    WARN    [pom] Dependency version cannot be determined. Child dependencies will not be found.
2026-05-18T08:00:32Z    DEBUG   [pom] Dependency version cannot be determined.  GroupID="io.micronaut" ArtifactID="micronaut-http-server-netty"
2026-05-18T08:00:32Z    DEBUG   [pom] Dependency version cannot be determined.  GroupID="io.micronaut" ArtifactID="micronaut-jackson-databind"
...

Reproduction Steps

1. Download a Maven project, e.g. https://micronaut.io/launch/
2. Run a Trivy scan using: `trivy -debug fs <pathToProject>`

Target

Filesystem

Scanner

None

Output Format

None

Mode

None

Debug Output

relevant outputs have been described above

Operating System

Docker

Version

0.70.0

Checklist

• Run trivy clean --all
• Read the troubleshooting

[DmitriyLewen]

Hello @AB-xdev
Thanks for your report!

For artifacts that are not in the local cache — Trivy downloads them from Maven Central to get the full list of dependencies.

It looks like Maven has tightened their rate limits (https://central.sonatype.org/faq/429-error/), which is why you are seeing this error.
We could try adding a retry on 429 errors, but if I understand correctly, this won't help in this scenario:
in most cases, if Trivy is downloading artifacts, it means the local cache is empty. This means Trivy needs to download all related dependencies, which are likely very numerous. After a few retries, Trivy will "inflate" the block duration (https://central.sonatype.org/faq/429-error/#how-long-do-blocks-last) and will time out.
I recommend download artifacts into local cache before scanning. This will speed up the scan and help avoid the 429 error.

Regards, Dmitriy

[DmitriyLewen]

track #10691

[jerrac]

I just ran into the 429 error and the message that you added recently.

The recommended action is to populate the local cache first, right?

I don't even have maven installed. I assume Trivy has it built in? From what I can tell Trivy is calling it because I'm running ApacheDirectoryStudio, Jetbrains IDEs, and have a java git repo or two checked out that are not being worked on. I really don't want to install maven just to get past this.

Do I have to exclude every single directory with something Java in it before I can get a scan to complete? Or is there a way to just skip maven stuff?

[DmitriyLewen]

Hello @jerrac

mvn is not built into Trivy.

We only try to reproduce the behavior of mvn so that Trivy works "out of the box".

Regarding your case:
Currently there is no way to disable individual analyzers, so you need to use skip-dirs and/or skip-files to skip scanning Maven repositories (or pom.xml files).

[jerrac]

For my initial case, I just ended up removing all the java repos and that got me past it.

I did do a bit more testing though.

In a test vm, I installed maven, added a large git repo with lots of java dependencies, and the tried scanning it with trivy. Ran into the 429 error. Then, I tried running mvn compile, and that was able to download things with no issues.

I guess that explains the work around I saw mentioning populating the maven cache before running trivy. (That doesn't seem to work due to trivy not using the already downloaded data? I don't know enough about how java development really goes to tell.) I was wondering how that'd work if requests were being throttled. Apparently mvn requests aren't throttled. :.

My concern with the current way things work is that Trivy stops scanning as soon as it hits the 429 error. This means that if you develop Java apps and use Maven, then you can't use Trivy, or at the very least, you have to exclude all your development files. Which kinda defeats the entire point of Trivy....

Then, in cases like mine, where I'm not a Java developer, but I end up with some repos floating around, the presence of those repos prevents Trivy from working until I track down every directory causing problems and exclude it. Then, down the road, since I'm automatically excluding all those directories, if something non-java related goes into (or replaces) one of the excluded directories it will never get scanned. Which leaves an extra vulnerable location on my system.

The only solutions I can think of would be for the throttling to be lifted, or for Trivy to have a way to continue scanning even when it hits a 429 error.

Personally I'd like to tell Trivy to autoskip any files/directories that can't be scanned for whatever reason, then include in the report data a list of those skipped items. Then I can decide if I want to keep skipping them, or something else.

But if I recall correctly, the developers (you and your team) prefer to just end the scan when hitting that kind of error. But I can't recall exactly why... Anyway, I'll leave that up to them. --skip-dirs and --skip-files will have to do for now.

[DmitriyLewen]

Hi!

Thank you for the information about how you use Trivy and your opinion on the 429 error.

Trivy can work with the mvn cache and successfully retrieves packages from the local .m2 repository. Therefore this is the most stable solution. That is why Java developers scanning a local repository during development should not have any issues, as all dependencies are likely already downloaded to the cache.

Regarding the error or continuation of work — we discussed possible solutions to the current situation within the team. The main problem is that we don't have (except for an error) a reliable way to communicate to the operator that the list of vulnerabilities for a Java application is incomplete. Adding logs is not a good option, since many users run Trivy in their pipelines and would then need to come up with separate logic for checking logs.
And a missed notification about an incomplete report + missed vulnerabilities due to a 429 error create a false sense of security.

At the moment we are still in the process of finding a good solution. Thank you for your feedback.

[jerrac]

FYI, by "log the skip" I meant add a section to the report about skipped files/dirs. Not just emit a normal log message. Then people could add logic checking the report for skipped files/dirs to however they parse the reports.