SAST vs manual secure code review

SAST vs manual secure code review: which one to buy first

SAST is the continuous baseline and manual review is the targeted depth. If your team ships code often and has no automated checks on every commit, start with static analysis: it runs on each change, flags known flaw patterns, and gives developers findings while the code is still fresh. If your team holds one critical component, such as an authorization service, a payment flow or a cryptographic module, the first purchase is usually a manual review, because the risks there depend on what the code is supposed to do. NIST SA-11(4) reserves manual code reviews for critical software and firmware components and notes they are effective where a weakness needs knowledge of the application's requirements, such as verifying an access control matrix or a cryptographic implementation.

Ask one question before you buy: which failure would hurt you most? If the answer is a dangerous library call, an injection pattern or a hard-coded secret, a SAST tool will find more of those, more often, at lower cost per change. If the answer is that a user can reach another tenant's records or that a refund can be issued twice, no pattern matcher will reason about that. Your reviewers need the requirements, the role model and the intended workflow. Confirm with any vendor or reviewer whether their work includes the design documents and access to developers, since OWASP ASVS 5.0.0 notes that higher-level requirements need source code, documentation, configuration and the development team, not only black box testing.

Most programs end up combining the two, but the order matters. Buy the continuous tool first when you have many repositories and no one to read them, then schedule manual review of the components that touch money, identity or regulated data. Under NIST SSDF task PW.7.2, a static analysis tool paired with a human who reviews and remediates the reported issues is an accepted pattern, so the tool and the reviewer are meant to work together. When you request a quote for manual review, ask for the scope by component, the reviewer's experience with your language and framework, and the deliverable: a list of findings with remediation guidance, or a re-test after fixes.

How SAST and manual code review compare on scope, method and effort

This table compares automated static analysis with expert reading of source code across scope, method, cost and what the team must supply. Read it through the NIST SSDF PW.7.1 split: code analysis is performed by tools, alone or with a person, while code review is a person looking directly at the code. The main takeaway is that the two answer different questions, so the choice depends on what must be proven and where in the life cycle.

Dimension	SAST (code analysis)	Manual secure code review (code review)
Goal	Find known flaw patterns quickly and consistently across the codebase	Find flaws that depend on application requirements, context or design intent
What is inspected	Source or compiled code against rule sets for injection, unsafe APIs and similar patterns	Selected modules, access control matrices, cryptographic implementations and business logic
Who performs it	Tools run by the pipeline, with a developer or security engineer triaging results	Experienced reviewers who read the code and the requirements behind it
Run frequency	Can run on every commit or pull request	Scheduled or triggered for critical components, releases or major design changes
Typical output	Ranked findings with rule IDs and code locations, many needing triage	Written findings tied to requirements, with reasoning and proposed fixes
False positive handling	Developers or analysts suppress or tune rules, so tuning effort recurs as code changes	Reviewers filter findings during the review, so noise is low but volume is limited
Language and framework coverage	Depends on the tool's supported languages and frameworks, so confirm coverage for each stack	Depends on reviewer skill in the languages and frameworks in scope
Time to first result	Often within the first pipeline run once the tool is configured	Set by reviewer scheduling and scope, so it runs over days or weeks
What the team must supply	Build access, tool licenses or hosting, rule configuration and triage ownership	Source access, design documents, requirements, environment details and developer time to answer questions

How each method works in practice

Static application security testing (SAST) is tool-driven code analysis. The tool takes source code, or in some products compiled code, as its input and matches it against a rule set that describes known flaw patterns, such as untrusted input reaching a database query or a deprecated hash function being called. It runs automatically, usually on each commit or pull request, so results arrive while the developer still has the change in front of them. NIST SP 800-218 treats this as code analysis, where tools find issues either fully automatically or together with a person.

Inputs: the repository at the commit under test, build configuration needed for compiled languages, and sometimes dependency manifests. Confirm with the vendor which languages and frameworks the rule set covers and how it handles generated or vendored code.
Rule sets: the vendor's default profile plus any custom rules your security team writes. Tune the profile before enforcing it, because a noisy default produces alerts developers learn to ignore.
Triage: NIST SSDF task PW.7.2 gives the example of a static analysis tool with a human reviewing and remediating the reported issues. The person decides which findings are real, which are false positives and which need a suppression with a recorded reason.
Gating: decide which severities block a merge and which only report. Blocking everything at launch usually leads to suppression by habit.
Operating cost: licensing or hosting of the scanner, plus the engineering time to tune rules and handle triage queues, recurs for as long as the pipeline runs.

Before adopting SAST, ask the vendor which flaw classes its rules cover and which they explicitly do not, and confirm how it handles frameworks your team uses.

What SAST catches and misses, and what manual review catches and misses

SAST and manual review look at the same source code but answer different questions. Automated analysis is strong at repeatable flaw patterns on every commit, while an expert reader is needed for flaws that depend on what the application is supposed to do.

Known flaw patterns and injection

SAST tools match code against rules for patterns such as tainted input reaching a SQL query, a shell command or an HTML output without encoding. Because the pattern is local and repeatable, the tool can run on every commit and flag the same mistake across thousands of files. The blind spots are data that passes through custom wrappers, frameworks the rule set does not model, and flows that cross service boundaries. Check how your chosen tool handles your frameworks before trusting a clean report.

Access control needs the intended rules

A static tool can see that a handler reads an object ID, but it cannot know which roles should own that object. Manual reviewers compare the code against the access control matrix and ask whether each endpoint enforces it. ASVS 5.0.0 Level 2 and 3 verification needs source, documentation and development team access for this reason. Ask the reviewer for the matrix before the review starts.

Business logic and context

Flaws such as a discount applied twice, a refund issued before payment clears or a workflow step skipped by changing a parameter are correct code that does the wrong thing. SAST has no model of the business rule, so it reports nothing, and dynamic scanners rarely exercise these paths. A human reader who knows the process can trace the state changes and test the sequence that breaks them.

Cryptography misuse

Consider a home-made single sign-on scheme that MD5-hashes the username and date with no secret key (illustrative of the OWASP WSTG example). A reviewer reading the code sees that the token is derived from public values and can be forged, while a black-box scanner sees only an unpredictable-looking hash. SAST can flag weak algorithm names, but it usually cannot judge whether a scheme is sound. Confirm that reviewers include cryptography specialists for authentication and key handling code.

Backdoors and malicious content

NIST SSDF task PW.7.2 includes expert reviewers checking code for backdoors and other malicious content. Pattern rules rarely flag a hard-coded trigger that looks like a legitimate feature flag or a condition that activates on a specific date. Human review is the control that addresses insider and supply chain concerns, and it is usually reserved for critical components. Decide which modules qualify and document who reviewed them.

Coverage and repeatability

Manual review is expensive per line and depends on reviewer skill, so it cannot cover a large codebase on every change. NIST SA-11(4) guidance says manual code reviews are usually reserved for critical software and firmware components. Use SAST for breadth and repeatability, then spend reviewer time on the components where context changes the answer. Ask a reviewer how they scope the review and what they will not cover.

Which code deserves manual review and which can rely on SAST

Manual review should be reserved for the code where a flaw would do the most damage. NIST SA-11(4) guidance says manual code reviews are usually reserved for critical software and firmware components, because they find weaknesses that depend on knowing what the application is supposed to do. Start by listing the components that carry authentication and session handling, the authorization matrix that decides who can see or change what, the cryptographic implementations that protect keys and data, and the payment or regulated data paths. Those are the places where a pattern-matching tool can report a clean result while the logic is still wrong, so they earn a human reader.

Add a second filter for code that has recently crossed a trust boundary. New or changed endpoints, new integrations with third-party services, and modules that accept input from a new class of user are higher priority than code that has been stable and exposed for years. Ask each component owner to name the data it touches and who is allowed to call it, then take those answers to your risk owners. Criticality is a business decision, and the reader should confirm the list with the people who accept the residual risk rather than relying on engineering's view alone.

Routine code can rely on automated analysis, provided findings are triaged. Helpers, formatting, internal utilities and well-bounded CRUD code with no sensitive data can run through SAST on every commit, with a named owner reviewing each finding and recording whether it was fixed, suppressed or accepted. Set a rule that suppressions need a reason and a second approver, and revisit the critical list whenever a component changes scope. The result is a documented decision for every part of the codebase, which is the evidence an assessor will ask to see.

How NIST SSDF combines code review and code analysis in the life cycle

The sequence pairs automated code analysis on every change with human triage, targeted manual review of critical components before release, and expert checks where malicious content is a credible risk, so each layer leaves its own record.

Define which code is in scope for each layer
The team decides which repositories and components get automated analysis, which critical components get manual review, and which warrant expert checks for backdoors or malicious content. Security engineering and the component owners agree the list and record it in the team's secure development procedures. NIST SSDF task PW.7.1 separates code review, where a person looks directly at the code, from code analysis, where tools find issues on their own or with a person. Knowing which layer applies to which code is the first decision. The output is a written scope that names the components and the reason each layer applies to them.
Run automated code analysis on each change
A static analysis tool runs as part of the build or pull request workflow on each change, so findings appear before the code merges. The developer or the security engineer who owns the pipeline configures the rule set and records which rules are blocking and which are advisory. Tool choice and run frequency are the team's decisions, since SSDF task PW.7.2 does not name a specific tool or cadence. The output is a scan result attached to each change, along with the rule configuration that produced it.
Triage reported issues with a human reviewer
A person reviews each reported issue, confirms or dismisses it with a short reason, and assigns fixes for confirmed findings. This is the human step PW.7.2 describes, where a static analysis tool is used with a human reviewing and remediating the reported issues. Triage is where false positives are removed and where a reviewer notices that a flagged pattern is actually safe in context. The output is a triage record for each finding: confirmed, dismissed with reason, or accepted as risk with an owner.
Perform targeted manual review before release
Before a critical component ships, an experienced reviewer reads the code paths that depend on application context, such as access control decisions, authorization logic, and cryptographic implementations. NIST SA-11(4) guidance says manual code reviews are usually reserved for critical software and effective at finding weaknesses that need knowledge of the application's requirements. The reviewer checks the code against the documented requirements and design, not only against tool output. The output is a review report listing the paths examined, the defects found, and the fixes or accepted risks, signed off by someone outside the author's team.
Check high-risk components for backdoors or malicious content
Where the risk warrants it, expert reviewers look for backdoors, hidden functionality, and other malicious content that automated rules are not designed to detect. This step is typically reserved for components with elevated supply chain or privileged access exposure, and the owner decides which components qualify. SSDF task PW.7.2 lists expert reviewers checking code for backdoors and other malicious content as one example. The output is a documented review of the selected components, with the scope, reviewer identity, and any unexplained code recorded.
Remediate, retest, and close each finding
Developers fix confirmed findings, and the team reruns the relevant analysis to confirm the fix does not reintroduce the flaw. Manual review findings go back to the reviewer for verification. Open items that the team accepts as risk need a named owner and a recorded reason. The output is a closed findings register in which every item shows its status, fix reference, and verification result.
Retain the evidence for assessors
The team keeps the scan results, triage records, manual review reports, and expert review records together, linked to the release they support. These records let an internal assessor or an external auditor trace a release back to the checks it passed. Ask your assessor which retention period and format they expect, because the SSDF does not set one. The output is a release evidence package that shows which layers ran, who performed them, and how each finding was resolved.

What drives the cost and effort of each approach

SAST and manual secure code review have different cost structures: one is mostly tooling and triage that recur with every commit, the other is mostly expert time that scales with what is reviewed. The cards below separate one-time setup from recurring work so you can ask each quote to break out the same components.

SAST tool licensing or self-hosting

Commercial SAST is usually billed per developer, per line of code or per application, and open-source engines carry no license fee but still need hosting, updates and a team to run them. Ask whether a quote covers the scanner, the CI integration, and support as separate lines. Licensing recurs annually, while self-hosting moves cost into infrastructure and staff time. Confirm the metric the vendor uses before comparing quotes.

SAST rule tuning

Default rule sets are written for broad coverage, so they fire on framework idioms and internal helper functions that are safe in your code. Tuning means disabling irrelevant queries, writing custom sources and sinks for your own sanitizers, and re-checking after each major framework upgrade. This is mostly one-time work at onboarding, with smaller recurring effort whenever the stack changes. Ask who owns tuning and whether it is in scope.

SAST triage volume

Every commit can produce findings, and each one needs a developer or security engineer to confirm, dismiss or fix it. Volume rises with codebase size, the number of languages in use and how loose the rule set is. This is a recurring cost that often exceeds the license fee in practice. Ask a provider how many findings a typical application generates on first scan and how the backlog is handed over.

SAST CI integration and false positive backlog

Wiring the scanner into pull requests, build gates and ticketing takes setup effort, and every change to the pipeline needs testing. Initial scans often leave a false positive backlog that must be suppressed with documented reasons, or teams will ignore the tool. Both costs recur whenever pipelines or languages change. Ask whether the quote includes baseline suppression and who maintains the suppression records.

Manual review reviewer expertise

Manual review is paid mostly as expert time, and the rate depends on the reviewer's depth in the language, framework, authentication design and cryptography involved. NIST SA-11(4) reserves manual review for critical components because it relies on knowledge of application requirements. Ask whether reviewers hold relevant credentials, and whether the quote names the seniority mix. Expertise drives both price and the quality of findings on access control and business logic.

Manual review scope and codebase size

Reviewer hours scale with the lines and modules in scope, the number of trust boundaries and the number of components that handle sensitive data. Narrowing scope to authentication, authorization, payment flows and cryptographic code reduces effort but leaves other code unreviewed. Ask the provider to list the components in scope by name, with the review depth for each, before agreeing a fixed scope.

Access to documentation and developers

Reviews go faster and find more when reviewers can read design documents, configuration and developers' explanations. OWASP ASVS 5.0.0 notes that verifying many Level 2 and Level 3 requirements needs source, documentation and the development team, not only black box testing. Missing access adds discovery time and can lower coverage. Ask what material the client must provide before the review starts and who is the named contact.

Retest after fixes

Each round of fixes needs a reviewer to confirm the change closes the flaw and does not add a new one. For manual review this is a separate, usually smaller, fee that repeats until findings are closed. For SAST, retesting is largely automatic on the next scan, but someone still has to validate the dismissals. Ask whether retests are included in the fixed scope and how many rounds the quote covers.

Questions buyers ask before hiring help on SAST or manual review

Does SAST alone satisfy a secure code review requirement?

Usually not on its own, because a secure code review asks for a person to examine the code, and SAST only covers part of that. NIST SSDF task PW.7.1 separates code review, where a person looks directly at the code, from code analysis, where tools find issues automatically or together with a person. NIST's PW.7.2 examples pair a static analysis tool with a human who reviews and remediates the reported issues. Check the exact wording of your contract, customer questionnaire or assessor's requirement, since some ask for a named reviewer or a documented review, and confirm with the assessor which of the two they expect before you scope the work.

What does a manual code review need from our team?

A manual review needs the source code, the design or requirements that define correct behavior, and access to a developer who can explain intent. NIST SA-11(4) guidance notes that manual reviews work best on problems that depend on the application's requirements or context, such as access control matrices and cryptographic implementations, so the reviewer needs those specifications. OWASP ASVS 5.0.0 adds that many Level 2 and Level 3 requirements need documentation, configuration and development team access, not only black box testing. Plan developer time for walkthroughs and questions, and ask any provider to list the artifacts they need before work starts.

How long does a manual code review take, and what drives the duration?

The duration depends mainly on the size and complexity of the code in scope, how well the code is documented, and how many people must answer questions. No supplied source gives a standard duration, so ask each provider for its estimate in writing and check it against the scope you define. Reviews of critical components take longer because SA-11(4) reserves manual review for critical software and firmware, which tends to narrow the scope to high-value code. Clear architecture notes and a named developer contact typically shorten the work, while missing requirements usually extend it.

Can our own team run SAST in-house?

Often yes for the tooling itself, but the effort goes into configuration, triage and remediation rather than the scan. A SAST tool needs a build integration, rule tuning and an owner who reads the results, and NIST SSDF expects a human to review and remediate the reported issues. Costs fall into licenses or hosting for the tool, the engineer time to integrate it, and the recurring time to triage findings. Confirm the license terms and whether your team has someone to own the findings queue before you decide. DeployOpen can plan, implement and document a self-hosted SAST setup inside your own infrastructure, with scope and deliverables agreed in writing first.

How should we handle false positives from SAST?

Triage every finding into a documented outcome: fix, accept with a recorded reason, or suppress with a rule that is reviewed. Keep suppressions in version control so they are visible in code review, and track how often each rule produces false positives so you can tune or disable noisy rules. A manual reviewer is useful here because they can confirm whether a flagged path is reachable and whether the input is actually controlled by an attacker. Ask any vendor how its tool records suppression decisions and whether those records can be exported for an audit.

Does manual code review replace penetration testing?

No. Manual code review and penetration testing answer different questions. OWASP WSTG notes that no single technique is enough and recommends a mix, with more weight on early development phases. Code review can reveal design and logic flaws that a black box tester may not see, while penetration testing exercises the deployed system, its configuration and its integrations. PCI SSC guidance also states that running an automated tool does not satisfy its penetration testing requirement. Confirm with your assessor or regulator which tests they require, and plan for both where the requirement calls for each.

Which code should get manual review first?

Start with code that enforces trust decisions: authentication, session handling, authorization checks, cryptographic code and any component that handles regulated data. NIST SA-11(4) guidance supports reserving manual review for critical software, and access control and cryptography are the areas where it names manual review as effective. Use SAST across the full codebase on every commit, then direct reviewer time to the highest-risk components. Document the selection criteria so an auditor can see why certain code was reviewed and other code was not.

How to combine SAST and manual review without duplicating work

Run SAST as the baseline on every commit and let manual review focus on what the tool cannot judge. The working split is simple: the scanner handles known flaw patterns across the whole codebase, and reviewers spend their hours on access control decisions, business logic and cryptographic choices in the components that matter most. NIST SSDF task PW.7.2 describes this pattern directly, with a static analysis tool and a human reviewing and remediating the reported issues. Confirm with your scanner vendor which rule sets, languages and frameworks it covers, because a clean scan only means the tool's rules found nothing, not that the code is sound.

Make the handoff explicit. Have the SAST pipeline tag each finding with its component and rule ID, then route only the findings in critical components to a reviewer, and close the rest through the normal developer triage queue. Reviewers should record which checks they ran against an access control matrix or a cryptographic implementation, so the same ground is not re-covered in the next release. When a reviewer finds the same mistake in more than one place, write it up as a candidate custom rule for the scanner, then check that the rule fires on the original defect and stays quiet on the fixed version. Treat this as a continuous tuning task owned by a named AppSec engineer, not a one-time setup.

Weight the mix toward the early phases, as the OWASP WSTG v4.2 recommends when it says no single technique is enough. For a new design, a threat model and an early manual review of authentication and authorization code will catch flaws that a scanner cannot see, and those findings are cheaper to fix before the code spreads. Later, as components stabilize, the balance can move toward automated scanning on every change with periodic manual review of high-risk paths. Ask any reviewer firm to show how it will reuse your SAST output and rule changes, so you pay for judgment on the code that needs it rather than for a second full scan.

How DeployOpen scopes and delivers code security testing

DeployOpen plans and runs code security work for teams that need both automated static analysis and expert review of the source, inside the client's own infrastructure. Each engagement starts from a written scope that states which code, which tools and which reviewers are involved.

How we scope

The written scope names the repositories, languages and components covered by static analysis and by manual review.
Critical modules such as access control, authentication, cryptography and payment logic are identified for expert reading.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

Static analysis rules are configured in your own pipeline, run on every commit, and tuned to reduce noise over time.
Expert reviewers read the flagged code and the unflagged design-critical paths, then document the findings they confirm.
Results are triaged with your developers so each confirmed issue has an owner, a severity and a clear fix path.

How we hand over

The handover includes the scan configuration, review notes, and a list of confirmed findings with reproduction steps.
Documentation records which code was analyzed automatically, which was read by people, and what remains uncovered.
Your team receives the evidence needed for assessors, such as SSDF practice mapping, without any audit claim from DeployOpen.

How we support

Ongoing support, rule upgrades and periodic re-review of changed critical code are available as a retainer.
Pipeline changes, new languages and tool upgrades can be scheduled under the same written agreement.
Confirm with DeployOpen which support terms, response windows and review cadence apply before signing.

SAST vs manual secure code review