Skip to main content
Stackbastion

Draft, not yet published

Keeping dependencies updated in code you didn't write yourself

7 July 2026· 5 min read · by Stackbastion

Your app has a package.json with 40 dependencies, and you couldn’t name what half of them do. The AI added them while building your app. Now there’s a security advisory floating around and you have no idea if it affects you, or how to safely update without breaking everything.

You don’t need to understand every package. You need a repeatable way to find the risky ones and patch them.

Why this happens

AI code generators reach for packages the way a chef reaches for salt. Need a date formatted? Add a library. Need to parse a CSV? Add another. It’s faster than writing the code, and the AI has no reason to be frugal. The result is an app with a large dependency tree you never curated.

Every one of those packages is code running on your server that you didn’t write and haven’t read. When a vulnerability is found in one of them, the fix is on you. And because the AI pinned specific versions to make your app work on day one, nothing updates on its own. Six months later you’re running packages with known holes and no process to close them.

The other trap: updating carelessly. Bump the wrong package to a new major version and your app breaks in ways the AI’s original code never anticipated. So the goal isn’t “always be on the latest,” it’s “know what’s vulnerable, and update safely.”

How to fix it

Start with a single command that tells you where you stand.

Step 1: run an audit

If your app uses npm (most JavaScript AI builders do), npm audit scans your installed packages against a database of known vulnerabilities:

npm audit

You’ll get output like this:

# npm audit report

axios  <1.7.4
Severity: high
Server-Side Request Forgery in axios
fix available via `npm audit fix`

lodash  <4.17.21
Severity: high
Prototype Pollution
fix available via `npm audit fix --force`

2 vulnerabilities (1 moderate, 1 high)

This is your priority list. Read it top to bottom. High and critical get fixed first.

Step 2: apply the safe fixes

For vulnerabilities where a compatible patch exists, npm audit fix updates them within your allowed version ranges, which means it won’t jump major versions and is unlikely to break anything:

npm audit fix

Then run your app and click through it. Even “safe” updates deserve a five-minute smoke test.

Step 3: handle the risky ones deliberately

Some fixes require a major version bump. npm audit fix --force will do it, but the --force is a warning: major versions can have breaking changes. Don’t run it blind on production.

Instead, update those one at a time. Look at what needs bumping, update a single package, and test:

npm install axios@latest
npm test        # if you have tests
npm run build   # confirm it still builds

If your app has no tests (many AI-built apps don’t), do this on staging, not production, and click through the features that use the package. This is exactly the kind of change you want to catch before your users do.

Step 4: automate the ongoing check with Dependabot

Doing this by hand once is good. Doing it every month forever is the part humans forget. If your code is on GitHub, Dependabot watches your dependencies and opens a pull request whenever one has an update or a security fix. Turn it on with one file:

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 5
    groups:
      # bundle minor and patch updates into one PR to cut noise
      minor-and-patch:
        update-types:
          - "minor"
          - "patch"

Commit that, and Dependabot starts opening PRs. Security fixes come as their own PRs so you can merge them fast. Routine minor updates get grouped so you’re not drowning in notifications.

Step 5: a monthly habit, 15 minutes

Automation opens the PRs. You still decide what to merge. Once a month:

  1. Run npm audit and clear anything high or critical.
  2. Review the Dependabot PRs. Merge the security ones first.
  3. For grouped minor updates, merge, then smoke-test on staging.
  4. Leave risky major bumps for when you have time to test them properly.

Fifteen minutes a month keeps you out of the situation where a two-year-old vulnerability is sitting in production because nobody was watching.

A note on scope: npm audit flags every advisory, including ones in packages that only run during your build, not in production. A vulnerability in a build tool that never touches user data is lower risk than one in a package handling requests. Read the advisory, don’t just react to the severity label. But when in doubt, patch it.

Or, we do it for you

Dependency patching is the classic thing that’s easy to set up and easy to forget. Managed hosting from Stackbastion keeps your dependencies audited and patched as part of the service, so a known vulnerability doesn’t sit in your app for months. See what’s included on our pricing page.

FAQ

Is npm audit enough, or do I need a paid scanner?

For most solo and small-team apps, npm audit plus Dependabot covers the essentials for free. Paid scanners add things like license checking and deeper supply-chain analysis, useful at larger scale. Start with the free tools; they catch the vulnerabilities that actually get exploited.

Should I just update everything to the latest version?

No. Blindly updating to the newest version of everything is how you break an AI-built app that was never tested against those versions. Update security fixes promptly, update minor versions on a schedule with a quick test, and treat major version bumps as deliberate work you do on staging first.

What if npm audit shows vulnerabilities I can’t fix?

Sometimes the fix isn’t available yet, or it’s in a transitive dependency you don’t control directly. Note the advisory, check whether the vulnerable code path is even reachable in your app, and watch for the patch. If it’s high severity and reachable, you may need to replace the package or pin to a patched fork. That’s a good moment to ask for help.

Does this apply to Python or other languages too?

Yes, the pattern is the same, only the tools change. Python has pip-audit, Ruby has bundler-audit, and Dependabot supports many ecosystems beyond npm. The habit is identical: scan for known vulnerabilities, patch the serious ones fast, automate the checking so you don’t have to remember.

Related posts