.png)
Overview
Some customers use automated security scanning tools (e.g., AWS Inspector, Trivy, Prisma, Azure Defender) to analyse Docker images that include HCMS.
These tools may report critical vulnerabilities in certain Java libraries or dependencies packaged inside the container.
In many cases, these findings do not correspond to actual vulnerabilities in the running HCMS application.
This article explains why such “false positives” can appear and how to interpret them.
However, not all findings are false positives—some libraries may legitimately contain vulnerabilities and require upgrades.
Why Security Scanners Report Vulnerabilities
Most security tools scan the entire filesystem of a container image, including:
-
Java library JAR files
-
Nested JARs within JARs
-
Build metadata stored in META-INF/maven/.../pom.xml
These pom.xml files often contain:
-
Version numbers of dependencies used at build time
-
Transitive dependencies from parent projects
-
Deprecated or unused component references
These metadata files do not represent the libraries actually loaded and executed by HCMS at runtime.
What Causes the False Positives
It is common for Java libraries to include a pom.xml inside their JAR for Maven build metadata.
For example:
META-INF/maven/<group>/<artifact>/pom.xml
A scanner may detect:
-
Very old dependency versions declared in these metadata files
-
Transitive dependencies that were overridden or removed
-
Libraries referenced but not actually included in the HCMS runtime classpath
Common examples include:
-
commons-logging
-
handy-uri-templates
-
logback-classic
-
Older jackson-databind versions listed in metadata
These files may list vulnerable versions even when the real application is using newer, patched versions.
Important Clarification
A vulnerability listed in a pom.xml inside a nested JAR does not mean that the vulnerable library is present or used by HCMS.
HCMS may:
-
Override the transitive dependency with an updated version
-
Not use the library at all
-
Include the metadata but not the corresponding code
This is how Java/Maven packaging works and is normal for large Java applications.
However:
Some findings are real, and libraries may actually require updates.
Evaluating each CVE is therefore essential and must be done by the development team.
What You Should Do When Scanning HCMS Images
1. Compare Findings to Actual Runtime Libraries
The runtime JARs (mostly) located directly under:
/opt/corpus/censhare-Satellite/bundles/
should be evaluated.
Metadata inside nested JARs does not reflect runtime behavior.
2. Review the True Library Versions
If a scanner reports a vulnerability for a library:
-
Confirm the actual JAR version delivered with HCMS
-
Compare it against published CVE advisories
-
Validate whether the vulnerable version is actually included
3. Distinguish Metadata‑Only Findings
Findings referring to:
-
pom.xml
-
META-INF/maven/...
-
nested JAR metadata
typically do not represent runtime vulnerabilities.
4. Recognise Real Vulnerabilities
If the runtime JAR version matches an actual CVE, the finding is not a false positive and may require:
-
dependency updates
-
override adjustments
-
developer review
If you have questions about specific findings, please provide:
-
File path from the scanner
-
CVE ID
-
Scanner tool used
-
HCMS version
-
Docker build process (if applicable)
Support can help determine whether the finding reflects:
-
real runtime vulnerability, or
-
metadata‑based false positives
Summary
Security scanning tools often flag non‑runtime metadata inside Java packages, creating false positives. These findings usually relate to Maven POM files that do not correspond to the actual libraries used by HCMS.
However, not all findings are false positives—some vulnerabilities may genuinely affect runtime libraries and require upgrades.
Each finding must be validated individually.