Replies: 26 comments 57 replies
-
I get a similar error.
Can someone please look into this ASAP? |
Beta Was this translation helpful? Give feedback.
-
The rate limits are applied per organization, so creating a new repository (e.g., This is happening just because Trivy has too many users and reached the rate limits. The same problem could occur in other registries. We are trying to find a way, but currently, the only ways are to use ECR Public (we're still evaluating ECR Public, though) or self-host DBs on another registry, including a separate GitHub organization like this. |
Beta Was this translation helpful? Give feedback.
-
Over the past 1-2 days, I've started seeing CI/CD scan job failures with this error as well in our on-prem infrastructure (with a GitLab Runner using the Kubernetes executor). A big difference is that we scan via a Trivy server deployment (using the Trivy Helm chart), so the errors don't arise from pulling Java DBs, etc. |
Beta Was this translation helpful? Give feedback.
-
Same errors in our GitLab pipelines. v0.56.1 @knqyf263 Any info/docs on how exactly to configure trivy to do the workaround you mentioned (ECR)? Or better to wait? |
Beta Was this translation helpful? Give feedback.
-
Just adding my context: We're moving to using private AWS ECR Pull Through Caches for containers so that we have more visibility into the containers that are running, and so that we can disconnect environments where things are running from having public internet access. I'd love if a job running trivy could do everything it needs to do, without connecting to the public internet. AWS requires credentials to set up these caches for the upstream, and does sane things with ratelimiting. I was already working to have trivy pull things through caches instead of "upstream", but there is different config required for each of the different ways of using trivy (config, image, etc). I'd be totally happy for trivy to have a single configuration method for "use_this_repo" to allow us to maintain our own cache, but it'd be even better to have a |
Beta Was this translation helpful? Give feedback.
-
I'd like to add one more aspect that was touched upon but not made explicit by several comments above. If registries like GHCR and ECR make it difficult for Trivy users to access the DBs during high load, then why not ensure that the latest DB images are also hosted on Docker Hub? When they started their rate limiting nearly four years ago, the tooling and hosting ecosystem quickly adapted and introduced features like Harbor's Proxy Cache, GitLab's Dependency Proxy, and others, which are designed to mitigate upstream registry rate limiting, but work specifically and exclusively with Docker Hub at the moment, and not with GHCR etc. |
Beta Was this translation helpful? Give feedback.
-
Have the same problem but with the bundle-checks repository when running misconfiguration. |
Beta Was this translation helpful? Give feedback.
-
I am using the helm chart to deploy the operator on EKS and pointing to the AWS ECR for images and vulnerability DBs. For some reason, it still keeps going to ghcr.io. The CM seems to have been updated properly though. Below is my values.yml
And below is the error I am seeing still
|
Beta Was this translation helpful? Give feedback.
-
Most people here are talking about issues with the |
Beta Was this translation helpful? Give feedback.
-
i have the same issue with latest trivy version while executing stage with jenkins pipeline: |
Beta Was this translation helpful? Give feedback.
-
This is still an issue for me and my team. We updated all commands in our CI/CD scripts to specify the AWS ECR ( This tool is a critical part of our CI processes and it is very difficult for us to remove it. Are there any other workarounds for this issue that we can try? |
Beta Was this translation helpful? Give feedback.
-
This is still an issue for us.
Is there any timeline of when this issue will actually be solved? |
Beta Was this translation helpful? Give feedback.
-
Even with the workaround of setting Example command: $ TRIVY_DB_REPOSITORY=ghcr.io/aquasecurity/trivy-db,public.ecr.aws/aquasecurity/trivy-db trivy fs . The failures happen with both and with only one of the repos enabled:
Failure example:
Trivy version:
|
Beta Was this translation helpful? Give feedback.
-
Hello @nikpivkin Could you please guide me on this? |
Beta Was this translation helpful? Give feedback.
-
A lot of this doesn't make sense to me, my guess is the whole reason the databases are being distributed like this, is its some scheme to avoid paying transit costs, that has obviously broken down now that GitHub is rate limiting. This would probably have been better done by distributing the file via HTTP, via a good CDN like Cloudflare, where there are better tools for caching available. My workaround is to use an AWS ECR pull-through cache rule:
You just need the public_repo permission on the GitHub access token, and the token is required, but unfortunately having a token doesn't get you past the rate limit, because thats being imposed on the aquasecurity organization. One you have created the cache rule you need to "prime the pump" since you may be rate limited several times before getting a successful pull. When successful, you will see the message: "unsupported mediatype application/vnd.oci.empty.v1+json" because the Docker tools do not know how to parse these particular container images. If you are interested in inspecting the contents, use the command
Once the images exist you can do something like:
And you have to repeat that for every account/region combo where you need it because cross-account/cross-region access to ECR seems to be hard or not supported. But this is a PITA to have to set up and maintain so longer term I think aquasecurity ought to re-think if this overly elaborate scheme to distribute tar files is really the right way. |
Beta Was this translation helpful? Give feedback.
-
I get this error on CI even when the last run was a day ago. Maybe it's time to setup mirrors instead of just relying on GitHub. I'm up for hosting one. |
Beta Was this translation helpful? Give feedback.
-
My workaround for those with their own OCI compatible image registry (such as harbor).
oras doc: https://oras.land/docs/commands/oras_cp/ |
Beta Was this translation helpful? Give feedback.
-
Just to add my feedback, in order to be able to pull down from the aws ecr I had to do a firewall request. Which worked. but its now failing on trying to pull down one of the layers of the image - (snippet from the error) - oci download error: failed to fetch layer : GET https://d2glxk2uabbnd.cloudfront.net/..... now clearly that url is blocked at present. Now this isn't an issue I have seen before with the normal trivy db download... So any explanation or indeed expectation around additional firewall permissions be useful.. That said I think I'll just implement what @resamaraschi has done above. |
Beta Was this translation helpful? Give feedback.
-
Tagging my discussion because @miguno said above
but that doesnt seem to be case from what Ive seen in my personal git pipeline. |
Beta Was this translation helpful? Give feedback.
-
Can someone please cleanup this discussion? Finding the actual solution/workaround from #7668 (reply in thread) is quite hard... |
Beta Was this translation helpful? Give feedback.
-
Additional note: There is a PR in progress that aims to fix these problems: #7679 |
Beta Was this translation helpful? Give feedback.
-
I encountered the same issue while using GitHub Actions. Caching the Trivy database in the GitHub Workspace and reusing it during the scan process resolved the problem for me. Here's the caching guide: https://github.com/aquasecurity/trivy-action?tab=readme-ov-file#updating-caches-in-the-default-branch |
Beta Was this translation helpful? Give feedback.
-
Same issue with GitlabCI, this is starting to get very problematic. |
Beta Was this translation helpful? Give feedback.
-
Jenkins Pipeline: Same issue..... Why not have a user create a free user account, confirm email. and then distribute a token ? Attach the token to the ENV variables and have trivy pick it up.. 16:29:41 2024-11-12T13:29:41-08:00 INFO [vulndb] Need to update DB |
Beta Was this translation helpful? Give feedback.
-
Hi all, we found 1 more way - #7538 (comment) |
Beta Was this translation helpful? Give feedback.
-
v0.57.1 with |
Beta Was this translation helpful? Give feedback.
-
Description
Hi, I'm the maintainer of MegaLinter, which heavily uses trivy in its core, but also in its own CI/CD jobs
For some weeks now, there are many fatal errors because of rate limit when downloading database, and this is impacting MegaLinter stability, at a point that we have to advise to disable trivy "until it is stable again"
init error: DB error: failed to download vulnerability DB: database download error: oci download error: failed to fetch the layer: GET https://ghcr.io/v2/aquasecurity/trivy-db/blobs/sha256:9eed63035e251610986ab4666a7ef45cfcf74e7f02daee94fe9958d1f7f2749b: TOOMANYREQUESTS: retry-after: 544.488µs, allowed: 44000/minute
I've read all issues & discussions about it, and all I see are workarounds
MegaLinter users can run MegaLinter on:
So the GITHUB_TOKEN solution does not work.
People also have existing MegaLinter config with their own arguments to call trivy, so I can't either force the AWS image to be used
The best solution I imagine is the following:
That way, Trivy would continue to work great without forcing user to implement clumsy workarounds :)
Do you think it's doable ? :)
Desired Behavior
Trivy to work perfectly everytime as before :)
Actual Behavior
If you are lucky, it work, but if you are not , it fails :/
Reproduction Steps
Target
Filesystem
Scanner
Vulnerability
Output Format
None
Mode
Standalone
Debug Output
`init error: DB error: failed to download vulnerability DB: database download error: oci download error: failed to fetch the layer: GET https://ghcr.io/v2/aquasecurity/trivy-db/blobs/sha256:9eed63035e251610986ab4666a7ef45cfcf74e7f02daee94fe9958d1f7f2749b: TOOMANYREQUESTS: retry-after: 544.488µs, allowed: 44000/minute`
Operating System
Alpine & ubuntu
Version
Checklist
trivy clean --all
Beta Was this translation helpful? Give feedback.
All reactions