When Builds Bite Back: The Surprising Pitfalls of Maven Environments and Reproducibility

In a perfect world, builds are deterministic: run the same build on the same codebase and get the same output. But anyone who's worked with Maven at scale knows we don't live in that world.

At FOSSA, we help companies track and secure their dependencies. So when builds go sideways and dependencies unexpectedly shift, we're often the first to notice — and the ones tasked with explaining why.

This post dives into the surprising ways Maven build environments can introduce non-determinism, using a real-world issue involving commons-collections that temporarily puzzled engineers across multiple teams.

Maven Doesn't Guarantee Reproducible Builds

Maven prioritizes build success over build determinism. That means:

• It will resolve the latest allowable version of a dependency based on your pom.xml and any inherited dependencies.
• It doesn't lock versions by default.
• Your build output may change without any code or configuration changes.

Unless you're using explicit version locking, you're at the mercy of what Maven sees at build time.

💥 Real-world example: A project scanned across different containers returned two different versions of commons-collections: 3.2.1 (with a critical CVE) and 3.2.2 (which fixed it). No code changed. The only variable? The build environment.

The Diamond Dependency Problem in Maven

The diamond problem occurs when multiple dependency paths bring in different versions of the same library:

     A
    / \
   B   C
    \ /
     D

In Maven:

• Module B may depend on commons-collections:3.2.1
• Module C may depend on commons-collections:3.2.2
• Module A inherits both — but Maven must choose one.

Which version gets resolved can depend on resolution order, plugin behavior, or environment context.

Surprising Impact: Even if you declare 3.2.2 in your pom.xml, Maven might still pick 3.2.1 if it comes from a transitive path with higher precedence. This can introduce vulnerabilities unexpectedly.

Managing Maven Dependencies

FOSSA uses multiple strategies to analyze Maven projects:

Strategy	Direct Deps	Transitive Deps	Edges
mavenplugin	✅	✅	✅
treecmd	✅	✅	✅
pomxml	✅	❌	❌

The most accurate (mavenplugin) requires Maven to run and resolve dependencies in real time. If the plugin fails, FOSSA can fall back to other methods — but those are less precise.

Inconsistencies arise when different team members or systems trigger scans using different strategies, tools, or Maven environments. This is why we typically recommend users to run fossa analyze from a consistent, standardized build environment (ideally the same one used for CI/CD). Control Maven version, JDK, and other configurations explicitly.

💡 Tip

Use the --strict flag to enforce consistent strategy usage. This ensures all results rely on the most accurate and complete graph, and prevents confusing fallback behavior.

Even perfectly-scripted pipelines can drift when humans intervene. Consider:

• Different developers running scans locally
• Slightly misconfigured containers used for scanning
• Manual overrides of manifest files or JDK versions
• Inconsistent use of fossa analyze with or without a Maven wrapper (mvnw)

These human factors introduce subtle inconsistencies that are hard to trace but easy to overlook.

💡 Recommendation

Assign ownership of your FOSSA integration and document how it’s implemented. Ensure scans run within your actual build process — not as a separate afterthought.

Final Thoughts

Maven doesn’t promise determinism — it promises builds that work. That matters when your job is to audit security or license compliance with precision.

When a project shows fluctuating dependencies, it’s most likely your build system revealing its own inconsistencies. We don’t hallucinate vulnerable versions; we report what your environment tells us.

This is one of the key benefits of integrating FOSSA: it can highlight mismatches, misconfigurations, and version drifts that would otherwise go undetected. To prevent those surprises, lock your versions, standardize your environments, and treat reproducibility as a core requirement, not a side effect.

Need additional guidance on managing Maven dependency graphs? Reach out to support@fossa.com or schedule a FOSSA demo.