Your AI agent has wired up authentication, payments, and the database, and the interface works. Then, right before deployment, you notice a row of unfamiliar packages in package.json and thousands of lines in the lockfile. Which dependencies actually reach production? What changed in last week's pull request? Nobody may have a clear answer.

The useful question is not whether AI-written code is inherently dangerous. There is not enough primary-source evidence to claim that AI-assisted projects suffer more supply chain incidents than hand-written ones. What we can see is a process gap: AI makes adding packages, editing workflows, and copying install commands fast, while review has not accelerated at the same rate.

Once a dependency runs on your server, payment path, or GitHub Actions workflow, a failure can expose more than a broken build. This guide is for indie makers who have built a Node.js or Next.js app with AI and can use GitHub and a terminal. If those tools are still new, start with the 30-minute version rather than jumping straight into CI gates.

The short answer: commit the lockfile, confirm that GitHub's dependency graph can read it, review every dependency change in a pull request, and then enable alerts and remediation pull requests. A clean npm audit or OSV-Scanner result only means no current match against known-vulnerability data. It does not certify a new package as trustworthy.

Map the blast radius before choosing tools

A small side project can still give a dependency access to servers, build pipelines, secrets, or deployment permissions. Start with five failure modes instead of memorizing attack names.

Failure mode	What you see	Lowest-cost gate
Invisible inventory	You cannot list direct and transitive dependencies	Commit the lockfile and create a dependency graph
Unreviewed change	AI quietly adds a package in a pull request	Require a reason and review the dependency diff
No alerting	Nobody notices when a vulnerability is disclosed	Enable Dependabot alerts and security updates
Unsafe remediation	A bot update breaks the app	Run the existing build, tests, and production-path checks
Scanner blind spot	A clean scan is treated as proof of safety	Review package origin, install scripts, and project health

GitHub's dependency graph builds an inventory from manifests, lockfiles, and submitted dependency data. CISA also places open source inventory and SBOMs within a broader risk-management process, but its guidance is not a law requiring every small project to implement every control.

Build an inventory with the lockfile and dependency graph

A dependency inventory is a continuously updated list of direct and transitive dependencies, including at least the package, version, and source file. A transitive dependency is installed by another package rather than directly by you. Without an inventory, alerts and pull request reviews have no dependable baseline.

Do three things first:

1. Commit the lockfile. For npm projects, that usually means package-lock.json, not only package.json.
2. Open Insights → Dependency graph → Dependencies in the GitHub repository and confirm that it shows package names, versions, and source manifests or lockfiles.
3. Create a first vulnerability snapshot:

npm audit

The npm documentation explains that the command sends dependency-tree information to the configured registry and returns known-vulnerability findings. It is useful, but it is not code review and cannot tell you whether a new package deserves trust.

Stop quiet dependency changes at the pull request

An AI suggestion that a library can solve a problem is not an approval to introduce it. Every manifest, lockfile, or workflow change should answer three questions: Why is it needed? Can existing code do the job? What direct or transitive dependencies changed?

GitHub Dependency Review shows added, removed, and updated dependencies in a pull request, including lockfile changes and known vulnerabilities. With the Dependency Review action and a required check, it can block a merge when a change violates your policy.

Keep the pull request template short:

## Dependency change
- Purpose:
- Why existing code is insufficient:
- Manifest and lockfile diff reviewed: yes/no
- Build and test results:

The tool exposes the diff. A person still decides whether the package belongs in production.

Give npm audit, OSV-Scanner, and Dependabot different jobs

Running every scanner in CI can produce the same alert three times. Divide them by the point in the workflow they protect.

Stage	Tool	Question answered	What it does not do
Local	npm audit	Which known vulnerabilities match the npm dependency tree?	Judge whether a new package is trustworthy
Pull request	Dependency Review	Which dependencies changed, and did a known vulnerability enter?	Test runtime compatibility
CI	OSV-Scanner	Do source, lockfile, or container packages match OSV data?	Prove unknown malicious behavior is absent
Hosted alerts	Dependabot	Which dependencies in the graph have known vulnerabilities?	Prove a remediation pull request is safe
Remediation PR	Dependabot security updates	Can it update to the lowest patched version?	Replace your build and tests

OSV-Scanner is useful when your CI still lacks coverage for a lockfile, source tree, or container. Its official GitHub Action can produce SARIF output. If GitHub's native workflow already covers your needs, do not add another scanner merely to increase the tool count.

Setup	Best for	PR gate	Ongoing alerts	Main limitation
Lockfile + npm audit	Local maintenance without GitHub gates	None	None	Relies on someone remembering to run and track it
GitHub-native workflow	One GitHub repository needing PR review and hosted alerts	Dependency Review, subject to plan and configuration	Dependabot alerts	Repository type, plan, and platform constraints
GitHub + OSV-Scanner	A remaining CI, lockfile, or container coverage gap	Workflow-dependent	Duplicate alerts are possible	Additional workflow and triage cost

Start with GitHub's native controls for one GitHub repository. Add OSV-Scanner only when you can name the missing scan location. For repositories hosted elsewhere, recreate the four functions through your platform or CI: inventory, a pull request gate, ongoing alerts, and remediation updates.

Build the minimum defense in 30 minutes, two hours, or half a day

These are planning tiers, not measured guarantees. Older repositories, monorepos, and projects without tests will take longer.

If you have 30 minutes

• Commit and inspect the lockfile.
• Confirm that the dependency graph recognizes packages.
• Run npm audit once and save the result in an issue or maintenance log.
• Assign an owner for future security alerts, even if that owner is you.

If you have two hours

• Enable Dependabot alerts and security updates.
• Add a dependency-change section to pull requests.
• Add a required Dependency Review check if your repository and plan support it.
• Send one real update pull request through dependency review, build, and tests.

Dependency Review availability differs between public and private repositories and GitHub plans. Alerts, security updates, and Dependency Review are separate features, not one master switch. Confirm the current support and setup steps in the linked official documentation.

If you have half a day

• Add OSV-Scanner only where CI still has a coverage gap.
• Configure branch protection or a ruleset so required checks cannot be skipped.
• Rehearse the path from receiving an alert to merging a fix.
• Use OpenSSF Scorecard as an additional upstream project-health signal.

Stop there. Every detector needs an owner and a review cadence. An unread dashboard is just better-looking anxiety.

Triage alert overload with a decision tree

Separate security updates from routine version updates. Then work through five questions:

1. Does the dependency reach production, the build, or deployment? Record the basis for the answer.
2. Is a patched version available? If not, consider disabling the feature, replacing the package, or reducing exposure.
3. Does the fix move a parent dependency or major version? Keep broad changes on a separate branch for manual review.
4. Do existing tests cover the production path? If not, add a focused manual check.
5. Must you defer it? Record the reason, impact, owner, and next review date.

Dependabot security updates attempts to open a pull request for the lowest version that contains a patch. npm can sometimes update a parent to fix a transitive dependency, while other ecosystems have different limits. A missing bot pull request therefore does not mean the vulnerability can be ignored.

Auto-merge only when your tests deserve that trust

A Dependabot pull request is a candidate for auto-merge only when the dependency diff is narrow, branch protection is active, required checks pass, and your tests cover the affected production path. A security purpose does not guarantee runtime compatibility.

Before merging, confirm that the dependency diff contains no surprises; run the repository's actual build, lint, type checks, and tests; cover login, payments, or data writes where relevant; and make sure the pull request did not weaken branch protection or required checks. If the project has no tests, keep auto-merge off.

A clean scan is not a package trust assessment

npm audit and OSV-Scanner answer whether a version matches currently known vulnerabilities. They do not confirm that the package name is correct, an install script is harmless, a maintainer has not changed, or a new release is trustworthy.

For every new package:

• Cross-check the registry entry, official repository, and package name.
• Look for unusual changes in releases, maintainers, or repository activity.
• Inspect scripts, especially commands executed during installation.
• Avoid adopting a brand-new production release immediately without a concrete reason.

OpenSSF Scorecard adds project-health signals such as branch protection, dependency updating, and risky workflows. Treat the score as a clue, not a security certificate.

Review the defenses themselves

A scanner in .github/workflows receives permissions, downloads actions, and executes code. Treat workflow changes like production dependency changes: require human review, reduce permissions to the minimum needed, and pin action references according to your team's policy. Security-tool updates still go through required checks.

Keep the system alive with a weekly 20-minute timebox

The timebox is a habit, not a promise to clear every alert. Spend the first five minutes on security alerts and production scope, eight minutes reviewing low-risk fixes that passed CI, five minutes deciding what to do with one larger update, and the final two minutes recording deferrals and removing notification noise.

If you always run over, check whether routine updates and security fixes share one queue, whether scanners duplicate findings, and whether missing tests make every low-risk pull request expensive. Alert fatigue is often a workflow bottleneck rather than a detector problem.

Upgrade to formal SBOM or paid SCA only when the need appears

For a small single-repository project, a usable dependency inventory is usually the practical starting point. Move toward a formal SBOM when customers need a machine-readable deliverable, compliance enters the picture, or multiple repositories require shared governance.

Keep the minimum workflow	Evaluate a platform or formal SBOM
One or a few repositories	Many repositories need a shared policy
Weekly manual triage is manageable	Alerts need assignment and audit trails
Dependency diffs and CI provide enough evidence	Reachability or cross-project analysis is required
No external reporting format is required	Customers, procurement, or compliance request reports
Current hosting and plan supply the needed gates	The repository is elsewhere or the plan lacks integrations

Do not buy a system you cannot maintain because larger companies use it. But if customers already ask which open source components you ship and who owns vulnerability response, an occasional npm audit is no longer enough.

Put one dependency pull request through the full loop today

AI-assisted shipping will not slow down, and you do not need to research every package for a week. Today, commit the lockfile, confirm that the dependency graph works, and take one real dependency pull request through justification, diff review, vulnerability checks, build, tests, and human approval.

If you only have one evening, stop after the inventory and first vulnerability snapshot. If CI and tests already exist, add Dependency Review and rehearse an update. Tools will keep changing names; the review path that speed cannot bypass is what keeps the app maintainable after launch.