Today, we’re excited to announce the preview release of full repository code review, a new capability in AWS Security Agent that performs deep, context-aware security analysis of your entire code base. AI-driven cybersecurity capabilities are advancing rapidly. AWS Security Agent can now find vulnerabilities and build working exploits across your entire code base at a scale and speed we haven’t seen before, reasoning like a human security researcher, but operating at machine velocity. Unlike traditional static analysis tools that match code against known vulnerability patterns, full repository code review reasons about your application’s architecture, trust boundaries, and data flows the way a human security researcher would and then produces developer-ready findings with transparent evidence and concrete remediation.
AWS is prioritizing free early access for customers, giving defenders the opportunity to strengthen their code bases and share what they learn so the whole industry can benefit.
The challenge: Security analysis that scales with your code
Development teams today face persistent tension. Traditional static application security testing (SAST) tools are fast and reliable at catching known patterns such as a SQL injection sink, an unescaped output, or a hard-coded credential. But modern applications are complex systems of services, APIs, trust boundaries, and authorization logic. The most dangerous vulnerabilities often aren’t single-line pattern violations, rather they’re systemic gaps where a validation function covers four of five cases, one endpoint is missing the authorization annotation its neighbors have, or encoding is applied in one context but not another.
Manual security reviews catch these issues, but they’re expensive, slow, and don’t scale to the pace of modern development. As code bases grow, teams are forced to choose between breadth and depth.
Full repository code review is built to close this gap. It gives your team an automated security researcher that reads and reasons about your entire repository, not just individual lines or file, and surfaces findings that pattern-matching tools miss.
How it works: Profile, search, triage, validate
Full repository code review operates in four stages that mirror how an experienced security engineer conducts an engagement.
- Profile the application: The scanner begins by reading the entire repository and building a security model of the application including entry points, trust boundaries, data flows, authorization invariants, and the defenses already in place. This profiling step accounts for every source file, so coverage decisions are explicit rather than implicit. The result is a structured understanding of what the application does and where its attack surface lies.
- Search for vulnerabilities: An orchestrator reads the security profile, reasons about the attack surface, and dispatches specialized agents to the highest-risk components. Each agent receives a scoped assignment with specific modules, threat context, and adversarial questions. Agents are free to follow imports and callers beyond their starting scope when a lead takes them there.
- Triage and deduplicate: Candidate findings are deduplicated (same sink, same root cause) and low-confidence noise is filtered out before the validation phase.
- Validate independently: For every candidate, an independent validator re-reads the source code and traces the full attack chain. The validator argues both sides: it looks for reasons the finding might not be a vulnerability (compensating controls, intentional design), and it looks for reasons it is one (alternative attack paths, edge cases). A finding is only rejected when the evidence against it is as strong as the evidence that promoted it. This process produces findings with structured Verified and Could not verify sections, so your team knows exactly what the scanner confirmed in the code and what depends on your deployment environment.
What makes this different
Full repository code review differs from traditional static analysis in two fundamental ways. It reasons about your application’s actual behavior rather than matching against known vulnerability patterns, and it presents findings with structured evidence that makes uncertainty explicit rather than hidden.
Context-aware reasoning, not pattern matching
Because the scanner builds a security model before searching for vulnerabilities, it reasons about the application’s actual behavior, not only surface-level code patterns.
Consider a real example: A stored procedure had a SQL injection vulnerability. A traditional SAST tool would flag the specific EXECUTE IMMEDIATE call. The scanner went deeper and it identified that the central validation function doesn’t block single quotes in any of its five regex profiles, listed all five profiles by name, explained why single quotes matter for the specific database engine, and noted that another stored procedure skips the validation function entirely. Instead of a point fix on one call site, the finding led to a comprehensive remediation of the systemic gap.
In another case, the scanner found an XSS vulnerability where a value was added to a field without HTML encoding. The same value was properly encoded with Encode.forHtml() in a different context within the same file. Pattern-matching tools miss this because the encoding function is present, but the vulnerability is the inconsistency, which requires understanding the application’s behavior across code paths.
Validated findings with transparent uncertainty
Every finding is structured for efficient developer triage:
- Problem: What the code does wrong, with specific file and line references.
- Impact: What an attacker gains, with details about deployment context.
- Verified and could not verify: What the scanner confirmed directly in code versus what depends on your environment (network segmentation, runtime behavior).
- Remediation: Concrete fix suggestions with specific code changes, not generic guidance.
- Severity and confidence: Calibrated independently. Severity reflects the impact if the vulnerability is exploitable; confidence reflects how much of the attack chain was verified in code.
How full repository code review fits into your workflow
Full repository code review is designed to complement, not replace, your existing security tooling. Here’s how it fits into a modern development workflow:
- Before security reviews: Run a full repository code review before scheduling a penetration test or security review. The review surfaces the obvious and semi-obvious issues so your security team can focus their limited time on the subtle, design-level questions that require human judgment.
- When onboarding acquired or open source code: Full repository code review is especially valuable when your team inherits code through acquisitions or vendor dependencies, or from open source components you’re integrating. The scanner builds a security model from scratch, so it doesn’t need institutional knowledge of the codebase.
- During architecture reviews: Because the scanner reasons about trust boundaries, data flows, and authorization invariants, its findings often surface architectural issues, not only implementation bugs. Review the scan results alongside your threat models to validate assumptions about how components interact.
Follow our Quickstart guide to set up and execute a full repo code review with AWS Security Agent.
Preview availability and pricing
Full repository code review is available today in preview at no additional charge for AWS Security Agent customers. During the preview, we welcome your feedback as we refine the experience. Use the built-in feedback mechanism in the Security Agent web application or reach out to your AWS account team.
Visit the AWS Security Agent console to enable full repository code review and run your first scan. For more information, see the AWS Security Agent documentation.
Login
