Congrats for the good work with this contrib version of the task!
BTW I think make sense to do a rebase on upstream since they implemented few things recently.
The retry mechanism you implemented (d87c310) does not consider the following options: db-repository, java-db-repository, checks-bundle-repository.
The only effective way as for now to workaround the aquasecurity#82 in fact is using public.ecr.aws as registry. This is working well, apart for the downloadVulnDb that could still fail for TOOMANYREQUESTS.
parameters:
- name: privateRegistry
type: string
# see: https://github.com/aquasecurity/trivy/discussions/7538
default: public.ecr.aws
steps:
- task: trivy-contrib@1
inputs:
image: ${{ parameters.repositoryPrefix }}${{ imageName }}
scanners: vuln
ignoreUnfixed: true
options: >
--db-repository ${{ parameters.privateRegistry }}/aquasecurity/trivy-db
--java-db-repository ${{ parameters.privateRegistry }}/aquasecurity/trivy-java-db
--checks-bundle-repository ${{ parameters.privateRegistry }}/aquasecurity/trivy-checks
Congrats for the good work with this contrib version of the task!
BTW I think make sense to do a rebase on upstream since they implemented few things recently.
The retry mechanism you implemented (d87c310) does not consider the following options: db-repository, java-db-repository, checks-bundle-repository.
The only effective way as for now to workaround the aquasecurity#82 in fact is using public.ecr.aws as registry. This is working well, apart for the downloadVulnDb that could still fail for TOOMANYREQUESTS.