Yes, you still need a scanner. An AI reviewer reads your change and offers opinions. A scanner checks every library you use against a list of known flaws and does it the same way every time. One is judgment, the other is lookup. Good teams use both and add a gate so neither step is skipped.
TL;DR: AI review is good at spotting odd logic in the lines someone just wrote. A scanner is good at finding known problems in the hundreds of libraries you did not write. A gate on the pull request keeps both honest. Dropping the scanner because the AI "looked at everything" leaves a gap.
Definition: security scanner. A security scanner is a tool that lists the parts inside your software and compares each part and version against a database of publicly known vulnerabilities, then reports the matches.
What does an AI code reviewer actually look at?
When you ask an AI assistant to review code, it usually reads the change in front of it. That might be one file, one function, or the difference between the old version and the new one. It then writes comments such as "this input is not checked" or "this loop could be slow."
That is useful. A good reviewer notices things a tired human misses. It can also explain a confusing block of code in plain words.
But the reviewer has limits that are easy to forget:
- It sees what you show it. It does not automatically see the 300 libraries your project pulls in, or the libraries those libraries pull in.
- Its knowledge has a date. An AI model learns from data up to a certain point. A flaw published last week may not be in what it learned.
- It can be wrong with confidence. It may say a library version is safe when it is not, or flag a harmless line as dangerous.
- It may answer differently on a second try. Ask twice, and you may get two different lists of concerns.
None of that makes AI review bad. It makes it a different kind of check.
What does a scanner do that an AI reviewer does not?
Most modern software is built from outside parts called dependencies. A dependency is a library of code written by someone else that your project uses. Our guide to what a dependency is in programming explains the idea in more detail.
A scanner builds a list of those parts, including the ones hidden several levels down. Then it checks each name and version against a database of known vulnerabilities. If version 4.17.11 of a library has a published flaw, the scanner reports it every time, in the same words, with a fixed version if one exists.
That repeatability matters. An auditor, a customer or your own future self can ask "what did you check, and when?" and get a real answer. A chat reply is much harder to defend.
A scanner also runs without anyone remembering to ask. It can run on every pull request, nightly, or whenever a new flaw is published.
How do the two checks compare?
| Question | AI review | Security scanner |
|---|---|---|
| What does it read? | The code you show it | Your full list of libraries and versions |
| How does it decide? | Reasoning, which can vary | Matching against a known flaw database |
| Same answer each time? | Not always | Yes, for the same input and database |
| Finds odd logic in new code? | Often | Not its job |
| Finds known flaws in libraries? | Only if it happens to know | Yes, that is its job |
| Leaves a record? | A chat or a comment | A report you can save and compare |
The table shows why the two checks fit together. One covers the lines your team wrote. The other covers the many lines they did not.
What does a worked example look like?
Every number here is invented for illustration.
A team ships a small web service. It has 12 files of its own code and pulls in 180 libraries when you count the hidden ones.
- The AI reviewer reads the 12 files and leaves 6 comments. Four are small style points. One finds a missing check on a form field. One is a false alarm.
- A scanner lists all 180 libraries and finds 24 known flaws across 9 of them.
- The AI reviewer mentions 1 of those 9 libraries. It says nothing about the other 8.
If the team had relied on AI review alone, it would have fixed the form field and heard about 1 of 9 risky libraries. With both checks, the form field and all 9 libraries are on the list.
The scanner's 24 findings are not all equally urgent. A fair next step is to ask which flaws your code can actually reach. That question is called reachability, and it often cuts a long list down to a short one.
How do you use both checks without extra work?
Here is a simple setup a small team can copy.
- Scan on every pull request. A pull request is a proposed change that other people can read before it is accepted. Run the scanner there so new problems show up before they merge.
- Ask the AI to review the same change. Use it for logic, naming and missing checks in the new code.
- Read both outputs together. If the AI says "this looks fine" and the scanner reports a critical flaw, the scanner result wins until a person says otherwise.
- Add a gate. A gate is a rule that blocks a merge when a check fails, for example "no critical findings with a fix available."
- Re-scan on a schedule. New flaws are published every day, so code that was clean last month can have a known problem today.
- Keep the reports. Save scan results with the pull request so you can answer questions later.
Our post on why a clean scan does not mean your software is safe is worth reading next, because it explains what a scan does not cover either.
Can an AI assistant use a scanner for me?
Yes, in many setups. An assistant can be connected to a scanner so it can look up results instead of guessing. That gives you the friendly explanations of an assistant with the factual lookup of a scanner. The scanner still does the checking. The assistant just helps you read it. You can see how this works in our post on whether an AI assistant can use a security scanner through MCP.
Where does Safeguard fit in?
Safeguard handles the scanner side. It builds a software bill of materials (a complete list of the components in your application), scans dependencies for known flaws, and uses reachability analysis to show which ones your code can actually trigger. Policies and gates can block a pull request that breaks your rules. It can also open fix pull requests. That feature is off by default, with every category on Manual, so a person turns it on.
The Safeguard command line tool runs on your own machine. According to the CLI page, it scans a folder, a Git repository, a container image or an existing bill of materials, and only the scan results leave your machine, not your source code. The CLI can also write code, which is useful for turning a finding into a change you can review.
Try the free scan at gold.safeguard.sh/scan, or see the installers on the download page.
Try it yourself
Open the demo below and look at the list of components it builds. Notice how many are libraries nobody on the team wrote, and how each one carries a version you can check.
Click through it at your own pace, or open it full screen.
Quick check
If my AI assistant says my dependencies look fine, is that enough?
No. The assistant may not have seen your full list of libraries, and its knowledge stops at a training date. A scanner checks every listed version against a current database of known flaws.
Can an AI reviewer replace a human reviewer?
It can help, but a person should still read the change, especially for anything that touches sign in, payments or private data. Treat the AI as a second reader, not the final approver.
How often should I scan?
On every pull request, and again on a schedule such as nightly or weekly. New flaws are published after your code is written, so a clean result today can change tomorrow.
What is a gate?
A gate is an automatic rule that stops a change from merging if a check fails. For example, it can block any pull request that adds a critical flaw with a fix available.
Sources
Last reviewed: 19 October 2026.
