Vulnerable Components in Java Projects – OWASP A06
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
Vulnerable and Outdated Components is the A06 category from OWASP Top 10:2021. In the 2025 release, this area is broader and appears as A03 Software Supply Chain Failures. The risk includes vulnerable libraries, but also untrusted package sources, plugins, base images, compromised build systems, and unsafe update paths.
For example, with Log4Shell the useful check was not simply “does this repository mention Log4j?” A team had to inspect the resolved version, packaging and runtime path, exposure, vendor guidance, and then upgrade or apply the supported mitigation. The same inventory should include transitive libraries, build plugins, and container images.
Automated advisory matches need triage, but an exposed issue should be upgraded or removed promptly. When that is not immediately possible, use a documented vendor mitigation, monitoring, and a time-bound remediation plan. Trusted repositories, protected CI credentials, reproducible dependency management, and an SBOM help reduce and investigate supply-chain risk.
Vulnerable Components in Java Projects – OWASP A06
Direct Answer
“Vulnerable and Outdated Components” is A06 in OWASP Top 10:2021. In the current 2025 release, dependency and build risks are covered more broadly by A03 Software Supply Chain Failures. Manage them with an inventory or SBOM, reproducible dependency management, scanning of direct and transitive components, trusted repositories, build-pipeline protection, and a process that evaluates advisories in the application's actual context. Patch or mitigate based on exploitability and exposure, not a CVSS number alone.
Code Example
<properties>
<!-- Keep this centrally managed and update it through normal dependency review. -->
<dependency-check.version>${approved.dependency-check.version}</dependency-check.version>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.owasp</groupId>
<artifactId>dependency-check-maven</artifactId>
<version>${dependency-check.version}</version>
<executions>
<execution><goals><goal>check</goal></goals></execution>
</executions>
<configuration>
<formats><format>HTML</format><format>JSON</format></formats>
</configuration>
</plugin>
</plugins>
</build>
mvn -ntp dependency:tree
mvn -ntp org.owasp:dependency-check-maven:check
Pin tool versions for reproducible builds, update them deliberately, and triage findings rather than treating one fixed CVSS threshold as the whole policy.
Common Mistakes & Pitfalls
- Set and Forget Dependencies: Adding libraries to pom.xml during initial development and never updating them again—applications run for years on vulnerable dependency versions from 2020.
- Ignoring Transitive Dependencies: Only reviewing direct dependencies in pom.xml while ignoring the 150+ transitive dependencies pulled in automatically—vulnerabilities hide several layers deep.
- Open-Ended Version Ranges: Using version ranges like
<version>[5.0,6.0)</version>hoping Maven will auto-update to secure versions—Maven doesn't automatically fetch newer versions, and ranges create unpredictable builds. - No CI Integration: Running
mvn dependency:treemanually once during a security audit instead of integrating vulnerability scanning into every build—by the time you manually check, a zero-day could have been disclosed weeks ago.
Check your understanding
Answer these without looking back at the article.
- What was Log4Shell and why was it so severe?
- How do you integrate OWASP Dependency Check into a Maven build?
- What is a CVE and how do you find out if one affects your project?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.