The Java generator writes models that use Swagger v2 annotations such as the ApiModelProperty annotation, so the generated project declares a library for them. Swapping in the v3 annotations library does not work, because it is not binary compatible. Expect this dependency, and track it like any other.
What the docs say
The OpenAPI Generator plugins page has a Dependencies note for the Maven plugin. It says generated models use commonly used Swagger v2 annotations. A user may try adding the Swagger v3 annotations dependency, but the page states this will not work: the dependency is not binary compatible with the v2 annotations, and the resulting code fails to compile. As an alternative it names a different dependency, the Swagger parser for v3.
This is a small, concrete example of a general fact. Generated code carries dependencies chosen by the generator, and you inherit them.
Why it matters for security work
You did not pick it. The library arrives because a template references it. It may not appear in any list your team keeps.
It cannot always be swapped. If a scanner flags an old annotations library, the obvious fix of moving to the newer major line may break the build. You need to know that before promising a quick patch.
It is easy to miss in reviews. Teams may assume annotation libraries carry no risk. Whether a given advisory reaches your code depends on what the library does in your build. Check it, rather than assuming.
| Situation | What to do |
|---|---|
| Scanner flags the annotations library | Confirm the version in the generated build file, then check whether a compatible fixed version exists |
| Developer tries the v3 library | Expect a compile failure, per the docs, and revert |
| Generator upgrade changes the version | Review it as a dependency change in the diff |
| You must stay on an old line for compatibility | Record a time limited exception with a reason |
A practical approach
- Generate an SBOM for the project that contains the generated code, as well as the hand written modules.
- Look for the annotations and parser libraries in it, and note their versions.
- When an advisory lands, read it for what is affected. Many advisories concern parsing behaviour, not annotation classes, so reachability matters.
- Plan fixes through a generator upgrade where possible, since the templates and the library versions move together.
- If you must override a version, keep the override in your own build file, record why, and re-check on each upgrade.
Related reading: a lockfile does not cover everything, and dependency risk in generated clients.
Where Safeguard fits
Safeguard produces SBOMs and runs dependency scanning that includes transitive libraries, and reachability analysis helps you judge whether an advisory affects code paths you use.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a finding is checked against whether it can be exploited in context.
Quick check
Is the annotations dependency specific to Maven?
The note appears in the Maven plugin section of the docs, but it describes what the generated models use, which applies to the generated code in general for that generator.
Can I just upgrade to the v3 annotations library?
The docs say it will not work and the code will fail to compile.
Sources
Last reviewed: 19 October 2026.
