What is code security review? A guide to secure code review in the AI era

Code security review is the examination of source code, and in practice each code change, to find security vulnerabilities before they reach production. Teams run it through manual review, automated analysis, or a mix of both. It can happen in the IDE as a developer writes code, at pre-commit, on every pull request, or during a periodic audit of an existing codebase.

A modern code security review covers more than the lines a developer typed. It includes the first-party code in the change and the open-source dependencies that change pulls in. It also includes any secrets the change introduces, plus configuration and infrastructure-as-code files that shape how the application runs.

The practice matters more now because AI coding assistants and agents open far more pull requests than human reviewers can read. Those changes also carry their own recurring security mistakes.

Code security review questions teams ask most:

• What code security review is, including where it happens and what it covers.
• How it differs from code review, SAST, SCA, and penetration testing, with a comparison table.
• What a secure code review should look for, ordered by impact, as the base for a checklist.
• How to perform a secure code review, as a repeatable workflow that splits work between program analysis, AI reasoning, and people.
• How AI coding assistants and agents change the job, including an AI-era risk taxonomy.
• How AI security review works, with a traced IDOR example.
• Where review fits in the agentic development lifecycle.
• How to measure whether review is working, with an outcome-based scorecard.

How is code security review different from code review, SAST, and penetration testing?

Secure code review is code review focused on exploitable risk, and teams can run it with humans, tools, AI agents, or a combination. A general code review asks whether the change is correct, readable, and maintainable. A secure code review asks whether an attacker could use the change to read data, take actions, or run code they shouldn't.

The terms below often get used interchangeably. They describe different activities with different blind spots.

Rule-based SAST tools match syntactic patterns. That makes them noisy, because many matches turn out to be safe in context. The same pattern approach is blind to logic flaws such as IDOR, authentication bypasses, and business logic errors, because those flaws have no fixed signature. Reviewers lose hours triaging false positives while real issues stay open.

That gap is what AI Security Review from Endor Labs targets: it reads the change and traces data flow instead of matching a pattern list.

What should a secure code review look for?

A secure code review should prioritize the highest-impact vulnerability classes: injection, broken access control and IDOR, authentication flaws, hardcoded secrets, unsafe deserialization, and insecure design. Weak cryptography, sensitive data in logs, misconfiguration, risky dependencies, and business logic flaws round out the list. The OWASP Top 10:2025 ranks broken access control as the top web application risk, and insecure design has its own category. Using OWASP's category names keeps findings consistent with the language your team already uses.

Injection across every data flow

Injection goes well beyond SQL. Check command injection, template injection, NoSQL injection, cross-site scripting, and log injection. The reliable way to find them is to trace untrusted input from its source (a request parameter, header, file, or message) to every sink where it's interpreted. A parameterized query in one file doesn't help if the same value reaches a shell call two files away.

Broken access control and IDOR

Role checks and object-level checks are different things. A role check confirms the user is allowed to call an endpoint. An object-level check confirms the user is allowed to touch this specific record. IDOR happens when code takes an ID from the request and fetches the record without checking ownership. Look for every place a user-controlled identifier reaches a data access call.

Authentication flaws

Review session handling, token validation, password reset flows, and any endpoint that skips authentication middleware. Watch for new routes registered outside the usual auth wrapper.

Secrets in code, history, and logs

A secret removed from the latest commit still lives in Git history. Review the diff for keys and tokens, scan history, and check that logs never print credentials, tokens, or personal data. Validating whether a found secret is live or revoked tells you how urgent the fix is. Endor Labs covers this as part of reviewing AI-generated code for secrets and vulnerabilities.

Unsafe deserialization and weak crypto

Flag deserialization of untrusted input with formats that can instantiate arbitrary types. Flag deprecated hash functions for passwords, hardcoded keys or IVs, and homegrown crypto.

Misconfiguration and infrastructure-as-code

Check for debug mode enabled in production config, permissive CORS settings, overly broad IAM policies, public storage buckets, and disabled TLS verification.

Dependencies, including transitive ones

A one-line change to a manifest can pull in dozens of transitive packages. Review what the change added, whether any of it has known vulnerabilities, and whether your code reaches the vulnerable functions.

Insecure design and business logic

These are flaws in what the code does, not how it's written. Examples include a checkout flow that trusts a client-supplied price, or a refund endpoint with no limit on repeat calls. They need someone, or something, that understands intent.

How do you perform a secure code review?

You perform a secure code review by understanding the change's context, letting automation handle deterministic checks, tracing untrusted data, and spending human attention on authorization and business logic. Then you deliver each finding with a fix and verify it. 

Here's the workflow step by step:

1. Understand context and trust boundaries. Read the PR description and linked ticket. Identify where untrusted input enters and which data stores or external services the change touches.
2. Let automation handle deterministic checks. Known vulnerable dependencies, secret detection, and common misconfigurations don't need a human's first look.
3. Trace untrusted data across functions. Follow each input from source to sink, across files and service boundaries.
4. Focus human attention on authorization and business logic. Ask whether every object access checks ownership and whether the flow can be abused.
5. Deliver findings with a fix. Describe the impact and include a suggested change that fits the codebase.
6. Verify. Confirm the fix closes the path and doesn't break behavior, ideally with a test.

Who should own which checks

Some teams may worry that AI review will either replace judgment or add one more noisy tool. A clear division of labor answers both concerns.

Deterministic program analysis gives repeatable answers. Run it twice on the same code and you get the same result. AI reasoning handles questions that rules can't express. Humans keep the decisions that depend on business context and risk appetite.

Use evidence to decide what's exercised

A finding is more useful when it comes with proof that the vulnerable path runs. Endor Labs builds a patented code context graph that models application behavior with line-level detail. Full-stack reachability uses that graph to show whether a vulnerable path in first-party code, an open-source dependency, or a container image is exercised. Each finding includes the data flow and call path as evidence, so a reviewer can check the reasoning instead of taking the tool's word for it.

Write findings developers can act on

Automate the obvious and review the subtle. When you do write a finding, lead with impact in one sentence, show the path, and suggest the fix. "User-supplied invoiceId reaches findById without an ownership check, so any logged-in user can read any invoice. Scope the query to the caller's organization." gets fixed. "Possible IDOR" gets argued about.

How do AI coding assistants and agents change secure code review?

AI coding assistants and agents multiply the number of pull requests and carry their own insecure patterns, so review has to scale and look for new failure modes. The volume shift is the first change. Endor Labs sees teams handling 1,000+ pull requests a day across hundreds of repositories. No security team can read that many diffs by hand.

The second change is the content of those diffs. Endor Labs' Agent Security League benchmark found that over 80% of AI-generated code it evaluated contained vulnerabilities.

An AI-era risk taxonomy for code review

Iterative degradation undercuts a common assumption that code generated securely stays secure. Endor Labs research shows that AI-generated code gets less secure with each iteration. One review at generation time can't cover what happens over the next five prompts.

Hallucinated packages connect code review to supply chain security. A USENIX Security 2025 study of 16 code-generating LLMs and 576,000 code samples found that hallucinated packages averaged at least 5.2% of suggestions for commercial models and 21.7% for open-source models. A reviewer who sees an unfamiliar import should confirm it resolves to a real, intended package before approving.

For the reviewer's side of the problem, including how to read a PR when no human wrote it, see our guide on how to review code an agent wrote. It covers how to spot the security, logic, and design risks that show up in AI-generated pull requests and what to check before they merge.

How does AI security review work?

AI security review uses specialized agents to detect, triage, and fix vulnerabilities on every pull request, combining deterministic program analysis with LLM reasoning. Endor Labs' AI Security Review runs the company's AI SAST engine on each PR. The engine combines rule-based pattern matching, dataflow tracing, and multi-pass LLM reasoning across several specialized agents.

Detection agents read a change the way a security engineer would. They trace how data moves across files and functions to catch flaws a pattern can't describe: broken access control, IDOR, injection, and insecure design.

A triage agent then classifies each finding as true positive, false positive, or unknown. It records its reasoning so your team can audit why it reached that verdict.

Remediation agents propose a fix matched to your codebase for every confirmed vulnerability.

A single PR scan covers the code, the dependencies the change modified (SCA), and any secrets it introduced. Results post as PR comments and connect to your CI/CD and policy engine. AI Security Review runs on GitHub, GitLab, and Bitbucket.

Worked example: an IDOR across three files

Here's an illustrative AI-generated pull request. An agent added an endpoint so users can download invoices. The code spans a route, a service, and a repository.

// routes/invoices.ts
router.get("/invoices/:invoiceId", requireAuth, async (req, res) => {
  const invoice = await invoiceService.getInvoice(req.params.invoiceId);
  res.json(invoice);
});

// services/invoiceService.ts
export async function getInvoice(invoiceId: string) {
  return invoiceRepo.findById(invoiceId);
}

// repositories/invoiceRepo.ts
export async function findById(id: string) {
  return db.invoice.findUnique({ where: { id } });
}

A rule-based scanner sees nothing to flag. The route uses authentication middleware. The query uses an ORM, so there's no string concatenation and no injection pattern. No rule describes "this lookup should have been scoped to the caller."

The detection agent traces req.params.invoiceId from the route handler, through getInvoice, into findById. It notes that the value is user-controlled and that the path reaches a data access call with no comparison against req.user. Authentication confirms who the caller is. Nothing confirms the caller owns the invoice.

The triage agent marks the finding a true positive. Its reasoning reads roughly like this: the identifier comes from the URL; any authenticated user can supply any value; the repository returns the record without an ownership filter; invoices contain billing data belonging to other customers. That reasoning sits in the PR comment where a reviewer can check each step against the code.

The remediation agent proposes an object-level authorization check that fits the existing structure:

// routes/invoices.ts
router.get("/invoices/:invoiceId", requireAuth, async (req, res) => {
  const invoice = await invoiceService.getInvoiceForOrg(
    req.params.invoiceId,
    req.user.orgId
  );
  if (!invoice) return res.status(404).end();
  res.json(invoice);
});

// repositories/invoiceRepo.ts
export async function findByIdForOrg(id: string, orgId: string) {
  return db.invoice.findFirst({ where: { id, orgId } });
}

Returning 404 instead of 403 avoids confirming that another organization's invoice exists. The developer reviews a working fix in the same PR instead of researching the data flow from scratch.

Why the design matters

Each part of the design addresses a specific trust problem with AI-generated findings. Auditable triage reasoning lets reviewers check a verdict instead of trusting a black box. Deterministic program analysis underneath the LLM reasoning keeps data flow and reachability results repeatable. Fixes ship alongside findings, which matters because researching a real vulnerability's data flow, impact, and safe remediation can take hours per finding.

Technical readers who want the full architecture can read the whitepaper on the multi-agent approach to detecting security design flaws.

Where does code security review fit in the agentic development lifecycle?

Code security review is the layer that checks every pull request, between preventing insecure code at generation and governing what coding agents do. It runs continuously inside the developer's existing workflow, rather than as a stage developers wait on.

Endor Labs approaches the AI-driven software lifecycle in layers:

• Prevention at generation. AURI by Endor Labs gives coding agents security context while they write, so common insecure patterns don't make it into the first draft.
• Review on every pull request. AI Security Review gives each change expert-depth analysis across code, dependencies, and secrets.
• Governance of agent actions. Coding Agent Governance secures what agents do, such as commands they run and tools they call, from a single control plane.
• Closing findings. Automatic triage and one-click fixes keep findings from piling up in a backlog.

These layers plug into tools developers already use, including Cursor, Claude Code, GitHub, and GitLab, without replacing existing systems. AURI connects to agents through Hooks, Skills, MCP, CLI, and API.

Prevention reduces how much review has to catch. Review catches what prevention missed, including degradation across iterations. Governance covers the actions that never show up in a diff. For the full model, read the secure agentic development lifecycle (ADLC) explained. The Endor Labs AI Code Security solution covers how the layers work together in production.

How do you measure whether code security review is working?

You measure whether code security review is working by the share of PRs that still need human security review, the false positive rate, the number of findings fixed before merge, and time to remediation. Counting findings filed tells you how busy your tools are. Counting findings closed tells you whether risk went down.

An outcome-based scorecard

Reference points from Endor Labs

Endor Labs reports that fewer than 10% of PRs need human security review after teams roll out AI Security Review.

Across its platform, Endor Labs reports these outcomes:

• 83% fewer blocked PRs
• 10x fewer security tickets
• 6x faster remediation
• Up to 95% false positive reduction for AI SAST

Use these as reference points, not targets. Your baseline depends on your languages, repository count, and current tooling.

A realistic rollout path

Start by running AI security review alongside your existing process without changing who approves PRs. For a few weeks, compare the triage agent's verdicts against your security engineers' judgment on the same findings. Track where they agree, where the agent marks findings unknown, and where humans overrule it. Once agreement is high on a set of repositories, let the tool handle routine PRs there and route only flagged or high-risk changes to people. Then expand coverage repository by repository.

Leaders building the budget case should pair this scorecard with Endor Labs' analysis of the total cost of securing AI coding assistants.

Frequently asked questions

Do teams still need manual secure code review if they use AI security review?

Yes, teams still need manual secure code review if they use AI security review for a smaller and more targeted set of changes. AI security review handles routine PRs and surfaces findings with reasoning. Humans keep threat modeling, architecture changes, new trust boundaries, and approval of high-risk exceptions. The goal is to spend expert time where judgment matters, instead of on every diff.

Can an AI coding assistant review its own code for security?

An assistant can catch some issues in its own output, but self-review shares the same blind spots that produced the code. Independent review with security-specific context, deterministic program analysis, and auditable reasoning gives a check that doesn't depend on the generating model. Prevention at generation, such as giving agents security context through AURI, and independent PR review work well together.

Who should perform a secure code review, developers or the security team?

Both, with different roles. Developers should own fixing findings in their PRs and can handle most routine review when tools give them clear impact and suggested fixes. The security team should set policy, tune what gets flagged, review high-risk changes, and own threat modeling. Automation connects the two by handling volume.

How often should secure code review happen?

On every change. AI-generated code can lose security controls across iterations, so a single review at generation or a quarterly audit leaves gaps. Run automated review on every pull request, add pre-commit secret detection, and reserve periodic manual audits and penetration tests for architecture-level and runtime concerns.