I have been using AWS Inspector for some time now to scan and track vulnerabilities for my docker Images for a number of java projects. Recently, I noticed a sudden and drastic increase in the number of reported vulnerabilities. The change has happened within the same day and a report of few medium vulnerabilities turned into a nightmare of critical vulnerabilities.

An example is that for a project with no critical and no high vulnerabilities it went to around 30+ critical and 50+ high. Most of them, reporting vulnerabilities on libraries which are not reported from the dependency tree of my application.

e.g. by running

mvn dependency:tree

I have noticed that the paths reported are coming usually from META-INF/maven/ metainfo directory where every pom.xml of every library is kept for reference, but not only.

What I have tried so far:

• Checked if dependencies are actually used with mvn dependency:tree, confirming that many reported libraries are not part of the runtime dependencies.
• Updated dependencies, it had minimal effect on reducing the number of reported CVEs.
• Scanned with alternative tools like Trivy and OWASP Dependency-Check do not flag these vulnerabilities in the same way.
• Checked AWS Inspector settings but with no luck in finding any relevant settings apart from suppression management.

My question is what is the expected way to treat those reported vulnerabilities from now on? It seems almost impossible to just clean all of those reported CVEs which some are like really really old.

EDIT:

AWS is reporting that they rolled out a new ECR scanning engine, which is a fair explanation, allow me though to explain why this is an issue with an example:

I'm adding as one of my runtime dependencies apm-agent-attach in its latest version. By navigating tο mvnrepository it displays all the dependencies of this .jar file.

As a critical finding AWS displays about jackson databind of jackson library which is not present instead it is detected in:

my-service.war/WEB-INF/lib/apm-agent-attach-1.52.1.jar/elastic-apm-agent.jar/agent/META-INF/maven/co.elastic.apm/apm-dubbo-plugin/pom.xml

How easily this vulnerability is exploitable, if it is present at all..