Dependency vulnerability triage for inherited AI code

Why dependency vulnerabilities feel overwhelming in inherited AI code

Inherited AI-generated code often comes with a huge pile of dependencies. Generators pull in full frameworks, UI kits, SDKs, and helper packages even when the app uses only a small slice. Run a scanner and it can feel like the app is on fire: dozens (or hundreds) of findings across direct and transitive packages.

A lot of that noise is real but not urgent. Some vulnerabilities only matter when a library is used in a specific way. Others affect dev-only tools that never run in production. Some require an attacker to already have access, which changes the urgency. The frustrating part is that most reports don’t tell you what’s actually exploitable in your app.

That’s why dependency vulnerability triage matters. Triage means making decisions, not blindly updating everything. You sort findings into a few buckets: patch now, patch soon, monitor, or accept temporarily with a clear reason.

Moving too fast can also make the app less stable, especially with AI-built projects that have fragile wiring and little test coverage. A quick upgrade can break authentication, change request validation, or alter build tooling in a way that only shows up after deployment.

Here’s a realistic situation: you inherit a prototype generated in Cursor or Replit and it’s already in production. The scanner flags a high-severity issue in a package used only for local testing, and a medium issue in the HTTP layer that handles user input. Patch the first one and you feel productive, but real risk barely changed. Patch everything at once and you might break login and lose users.

Set your triage goal and scope before you touch versions

The fastest way to break an inherited AI-generated app is to start upgrading packages without a clear target. Set your goal and scope first so every change has a reason.

Start with a quick inventory. Write down what you’re running (API, web app, mobile, worker), the runtime and version (Node, Python, Ruby, etc.), and which package managers are in play (for example, npm plus a Python requirements file). Also note where it runs: VM, serverless, container, or managed platform. This prevents “fixes” that never ship because they don’t match the real build and deploy path.

Next, define what “production impact” means for your app. For many products, the highest-risk areas are authentication and sessions, payments and webhooks, user data features (uploads, profiles, messages), admin tools, and any public endpoint that accepts input.

Pick one source of truth for tracking findings. Use one scanner as your official list, but reconcile it with what is actually installed (your lockfile). If a scanner says you’re vulnerable but the lockfile shows a patched version, treat it as noise. If it’s the other way around, trust the lockfile.

Keep the goal simple: reduce exploitable risk first, then clean up the rest. You’re aiming for fewer vulnerabilities that can be triggered in the deployed app, not a perfect score overnight.

The basics that decide whether a finding matters

Most scanners produce a long list, but only a small slice is urgent. Triage starts with one question:

Can this bug be triggered in your real app, by a real attacker, today?

A few concepts decide most outcomes:

• Direct vs transitive: Direct dependencies are imported in your code and are usually easier to upgrade or replace. Transitive dependencies are pulled in indirectly, so you may need to upgrade the parent package, use an override/resolution, or apply a temporary mitigation.
• Runtime vs dev-only: A critical issue in a dev tool often doesn’t affect production. It can still matter if your CI/build system pulls untrusted code or publishes artifacts automatically, but it’s a different type of risk.
• Exposure: The same vulnerable component is far more serious if it sits behind a public endpoint or processes user-controlled input.

When you’re judging exposure, focus on where user input can reach the vulnerable code: public routes and APIs, webhooks, file uploads, background jobs that process user data, and auth or admin flows.

Also watch for amplifiers that are common in AI-generated projects: hardcoded secrets, weak session handling, and unchecked input. Those can turn a “low” library issue into a breach. A vulnerable Markdown parser is a lot riskier if it’s reachable from a public preview page and runs with access to database credentials.

A practical prioritization formula: severity + exploitability + exposure

A CVSS score tells you how bad a bug could be in the best-case setup for an attacker. It doesn’t tell you how urgent it is for your app. Urgency depends on what’s reachable today, how easy exploitation is, and what happens if it succeeds.

A simple scoring approach helps you move fast without guessing:

Priority = Severity x Exploitability x Exposure

Rate exploitability and exposure as Low (1), Medium (2), High (3). Then use a couple of tie-breakers:

• Reachability: If the vulnerable function can’t be reached in your app, it drops.
• Business impact: If it touches user data, payments, secrets, or authentication, it rises quickly.

Example: a critical bug in an image parser is near the top if your app allows public file uploads. But if the same library only runs during a local build and never ships, it can wait.

Step-by-step: triage and build a patch plan you can finish

The goal isn’t “fix everything.” The goal is a patch plan you can actually complete without creating a new outage.

1. Make the work visible. Create a tiny backlog where each item includes the package, current version, where it runs (app server, build tool, container), and what feature uses it. If you can’t answer “where is this used?”, you can’t judge urgency.

2. Deduplicate. The same vulnerable library often appears through multiple parents or across a monorepo. Group by “root package + vulnerable range” so you don’t fix the same thing five times while missing the real source.

3. Take quick wins first. Patch-level or minor bumps with a small test surface reduce real risk fast and build confidence.

4. Flag risky upgrades early. Major version bumps are obvious, but treat auth libraries, request parsing, templating, database drivers, and ORMs as high-risk even when the version change looks small. These changes tend to break logins, data writes, or security assumptions.

5. Write down a decision per group. Patch now, mitigate temporarily, or accept temporarily (with a reason and an expiry date). Avoid vague “we’ll get to it later.”

A solid outcome looks like this: patch three low-risk updates today, schedule one major ORM upgrade next week with extra testing, and accept a dev-only tooling issue for 30 days because it never ships to production.

How to patch without breaking everything

Inherited AI-generated code often works by accident. A dependency bump can change defaults, tighten validation, or shift build output, and suddenly login fails or the app won’t deploy.

Start with the smallest safe move. Prefer scoped updates that respect your lockfile over “update all,” which rewrites half the tree.

A practical approach:

• Update one direct dependency at a time when you can.
• For transitive issues, upgrade the parent first. Use overrides/resolutions only when you can’t safely bump the parent.
• Keep one change per PR or commit so you can pinpoint what broke.
• Test in the mode you ship (production build, real environment variables), not only dev mode.

Don’t treat “it builds” as proof. Add a few targeted smoke tests that match real usage. For many SaaS apps, that’s sign up and login, password reset, one core create/read/update flow, an admin action, and a payment or checkout path if you have one.

Have a rollback plan before you merge. Tag a known-good commit, keep a backup of environment config and database migrations, and make sure you can redeploy quickly if something fails.

Document changes in plain English: old version, new version, why it changed, and what you tested. Future you (or a new maintainer) will thank you.

When you can’t patch today: mitigations and temporary risk acceptance

Sometimes the right fix is a version upgrade you can’t safely do this week. Maybe it’s a major jump with breaking changes, maybe the library is abandoned, or the codebase is so fragile that any bump risks an outage.

When that happens, the goal changes: reduce the real-world chance of abuse now, and make a time-limited decision so the risk doesn’t silently become permanent.

The fastest mitigations usually shrink exposure:

• Disable the feature or endpoint that triggers the vulnerable component.
• Restrict access to internal users or admins (and double-check those checks).
• Validate input at the edge: reject unexpected types, oversized payloads, and unsafe filenames.
• Reduce permissions: least-privilege database users, scoped tokens, read-only keys where possible.
• Turn off risky defaults: debug modes, open CORS, public buckets, directory listing.

Example: if a vulnerable Markdown or upload library is used in a notes feature, you might temporarily cap file size, block HTML rendering, or limit uploads to a safe subset.

If you can’t remove the path, add guardrails around it: stronger auth checks, rate limiting, and safer defaults. These often cut practical risk quickly.

Temporary risk acceptance should be explicit. Write down the exact package and vulnerability, why you can’t patch now, what mitigations you applied, who owns it, and an expiration date (14 or 30 days). If you can’t assign an owner and a date, you’re not accepting risk. You’re forgetting it.

Common mistakes that waste time or create new outages

Updating everything at once sounds efficient, but it makes failures hard to explain. If login breaks after 37 packages changed, you won’t know why. Move in small batches you can roll back.

Treating every dev dependency alert like a production emergency wastes time. Confirm whether the package is in the production bundle or only used in CI/build steps. Dev-only issues can still matter, but they’re usually not the first fire.

Ignoring transitive dependencies leaves the vulnerable version buried. Find what’s pulling it in, then decide whether to bump the parent, apply an override, or replace the dependency.

Relying on severity numbers and skipping reachability leads to busywork. Always ask whether user-controlled input can realistically hit the vulnerable function in your app.

Not testing critical flows after upgrades is how security work turns into outages. After each batch, re-check auth, permissions, payments, uploads, and at least one deploy/build to the real environment.

Example: a realistic triage plan for an AI-built prototype turned product

A founder inherits an AI-generated SaaS built with Next.js and Node. Users can sign up, pay, and access a dashboard, but authentication has odd edge cases (password reset sometimes logs into the wrong session). The scanner reports dozens of dependency vulnerabilities.

Instead of chasing every alert, sort findings into two buckets:

• reachable from the public internet
• internal-only (build tools, local scripts, admin-only jobs)

Then mark each as direct or transitive. Direct, internet-exposed items usually come first.

A plan you can finish in one focused pass:

• Patch three quick wins: internet-exposed, low-risk updates that stay within the same major version (for example, an HTTP helper, cookie parsing, a small auth utility).
• Mitigate one major-upgrade item: a critical issue sits in a core framework package, but the fix requires a major bump that could break routing or middleware. Add a temporary guard (stricter input validation, blocking unexpected headers) and schedule the upgrade as a separate task.
• Defer two low-impact items: low-severity issues in dev-only tooling or packages that don’t run in production.

Verification stays practical: sign up, log in, reset password, log out, log back in, test an expired session, and confirm the deploy still builds and starts cleanly.

Finally, write a one-page note listing what you patched, what you mitigated, what you deferred, and why, plus an owner and review date.

Quick checklist: what to confirm before and after you patch

Before

Make sure you’re looking at what’s actually deployed: the image tag or build ID, the Git commit, and the lockfile used for the build. If those don’t match your repo, fix that first.

Then sanity-check the top findings for real exposure. Trace a path like: public route -> handler -> library call. If you can’t connect the finding to a reachable path, it’s probably not your first priority.

Try to fix one or two high-risk items with patch or minor updates. Park major upgrades that look likely to break routing, auth middleware, or database behavior.

After

Re-test the flows that break quietly: login, signup, password reset, and permissions. Then hit the risky surfaces: uploads, forms, search, webhooks, and anything that accepts user input.

Also confirm the basics:

• the deployed image/commit/lockfile changed as expected
• the fixes you shipped match what the scanner reports
• any temporary risk acceptance is documented with an expiry date

Next steps: keep the app safe without getting stuck in upgrades

Once you have a clear triage list, turn it into a repeatable routine. Small, regular updates are less risky than occasional “everything at once” upgrades, especially in AI-generated codebases.

A monthly cycle is enough for many teams: rescan, focus on new or worsened findings, patch a handful of high-impact items, run a short smoke test, and write down what you changed and what you’re deferring.

If the codebase is too fragile, don’t force major upgrades just to silence a scanner. It can be faster to stabilize a few critical areas first (auth, database access, request validation), add minimal tests around them, and then upgrade in smaller steps.

Treat certain discoveries as blockers even if they look like “just dependencies.” If you find broken authentication logic, exposed secrets, or SQL injection risk, stop and fix those before shipping other features.

If you inherited an AI-generated app and want a second set of eyes on what’s truly exploitable versus noise, FixMyMess (fixmymess.ai) does codebase diagnosis and security hardening for AI-built projects, starting with a free code audit to identify the highest-impact fixes.