Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

Inspector: false positives in ECR from pom.xml files

7

Amazon Inspector is finding vulnerabilities in Java packages that are not present in the ECR image, but are referenced in a pom.xml file. This appears to be new behavior. For example, we see a finding for log4j version 0:1.2.17 with a file path pointing to the pom.xml file in the jboss-logging package (version 3.6.1 Final). This file (https://github.com/jboss-logging/jboss-logging/blob/main/pom.xml) does reference the log4j version, but with scope equal to "provided", which indicates that the package should "expect the JDK or a container to provide the dependency at runtime" (https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html). So the reference to the log4j library within the jboss-logging pom file does not mean that log4j is actually installed on the image.

Were there recent changes to Inspector that cause it to search within pom.xml files when it didn't before? Should this capability be restricted based on the "scope" and "optional" parameters?

  • ave
    a year ago

    The Inspector also reports dependencies of packages in "test" scope. I hope this gets fixed soon. Our clients are checking the Inspector results and this issue would waste both of our times. Here is an Stack Overflow thread for the same issue.

  • Olly
    a year ago

    Our container images are also seeing a huge increase in the number of CVEs found. We have many homegrown NodeJS containers that were CVE free prior to the 14 Feb 2025 updates, and now there are more than 20 CVEs reported in each.

  • ave
    a year ago

    Most of the false positives disappeared in today's report, it seems. 👍️ There still is an issue i.e. Inspector reports vulnerabilities of older versions of packages that are overridden by newer (non-vulnerable) versions.

  • ave
    a year ago

    In the latest scan, the issue with overridden packages I mentioned in my previous comment seems to have been resolved.

Topics
ContainersSecurity, Identity, & Compliance
Tags
Amazon InspectorAmazon Elastic Container Registry (ECR)
Language
English

asked a year ago2.4K views

2 Answers
1

Thank you for bringing this issue to our attention. While Amazon Inspector is designed to provide comprehensive vulnerability scanning for container images in Amazon ECR, it appears that you've encountered a situation where the scanning process may be overly sensitive in its interpretation of dependencies.

Amazon Inspector's enhanced scanning capabilities are intended to identify potential vulnerabilities in software packages, including those in Java environments. However, the behavior you're describing, where Inspector is flagging vulnerabilities based on references in pom.xml files with "provided" scope, does seem to be an overreach in its analysis.

To the best of my knowledge, there haven't been any recent announced changes to Inspector that specifically target searching within pom.xml files or altering how it interprets Maven dependency scopes. The behavior you're experiencing might be an unintended consequence of improvements to the scanning engine's depth and breadth.

You're correct in your understanding that dependencies with "provided" scope in Maven are expected to be provided by the runtime environment and are not typically bundled with the application. Therefore, flagging these as vulnerabilities present in the container image could indeed lead to false positives.

This situation highlights an area where the vulnerability scanning process could potentially be refined. Ideally, the scanner should take into account the Maven dependency scopes and optional parameters to provide more accurate results and reduce false positives. Distinguishing between actual included dependencies and those that are merely referenced but not present in the final artifact would improve the accuracy of the vulnerability reports.

I would recommend reaching out to AWS Support to report this behavior. They can investigate whether this is a known issue, a recent change, or an area for improvement in the Amazon Inspector service. They may also be able to provide guidance on how to interpret these findings or suggest workarounds if needed.

In the meantime, you may need to manually review these findings and potentially filter out false positives based on your knowledge of the actual contents of your container images. Keep in mind that while these particular findings may be false positives, it's always good practice to ensure that the runtime environments where you deploy your containers are also kept up-to-date and free of vulnerabilities.
Sources
Amazon Inspector finding types - Amazon Inspector
Troubleshooting image scanning in Amazon ECR - Amazon ECR
Scanning Amazon Elastic Container Registry container images with Amazon Inspector - Amazon Inspector
Automated Vulnerability Management - Amazon Inspector Features - AWS

answered a year ago

EXPERT

reviewed a year ago

0
Accepted Answer

We've experienced the same issues recently from the 13th Feb 2025.

From AWS Support there has been a recent change (between 12th Feb and 13th Feb 2025) to enhanced ecr scanning/inspector which leads to the above.

Update from 26th Feb 2025. After liaising with AWS Support they have now excluded scan results of transitive dependencies brought into containers to fix the above issue (e.g. pom files which include dependencies with a scope such as optional, test, provided). I have since closed my support case with them leading to this above resolution, however if there are additional issues with Inspector reports vulnerabilities of older versions of packages that are overridden by newer (non-vulnerable) versions, it's probably worth raising a support case with them.

answered a year ago

EXPERT

reviewed a year ago

  • Andreas
    a year ago

    Hi Aaron, others

    We are experience the same issue with lots of false positives and would benefit from the refined scanning you are mentioning in your update.

    In our case we also use a library which in its pom metadata as optionally declared dependency has jackson-databind in a quite old version.

    <!-- Used for optional Jackson support -->
<dependency>
  <groupId>com.fasterxml.jackson.core</groupId>
  <artifactId>jackson-databind</artifactId>
  <version>2.9.10.5</version>
  <optional>true</optional>
</dependency>

    If I understand your update correctly this should be excluded by the ECR scanner with recent changes. Is that understanding correct? Do you know if we need to actively do something on the inspector to benefit from the changes?

    Thanks

  • Aaron
    a year ago

    Hi Andreas, Yes you're right, it looks like optional is still being declared in enhanced ecr scanning. Do you have access to aws support to raise this as a support case?

  • Andreas
    a year ago

    Hi Aaron, Thanks for the confirmation. Unfortunately we do not have access to AWS support from our account.

    Maybe as this also seems to affect others, someone with access to the support can raise the topic? We currently have quite a number of false positives in the report, with no chance from our side to influence it (except for suppressing findings).

    Thanks, Andreas

  • Andreas
    a year ago

    Looks with the recent updateson ECR scan from today the false positives are also resolved for us. This is really good to see. Andreas

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content