Yes. Code generated from an OpenAPI file pulls in HTTP, serialisation and framework dependencies you did not choose one by one, and those age like any other. Treat generated clients and server stubs as normal code: inventory them, scan them, pin them and regenerate on a schedule.
What generators produce
OpenAPI Generator, a widely used open source tool, lists generator categories for clients, servers, documentation and schemas, across many languages and frameworks, with some marked beta, experimental or deprecated. A client generator emits an SDK plus a dependency manifest. A server generator emits a project with a framework and its libraries.
Where the risk comes from
| Source | Risk |
|---|---|
| Dependency manifest in the generated project | Old or vulnerable library versions baked in by the template |
| Template defaults | Insecure defaults, such as permissive settings, if left unchanged |
| Generator version | Output changes between versions, so builds are not reproducible |
| Experimental or deprecated generators | Little maintenance |
| Committed generated code | Stale copies that nobody regenerates |
| Spec content | A wrong spec produces wrong validation and auth handling |
What to do
- Pin the generator version and the template set, and record both.
- Inventory the output. Produce an SBOM for each generated project, so the list of dependencies is explicit.
- Scan the manifest the same way as hand written code, and check findings against reachability, since generated code often includes unused paths.
- Review the defaults in server stubs: authentication hooks, CORS, error handling, logging.
- Choose one workflow: either commit generated code and update it deliberately, or generate in CI and do not commit it.
- Regenerate on a schedule, for example when the spec changes or monthly.
- Own the customisations. If you patch templates, keep the patch in version control.
What a review of generated output looks like
Open the generated manifest and read it as you would a new dependency list. Which HTTP library does the client use, and at what version? Which JSON or XML parser does it pull in? Does the server stub enable debug output, permissive cross origin settings or a default error page that shows internals? Does it ship sample credentials or placeholder keys in configuration? A ten minute read of the first generated project usually shows which template defaults you need to override, and you can then encode those overrides once instead of fixing every service by hand.
Also decide who owns the output. A client library published to other teams or to customers becomes part of their supply chain, so the same version, changelog and advisory discipline applies to it.
Security of the spec itself
Generated server code enforces what the spec says. If the spec declares an operation without authentication, the stub may happily serve it. Review the file as described in writing an OpenAPI spec that helps security testing.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how direct and transitive dependencies are listed, since a generated project has both.
Quick check
Should I commit generated code?
Either is workable. Committing makes changes reviewable, but it can go stale. Generating in CI keeps it fresh but needs pinned tools.
Is a vulnerability in a generated client always exploitable?
No. It depends on whether the vulnerable code path is used. Reachability checks help you decide.
Safeguard provides SBOM and dependency scanning with reachability analysis, and a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
