Your AI coding assistant is choosing your dependencies. That’s a problem.
Your AI coding assistant is not just writing code. It is selecting your dependencies, modifying your build configuration, and choosing your suppliers at machine speed. For Java developers in particular, that deserves a harder look than most people are giving it.
The real risk is not the generated code
When you ask an assistant to add JSON handling, JWT validation, or a PDF parser, it does not just write Java. It may edit your pom.xml, import a BOM, add a Gradle plugin, or pull in a starter that brings another dozen transitive dependencies along with it. You typed none of those coordinates yourself.
Maven automatically resolves transitive dependencies. Add A and you silently get B, C, and D. That is a feature of Maven and normally a useful one, but it also means the dependency graph you run is larger than the handful of entries you consciously put in your POM.
️ Maven plugins are a bigger risk than libraries
Java developers tend to frame supply chain risk as a library problem. Plugins are the more dangerous surface. A Maven plugin executes code during the build lifecycle, during phases like generate-sources, compile, test, and package. If your assistant adds a new plugin, a new repository declaration, or a new parent POM, that change deserves more scrutiny than any library addition.
Also worth noting: the pom.xml you are reading is not necessarily the POM Maven actually builds. Inheritance and active profiles fold in silently. Run mvn help:effective-pom to see what Maven is really working with.
Four commands to run after every AI-generated build change
mvn dependency:tree— shows the full dependency tree including transitive dependenciesmvn help:effective-pom— shows the fully resolved POM after inheritance and active profilesmvn help:effective-settings— shows the merged settings Maven is actually using, including mirrors, repositories, and proxiesmvn dependency:resolve-plugins— explicitly resolves all project plugins and their dependencies
Gradle users have equivalent tooling. Gradle can display the dependency graph, explain why a particular version was selected, and supports both dependency locking and dependency verification.
Crossing ecosystems is where it gets messy
Ask for a Java backend and you will probably get Spring Boot. Add a frontend and you get Node. Add an LLM integration and Python arrives. Your CI configuration then downloads tooling from somewhere else entirely. You have gone from being a Java developer to consuming three or four software ecosystems, and the chances are you know the intricacies of only one of them well.
Research has found substantial rates of non-existent, deprecated, unsafe, or hallucinated dependency recommendations from AI assistants. That problem compounds when you are outside your ecosystem comfort zone and not reviewing what the assistant introduced.
The attacker is using the same tools
Expel published research on a North Korean threat actor it tracks as HexagonalRodent. The group used mainstream AI tools to create infrastructure, generate malware, and build fake companies to lure developers. More specifically, Expel found evidence that the attackers prompted AI models to audit their malicious code for signs of malware, specifically because targets had started using AI to inspect code and find backdoors.
The attacker is using AI to check that their malware evades your AI-assisted review. That is the threat model that matters, not autonomous super-hackers but productivity at scale on both sides.
⚠️ Old dependencies are not safe dependencies
AI assistants do not just pick bad packages. They sometimes pick old ones. A dependency that passes a CVE scan today may carry undiscovered vulnerabilities, and end-of-life packages accumulate those over time. Scanning for CVEs is necessary but not sufficient. You also need to check whether the packages your assistant selected are still actively supported.
HeroDevs offers a free EOL dependency scanner that identifies unsupported open-source components in a codebase. Running it against AI-generated projects is a reasonable first step.
What to do before you ship
- Run the four Maven commands above after every AI-generated change to
pom.xml - Review any new plugin, repository block, parent POM, BOM, SNAPSHOT reference, or dynamic version with extra care
- Check your Maven Wrapper: the thing that downloads your build tooling is itself part of the supply chain
- If your organisation proxies Maven Central through Nexus or Artifactory, verify that no AI-generated POM change added a new
<repository>or<pluginRepository>block outside that proxy - Scan for EOL components, not just CVEs
- Be explicit with your assistant upfront about what it can and cannot use
Your project’s security posture is now the posture of the weakest ecosystem in play, including the ones you did not choose and may not fully understand. The assistant that picked them works faster than any human reviewer. The audit has to happen on your end.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
