If we already run SAST and dependency scanning in CI, do we still need a manual audit?

Yes, if you care about the bug classes scanners structurally miss. Automated tools catch pattern-shaped problems like string-built SQL and known CVEs, but authorization logic errors, business logic flaws, and consistency gaps have no syntactic signature, so no rule engine fires on them. Keep the pipeline running and add periodic human review on top; the two cover each other's blind spots.

Why does raw SAST output feel useless on a mature codebase?

Because a first scan typically returns hundreds or thousands of findings, most of them false positives or true but irrelevant to your actual risk. Unfiltered, that noise trains the team to ignore the tool, which is worse than not having it. Human triage is what turns a scanner report into an audit: hundreds of raw findings become the dozen that matter for your business.

Are LLM-based code review tools a substitute for a human auditor?

Not yet. They are genuinely useful for summarizing code and flagging suspicious spots, but they are still confidently wrong often enough that their output needs the same human triage as any other scanner. Treat them as another breadth tool, not as the judgment layer.

How can I tell whether a paid audit is really just a scanner run with a cover page?

Read a sample report: if every finding has a rule ID and none has business context, it is tool output you could replicate in-house for nearly free. A real audit shows triage, logic and consistency findings, and severity judged against your specific system. Webisoft's free audit is the layered kind, tooling for breadth plus an engineer reading the paths tools cannot judge, delivered as a written report within a few business days.

Manual vs. Automated Code Audits: Which One You Actually Need

Q: Which automated tools should a team set up first?

Dependency scanning and secret scanning in CI, this week if you have neither. They take an afternoon to set up and retire a whole category of embarrassing findings before any human ever reads the code. Static analysis (Semgrep, CodeQL, SonarQube and kin) is the sensible next layer.

Somewhere in your inbox is a vendor promising to “audit your entire codebase in minutes with AI-powered analysis,” and somewhere else a consultancy quoting weeks of senior-engineer time for what sounds like the same thing. They are not the same thing. They’re not even competing things: they catch different classes of problems, and the marketing on both sides does its best to blur that.

Here’s the honest division of labor.

What automated analysis actually is

“Automated audit” covers several distinct tool families, worth separating because they have different blind spots:

Dependency scanners (npm audit, pip-audit, OWASP Dependency-Check, Dependabot-style services): match your dependency versions against published CVE databases.
Static analysis / SAST (Semgrep, CodeQL, SonarQube and kin): pattern-match your source for known-bad constructs: SQL built by string concatenation, eval on user input, weak crypto primitives, tainted data flowing to dangerous sinks.
Secret scanners (gitleaks, trufflehog): hunt for key-shaped strings in the working tree and, importantly, in history.
Linters and metric tools: complexity scores, duplication, style. Hygiene signal, not risk signal.
LLM-based review tools: the new entrant; genuinely useful at summarizing and flagging suspicious code, still confidently wrong often enough that their output needs the same human triage as everything above.

What automation is genuinely good at

Credit where due. An audit without tooling is malpractice in the other direction:

Coverage. A scanner reads all 400,000 lines and all 400 transitive dependencies. No human does.
Known-vulnerability lookup. Whether lodash 4.17.15 has a published CVE is a database question. Machines answer database questions.
Pattern-shaped bugs. If the bug class has a reliable syntactic signature (string-interpolated SQL, missing HttpOnly on session cookies, hardcoded AWS keys), tooling finds it cheaply and repeatably.
Regression prevention. Run in CI, the same checks apply to every future commit. A human audit is a snapshot; a pipeline is a policy.
Cost. Cents per run. This matters and shouldn’t be waved away.

If you run nothing automated today, start there this week: dependency scanning and secret scanning in CI are an afternoon of setup and they retire a whole category of embarrassing findings before any human audit begins.

What automation structurally cannot catch

The key insight: scanners detect code that looks wrong. They cannot detect code that looks fine and is wrong, because that judgment requires knowing what the code is supposed to do, and no tool knows your business.

Concretely, the finding types that in our experience only humans produce:

Authorization logic errors. db.invoices.findById(req.params.id) is syntactically immaculate. The missing WHERE tenant_id = ? is invisible to a scanner because the scanner doesn’t know you’re multi-tenant. Broken object-level authorization (perennially at the top of real-world vulnerability lists) is almost entirely a human-found class.
Business logic flaws. The discount code that can be applied twice, the refund path that skips the fraud check, the race between checkout and inventory. Correct-looking code doing the wrong thing.
Consistency failures. Validation applied in nine handlers out of ten. Each handler individually passes every scan; the gap is the vulnerability, and gaps have no syntax.
Architecture and design debt. No tool output says “your billing rules are duplicated between the API and a worker, and they’ve already drifted.” That’s a reading-comprehension finding.
Misleading tests. A suite that mocks the world and asserts the mocks green-lights every scanner and catches nothing. Judging whether tests would catch a real bug requires reading them as an engineer.
Severity in context. A scanner rates the CVE; it can’t know the affected code path is dead, or conversely that a “Medium” sits directly on your payment flow. Context is triage, and triage is the deliverable.

There’s also the noise problem in the other direction: raw SAST output on a mature codebase runs to hundreds or thousands of findings, most false positives or true-but-irrelevant. Unfiltered, this is worse than useless: it trains teams to ignore the tool. The distinction between reviewing changes and auditing systems has a similar shape, which we unpack in code audit vs. code review.

What manual review costs you

Symmetry demands the same honesty about humans:

Expensive and slow. Senior-engineer reading time is the priciest input in software.
Sampled, not exhaustive. A human audit reads critical paths line-by-line and samples the rest. If a bug hides in unsampled CRUD, a human can miss what a pattern-matcher wouldn’t.
Point-in-time. The report describes a commit hash. Tuesday’s merge is out of scope forever.
Variable. Quality depends on the reviewer. Tooling is at least consistently mediocre; humans range wider in both directions.

The actual answer: layered, not either/or

The framing “manual vs. automated” is the marketing artifact. Every competent professional audit is both, in a specific order:

Tooling first, breadth pass. Dependency scan, secret scan, SAST across everything. Machines do the exhaustive, boring part.
Human triage of tool output. Hundreds of raw findings become the dozen that matter for this business. This step is where “scanner report” becomes “audit.”
Human deep-dive where tools can’t go. Line-by-line on auth, money, and PII paths; consistency checks across entry points; test trustworthiness; architecture judgment. What that judgment is calibrated against is its own topic: see what good code looks like to an auditor.
Tooling last, as a leave-behind. The good audits convert findings into CI checks so the fixed bug class stays fixed.

So the honest purchase advice: if a vendor’s “audit” is a scanner run with a cover page (you can tell because every finding has a rule ID and none has business context), you can replicate it in-house for nearly free. Pay (or in our case, don’t pay) for the parts that require a human: triage, logic, consistency, and severity-in-context. And for a sense of which real-world vulnerability classes each layer historically catches, see the top security vulnerabilities code audits catch: the pattern-shaped ones fall to tooling, the logic-shaped ones stubbornly don’t.

Get a free code audit

Webisoft’s free audit is the layered kind: tooling for breadth, then a Webisoft engineer manually reviewing your repository (the authorization paths, the consistency gaps, the things scanners can’t see) and sending you a written, severity-ranked findings report with evidence. It’s genuinely free and read-only; the report is yours whether or not you ever want help acting on it.

Get a free code audit. The scanner pass you could do yourself; the human pass is the part worth taking us up on.