DEV Community: Amirthavarshini Marimuthu

I Fact-Checked Every Finding an AI Security Reviewer Gave Me. Here's What Held Up.

Amirthavarshini Marimuthu — Sun, 01 Nov 2026 20:40:57 +0000

During my internship at RakFort, one of my tasks was simple to describe and slow to do: run every security check in Secfoo with the Claude agent, and then check whether the AI was actually right.

Not "did the run finish". Not "does the report look good". Is each finding true?

This post is about what I found, and what I'd tell anyone who is starting to use AI for security reviews.

Quick background: what Secfoo is

Secfoo is an open-source tool that turns the AI coding agent you already use (Claude Code, Codex, Gemini CLI, Cursor, GitHub Copilot and others) into a security reviewer.

You point it at your code, pick a check, and it gives the AI clear instructions and a fixed report format. You get back a structured report with findings, severity and recommendations, and everything shows up in a local dashboard.

secfoo run --skill deployment-readiness --agent claude --target .
secfoo serve   # open the dashboard

It has 9 checks, including SAST, threat modeling, secret scanning, dependency triage, deployment readiness and responsible AI compliance.

How I tested

My target was Secfoo's own codebase (a good test, because I could read every file the AI talked about).

For each report I:

Opened every finding
Went to the exact file and line it pointed to
Checked the code as it was on the day of the scan (using the commit from that date, not today's code)
Marked it Confirmed, Partly wrong or Wrong
Checked that the numbers on the dashboard matched the report

Step 3 matters more than I expected. Code changes every day. If you check an old report against today's code, you'll blame the AI for things that were true at the time.

Results

Deployment readiness: 6 of 7 fully correct

#	Severity	Finding	Verdict
F1	High	Local dashboard has no login or CSRF protection	✅ Confirmed (exact lines were right)
F2	High	No security scanning in CI	⚠️ Partly wrong
F3	Medium	Release actions pinned by tag, long-lived tokens	✅ Confirmed
F4	Medium	Uploads saved to disk before the size check	✅ Confirmed
F5	Medium	Docker image runs as root, base image not pinned	✅ Confirmed
F6	Low	No health endpoint	✅ Confirmed
F7	Low	Dependencies have no upper version pins	✅ Confirmed

Responsible AI compliance: 4 of 4 correct

All four findings were accurate, and the overall rating ("Low") made sense for a tool that doesn't make decisions about people.

The interesting one: F2

Most of F2 was right. CI really didn't run any security scanners, and the linter was set to never fail the build.

But the report also said the release workflow "runs on any v* tag push".

It didn't. The workflow had been changed to manual-only five days before the scan. The file even had a comment at the top explaining the change.

So the AI described how the project used to work. My guess is that it matched a very common pattern ("release on tag push") instead of reading the current trigger carefully.

This is exactly the kind of mistake that is easy to miss:

It sounds completely reasonable
It's in a well-formatted report next to six correct findings
It's only wrong in one detail

If I had just skimmed the report, I would have believed it.

Things I tested besides the reports

Bad input. I fed the CLI things a real user might get wrong: a folder that doesn't exist, a file instead of a folder, an unknown skill or agent name, a GitHub repo that doesn't exist. Every one gave a clear error, with no crash and no AI tokens wasted. I found two small issues (a negative --timeout was accepted, and an empty target quietly scanned the current folder) and reported them.

The dashboard. All pages loaded and the finding counts matched the reports, except the home page, which crashed with a 500 error. The cause was a recent change: agents that don't report cost now store "unknown" instead of $0, and the home page added the costs together with a plain sum(), which fails on an empty value. It was a one-line fix, and my PR for it (#31) is now merged.

What I learned

1. AI reviewers are genuinely useful. Most findings were correct, with the right file and line numbers. For coverage and speed, it's a huge help, especially for a small team.

2. "Looks professional" is not the same as "true". The one wrong detail was written just as confidently as the correct ones. Severity labels and neat tables don't make a finding correct.

3. Check against the right version of the code. Use the commit from the scan date. Otherwise you'll mark correct findings as wrong (or the other way round).

4. Keep a human in the loop for anything that matters. If a report is going to someone who will sign it off, every finding should be checked first. It took me a while, but it's much faster than reviewing the code from scratch.

Try it

Secfoo is free and open source (MIT). If you're a student or developer interested in security, try it on your own project and check the findings yourself. That's honestly the best way to learn what AI reviewers are good and bad at.

👉 https://github.com/secfoo-com/secfoo

Feedback, issues and contributions are welcome. I'd love to hear how it does on your code!

This is my second post about Secfoo. The first one was about catching an AI scanner inventing fake vulnerabilities.

security #ai #opensource #testing

SecFoo — I Caught Our Security Scanner Inventing Fake Vulnerabilities — Here's the Proof!

Amirthavarshini Marimuthu — Wed, 07 Oct 2026 16:31:51 +0000

What is Secfoo?

Secfoo is an open-source CLI that turns an AI coding agent into a disciplined security reviewer. Instead of building its own scanner, it hands your codebase and a specific review checklist to an AI agent you already have like Claude Code, Cursor, Gemini CLI, Codex, and few others - lets it actually read the code the way a human security reviewer would.

You pick a target (a local folder or a GitHub repo), pick one or more checks to run, and Secfoo does the rest: renders the right prompt, runs the agent, and stores the results in a local dashboard you can browse in your browser. It can run 8 different kinds of review — architecture, threat modeling, SAST, SCA, secret scanning, prompt review, deployment readiness, and responsible AI compliance.

Part of my internship on Secfoo was real simple: install it, use it like a real user would, and see if it actually does what it claims.

One of its agent options broke that promise on the very first real test I ran. Here's exactly how I proved it, because "the AI made something up" is a big claim, and I wanted receipts, not a hunch.

The setup

Secfoo has a "no coding-agent CLI needed" option — give it an API key, and it talks straight to a model instead of needing Claude Code or Cursor installed. I pointed it at a small folder in Secfoo's own codebase and asked for a SAST (static code analysis) scan:

secfoo run --skill sast --target src/secfoo/report --agent secfoo

It came back successful, with 3 findings — 1 High, 1 High, 1 Medium. Confident-looking report, proper CWE IDs, CVSS vectors, even illustrative fix diffs.

The first red flag

Secfoo saves the exact prompt it sends to the model, alongside the report. So before trusting the output, I checked what the AI had actually been shown:

grep -c "def \|class \|import " prompt.md
# 0

Zero. Out of 161 lines. The entire prompt was instructions and a single line:

## **Target**
Inspect the codebase at: `/path/to/src/secfoo/report`

That's it. No file contents. Nothing. The model was told to review code it was never actually shown.

The proof it made things up

The report cited three "High/Medium" vulnerabilities, each with a specific file path:

db/query_handler.py:15 — SQL injection
template/render.py:45 — XSS
file_upload/upload.py:30 — path traversal

None of those files exist. Anywhere in the project. I checked with find. The folder I scanned only has 7 files, and not one of them is named any of those. The AI had nothing real to look at, so it generated the textbook example anyone would expect from "write me a SAST report" with zero actual input — and reported it with full confidence, including the line "Confidence in this assessment is moderate to high."

Ruling out "maybe the AI is just unreliable"

Before calling this a tool bug rather than a model limitation, I ran the exact same skill, on the exact same folder, through a different built-in option in Secfoo — one that actually reads files first. That one:

Correctly named all 7 real files in the folder
Cited a real, specific line of code accurately — down to the exact syntax
Found 0 issues and said so honestly, instead of padding the report to look thorough

Same tool, same folder, same day. One option told the truth. The other one guessed and called it confidence.

Why this matters more than a normal bug??

A security tool's entire value is that you can trust what it tells you. A tool that invents vulnerabilities is worse than one that finds nothing — it burns your time chasing ghosts, or worse, gives you false confidence that a real issue doesn't exist.

The good news: this is now fixed — the team removed the broken implementation. But it's a good reminder for anyone building on top of an LLM: "the run succeeded and returned a well-formatted answer" is not the same claim as "the answer is true." If your pipeline can check its own inputs the way I did here — just read the prompt you're about to log — do it. It's a five-second check that would have caught this before it ever shipped.