To fix vulnerable dependencies with an AI assistant on your own machine, scan first, hand the assistant the findings, ask for the smallest upgrade that clears them, read the diff, then approve the test run and scan again. The Safeguard CLI does all of that in one terminal session, and every change waits for your approval.
You do not have to give up the assistant you already pay for to work this way. Bring the Claude, ChatGPT or Codex plan you already pay for and use it inside the Safeguard CLI. Safeguard adds no extra charge for that usage; your plan's own usage limits and terms still apply. If you would rather stay in the chat window you know, connect Claude or ChatGPT to the Safeguard MCP server and ask about your findings from there.
This guide is the practical version. It covers why the scan has to come first, a four step loop that works with any assistant, a full Safeguard CLI walkthrough, a worked example on a generic Node and Python project, a facts only comparison of the tools people use for this job, and the mistakes that turn a ten minute fix into a broken build.
Why the scan comes before the prompt
An AI assistant is very good at editing a manifest, regenerating a lockfile and explaining a changelog. It is not a vulnerability database. A model's training data stops at a cutoff date, and new advisories are published every day. If you ask "is anything in this repo vulnerable?" with no scan data attached, you get a guess dressed as an answer.
So the ground truth has to come from a scanner that reads your lockfile and matches every resolved package against current advisory data. The assistant's job starts after that: decide which upgrade fixes the finding, make the edit, and help you check it.
Three details decide whether a fix works.
Direct or transitive. A direct dependency is one you declared. A transitive one came along with something you declared. You can bump a direct dependency in your manifest. A transitive one usually needs its parent upgraded, or an override your package manager supports. GitHub's Dependabot docs spell out the same limit: outside npm, Dependabot cannot update an indirect dependency when that would also require updating its parent.
The lockfile is the record. Scanners read what is actually installed, which lives in the lockfile, not in the version ranges of your manifest. npm's own docs say npm audit needs a package-lock.json or shrinkwrap file by default. If the assistant edits package.json and forgets the lockfile, you have changed nothing that ships.
Package names must be real. A 2024 study of code generating models, "We Have a Package for You!", generated 576,000 code samples across 16 models and found that the average share of hallucinated package names was at least 5.2% for commercial models and 21.7% for open source models, with 205,474 unique made up names. For dependency fixes the rule follows directly: an upgrade should change versions of packages you already have. If the assistant proposes adding a package you did not ask for, stop and check that it exists and is the one you meant.
What you want from the scan, for each finding, is five facts: the package, the installed version, the version that fixes it, whether it is direct or transitive, and the path that pulls it in. Give the assistant those and it has something real to work with.
The four step loop
This loop works with any assistant that can read files and run commands with your approval. The commands below are real; swap in your own package manager.
Step 1: Scan
Pick the scanner that matches your ecosystem, or run one that covers several.
# Node: report in JSON, fail only on high or worse
npm audit --json > audit.json
npm audit --audit-level=high
# Python: audit a requirements file
pip-audit -r requirements.txt
# Several ecosystems at once
osv-scanner scan source -r .
# Safeguard CLI: build an SBOM and match it against vulnerability databases
safeguard scan --dir .
A few facts worth knowing. npm audit --audit-level changes the exit code threshold but does not filter the report. pip-audit is maintained under the Python Packaging Authority and licensed Apache-2.0; its --format flag can emit CycloneDX JSON. OSV-Scanner is Apache-2.0, queries the OSV.dev API, and covers more than 11 language ecosystems. safeguard scan writes JSON results under ./output, including vuln.json and license.json.
Step 2: Ask, with constraints
The quality of the fix depends on the prompt. Vague prompts produce wide diffs. Give the assistant the scan output and a short list of rules.
Here are the high and critical findings from the scan in ./output/vuln.json.
For each one, upgrade to the lowest version that fixes it.
Change only the manifest and the lockfile.
Do not add new packages.
Do not cross a major version without asking me first.
For transitive findings, tell me which parent you would upgrade before you change it.
Then list every package you changed, old version and new version.
Each line closes a door. "Lowest version that fixes it" keeps the change small. "Do not add new packages" guards against invented names. "Ask before a major version" matters because npm's docs warn that npm audit fix --force can install semver major changes, and that you should not use it unless you know what you want. The same caution applies to an assistant.
Step 3: Review the diff
Before any test runs, read what changed.
git status
git diff --stat
git diff package.json requirements.txt
git diff package-lock.json | head -200
What to look for:
- Only the manifest and lockfile changed. A dependency fix that also edits source files deserves a second look.
- Every version change maps to a finding from step 1. Anything else is scope creep.
- No new top level packages appeared.
- In the lockfile, the
resolvedURLs still point at your normal registry. - No
scriptsentries or install hooks changed inpackage.json.
If the diff is wider than the finding list, say no and ask again with a tighter rule.
Step 4: Approve the tests, then scan again
Now let the assistant run your install and tests. On Node, npm ci is a good check because it installs exactly what the lockfile says and exits with an error if package.json and the lockfile disagree, instead of quietly rewriting the lockfile.
npm ci
npm test
pip install -r requirements.txt && pytest
When the tests pass, run the same scan again. A finding is fixed when the scanner stops reporting it, not when the assistant says so. Codex's own CLI docs recommend Git checkpoints before and after a task so you can revert, and that habit fits this loop well: commit before step 2, commit again after step 4.
Do the work properly with the Safeguard CLI
The loop above works with any assistant. The Safeguard CLI puts all four steps in one place. It scans code, container images and SBOMs on your own machine, sends only the results to the platform, and includes an assistant that can fix what it finds. It writes code, not only scans it, and it already knows your vulnerabilities, so you do not have to copy scan output into a chat window.
Install
On macOS and Linux:
curl -fsSL https://cli.safeguard.sh/install | bash
On Windows, in PowerShell:
irm https://cli.safeguard.sh/install.ps1 | iex
It is a single static binary with no Node, Python or JVM to install first. It runs on macOS, Linux and Windows, on x86_64 or arm64; Windows is x86_64 only. The download page lists CLI 1.4.0 binaries for macOS Apple Silicon and Intel, Linux x86_64 and arm64, and Windows x86_64. The walkthrough in "Try it yourself" below shows the runner setup end to end.
First session
Move into the project and start the CLI with no arguments:
cd ~/projects/orders-service
safeguard
That opens the interactive terminal. Type /login to sign in through the browser, then /scan . to scan the current folder. From there you can ask in plain language. The docs give "how many critical vulns do we have" and "fix the lodash CVE in this repo" as examples. The assistant has tools for your local files and for your Safeguard data, and it picks whichever the question needs.
Two shortcuts help with dependency work. Type @ to attach a file from the folder you started in, such as package.json or requirements.txt. And /resume picks up your last session in that folder, so a fix you started before lunch is still there after.
Writing and fixing code
This is where the four steps collapse into one conversation. Ask for the fix with the same constraints as step 2. The assistant proposes the edit, and because writing a file, editing code and running a command all ask before they act, you see the change before it lands. Approve it, ask it to run the tests, approve that command, then /scan . again to confirm the finding is gone.
This walkthrough shows that loop: attach a computer running the Safeguard CLI and a folder, ask for a fix, review the diff and approve the command before it runs. The demo notes that computer work from Search is available and expanding.
Click through it at your own pace, or open it full screen.
The same assistant handles plain machine tasks too, with your approval: find a file, read a config, run a command. The docs' own example is "what's the latest file in ~/Downloads".
Using your Claude, ChatGPT or Codex plan
Bring the Claude, ChatGPT or Codex plan you already pay for and use it inside the Safeguard CLI. Safeguard adds no extra charge for that usage; your plan's own usage limits and terms still apply. /model shows or switches the model, and the CLI docs cover connecting one.
The second route keeps you in the chat you already use. Connect ChatGPT (or Claude) to the Safeguard MCP server and ask which findings are open, then do the edit wherever you prefer. This walkthrough connects ChatGPT to the Safeguard MCP server with OAuth and lets you choose which tools ChatGPT can use.
Click through it at your own pace, or open it full screen.
Approvals
/permissions sets one of three modes. Ask prompts before every action. Auto, the default, approves known actions and asks about anything new. Yolo approves everything. For dependency fixes in a repository you know, Auto is a sensible default: routine reads flow, and a new command such as an install still stops for you. Use Ask in a repository you have never touched. Keep Yolo for throwaway folders.
CI with safeguard exec
In a pipeline there is nobody to approve anything, so use the non-interactive commands:
safeguard scan --dir .
safeguard exec "summarise the critical findings in this repository"
safeguard exec runs one assistant turn and exits, which suits a CI step that posts a summary for reviewers. If you publish SBOMs, safeguard validate checks CycloneDX, SPDX and VEX documents before they leave the build. Policies and gates are evaluated in the Safeguard platform, not by the CLI, so the pass or fail decision lives there.
Your source code stays on your machine when the local runner runs platform scan jobs; only SBOMs and findings are uploaded. On the platform side you also get reachability analysis to help you decide which findings matter first, and autonomous remediation that can open fix pull requests (off by default).
A worked example, start to finish
Here is the whole loop on a generic repository with a Node API and a small Python worker. Package names and versions below are placeholders; your scan output will differ.
1. Checkpoint. Start clean so every change is easy to see and easy to undo.
git checkout -b fix/dependency-findings
git status
2. Scan.
safeguard
/login
/scan .
Then ask:
list the high and critical findings from that scan, with package, installed version, fixed version, and whether each is direct or transitive
3. Ask for the fix. Attach the manifests with @ so the assistant reads the real files.
@package.json @worker/requirements.txt
Upgrade each high and critical finding to the lowest fixed version.
Change only manifests and lockfiles. No new packages.
Ask me before any major version change.
For transitive findings, name the parent you would upgrade first.
4. Read the proposal. A good answer looks like this (illustrative):
api: example-parser 2.3.1 -> 2.3.4 (direct, patch release)
api: example-stream 1.0.2 -> 1.0.5 (transitive via example-http 4.1.0 -> 4.1.3)
worker: example-yaml 5.3 -> 5.4.1 (direct, minor release)
No major version changes needed.
Every line maps to a finding, the transitive one names its parent, and nothing new is added. Approve the edits.
5. Review the diff yourself.
git diff --stat
git diff package.json worker/requirements.txt
Expect three files: package.json, package-lock.json and worker/requirements.txt. If a source file shows up, ask why before going further.
6. Approve the tests.
run npm ci and npm test in the api folder, then pytest in worker
Each command asks before it runs. If a test fails, paste the failure back and ask for the smallest change that fixes it, or revert that one package and leave a note.
7. Scan again and commit.
/scan .
When the findings are gone, commit with the package list in the message so reviewers see exactly what moved.
8. Pick up later. If you stop halfway, start safeguard in the same folder tomorrow and type /resume.
That is the whole job: one branch, one scan, one constrained prompt, one reviewed diff, one test run, one confirming scan.
Tools people use for this job
There is no single right tool here, and many teams combine two or three. The table sticks to what each project's own docs say.
| Tool | What it is | What it does for this job | Changes files | How you stay in control |
|---|---|---|---|---|
| npm audit | Built into the npm CLI | Reports known vulnerabilities from the lockfile; npm audit fix applies remediations | Yes, with fix | --dry-run shows changes first; --force is needed for semver major and the docs warn against it unless you are sure |
| pip-audit | Python tool under the PyPA, Apache-2.0 | Audits environments or requirements files; --fix upgrades vulnerable packages | Yes, with --fix | --fix --dry-run prints the fix behaviour without applying it |
| OSV-Scanner | Go scanner, Apache-2.0 | Scans lockfiles in more than 11 ecosystems against OSV.dev | Only with the experimental guided remediation for npm and Maven | Docs warn guided remediation can be risky on untrusted projects |
| Dependabot security updates | GitHub service | Opens a pull request to the minimum patched version for an alert | Through a pull request | You review and merge the pull request |
| Claude Code | Anthropic's agentic coding tool | Edits manifests, runs installs and tests; /security-review checks changes on the current branch | Yes, per permission mode | Modes include Manual, acceptEdits, plan and auto; plan mode proposes without editing until you approve |
| Codex CLI | OpenAI's terminal coding agent | Edits and runs commands; /review reports findings on uncommitted changes, a commit or a base branch without modifying files | Yes, per sandbox and approval policy | workspace-write is the default mode for local work; approval policies include on-request |
| Safeguard CLI | Safeguard's terminal assistant and scanner | Scans, writes the fix, runs tests and rescans in one session | Yes, with your approval | Ask, Auto (default) or Yolo via /permissions |
Two notes on the agents. Claude Code's security docs say plainly that you are responsible for reviewing proposed code and commands before approval, and list "verify proposed changes to critical files" among their best practices. Codex's /review command reports prioritized findings without modifying your working tree. Both fit the loop above. For a wider look at the agents themselves, see our comparison of AI coding agents and the Claude Code alternatives guide.
Common mistakes
Asking before scanning. Without scan data the assistant can only guess. Scan first and paste or attach the findings.
Accepting a major version jump without reading the changelog. Major versions can change APIs. If the only fixed version is a new major, plan it as its own change with its own tests.
Fixing the manifest and forgetting the lockfile. The lockfile is what installs. Check git diff --stat shows both.
Letting the fix add packages. An upgrade should not introduce new names. Given the hallucination research above, treat any new package in a fix as a red flag until you have checked it.
Running npm audit fix --force because it was suggested. npm's own docs say not to unless you know what you want. The same applies when an assistant suggests it.
Trusting "fixed" without a rescan. Run the scanner again. The finding is closed when the scanner agrees.
Overriding a transitive version blindly. Package manager overrides can pin a sub-dependency to a version the parent was never tested with. Prefer upgrading the parent; if you must override, run the full test suite and note it in the commit.
Fixing everything in one giant change. Batch by risk instead. Patch releases together, each minor release on its own, each major as its own branch. Smaller diffs are easier to review and revert.
Leaving approvals on Yolo. It approves every command, including installs that run package scripts. Use Auto for daily work and Ask in unfamiliar repositories.
FAQ
Can an AI assistant find vulnerable dependencies by itself?
Not reliably from its own knowledge, because advisories are newer than any model's training data. Pair it with a scanner. The Safeguard CLI does both: /scan . produces findings, and the same assistant can read them and propose fixes.
Can I keep my Claude, ChatGPT or Codex plan and still use Safeguard?
Yes. Bring the Claude, ChatGPT or Codex plan you already pay for and use it inside the Safeguard CLI. Safeguard adds no extra charge for that usage; your plan's own usage limits and terms still apply. You can also connect Claude or ChatGPT to the Safeguard MCP server and use Safeguard from the chat you already use. See the CLI docs or /model for connecting a model.
Will the assistant change files without asking?
In the Safeguard CLI, writing a file, editing code and running a command ask before they act, according to your /permissions mode. Auto, the default, approves known actions and asks about anything new. Only Yolo approves everything, and you choose it yourself.
What about transitive dependencies?
Ask the assistant to name the parent package that pulls the vulnerable one in, and upgrade the parent where possible. Read the proposal before approving it, then rescan to confirm.
Does my source code leave my machine?
When the local runner runs platform scan jobs, your source code stays on your machine; only SBOMs and findings are uploaded.
Can I run this in CI?
Yes. safeguard scan --dir . writes JSON results under ./output, and safeguard exec "summarise the critical findings in this repository" runs one non-interactive assistant turn. Pass or fail decisions come from policies and gates in the platform.
Is this different from Dependabot?
Dependabot opens a pull request to the minimum patched version when GitHub raises an alert. A local assistant works before anything is pushed and can explain, adjust and test the change with you. Many teams use both.
Which approval mode should I use for dependency fixes?
Auto for repositories you know, Ask for unfamiliar or sensitive ones, and Yolo only in a disposable folder. More on how the assistant works in the Safeguard CLI on your machine.
Try it yourself
This walkthrough sets up the runner on your own machine: pick the platform, start it, approve it with its device code, then use the same CLI to scan from the terminal.
Click through it at your own pace, or open it full screen.
The same platform follows you off the terminal. The download page lists a desktop app (3.2.2) for Windows, macOS and Linux, iOS and Android apps, IDE extensions for VS Code, JetBrains and Open VSX editors, and a cloud sandbox against a seeded demo repo that is free for seven days with no card. Fix in the terminal, review on the desktop, check findings on your phone.
Ready to start? Download the Safeguard CLI, run safeguard, type /login, then /scan .. The full reference is in the CLI docs.
Quick check
Why should the scan come before the prompt?
Because a model's knowledge stops at its training cutoff and advisories are published every day. The scanner provides current findings; the assistant turns them into a fix.
What should a dependency fix diff usually contain?
The manifest and the lockfile, with version changes that each map to a finding. New packages or source file edits deserve a second look before you approve.
Sources
- Safeguard CLI overview
- Safeguard CLI interactive terminal
- Safeguard downloads
- npm audit documentation
- npm ci documentation
- pip-audit repository
- OSV-Scanner repository
- About Dependabot security updates
- We Have a Package for You! (package hallucinations study)
- Claude Code permission modes
- Claude Code security
- Codex CLI docs
- Codex sandboxing docs
Last reviewed: 21 October 2026.
