AWS has put a new full-repository code scanning capability for AWS Security Agent into preview. The promise is simple and large: scan the whole codebase, reason across files and flows, and produce security findings that look less like raw SAST alerts and more like a human review note.
That is the useful part to watch. Not because static analysis is dead. It is not. But because many serious application bugs do not live in one obvious line. They sit in the gap between endpoints, validators, authorization checks, encoding contexts, and deployment assumptions.
AWS says the feature is designed to read an entire repository, build a security model of the application, search high-risk areas, triage candidate issues, and then validate findings before presenting them to developers. It is available in preview, with AWS prioritizing free early access for customers.
What AWS is announcing#
The new capability is called full repository code review for AWS Security Agent. AWS describes it as an AI-driven security analysis feature that performs deep, context-aware review of a whole codebase.
The distinction AWS draws is against traditional static application security testing, or SAST. Classic SAST tools are good at known patterns: SQL injection sinks, hard-coded credentials, missing escaping, unsafe calls. They are fast and useful, but they often struggle when the weakness is systemic rather than local.
AWS gives examples of that class of problem: a validation function that covers most cases but misses one important input, an endpoint that lacks an authorization annotation used by nearby endpoints, or encoding applied correctly in one context and incorrectly in another.
Those examples matter because they are common. Modern applications are not just files. They are routes, service boundaries, identity assumptions, data flows, background jobs, configuration, and framework behavior. A tool that only matches a line against a rule can miss the shape of the bug.
AWS says full repository code review is meant to close that gap by acting more like an automated security researcher. That is vendor language, but the underlying technical direction is clear: broader context first, finding second.
How the scanning flow works#
AWS describes the process in four broad stages: profile, search, triage, and validate.
First, the scanner reads the repository and builds a security model. That model includes entry points, trust boundaries, data flows, authorization invariants, and existing defenses. AWS says the profiling step accounts for source files, making coverage decisions explicit rather than hidden.
Second, an orchestrator uses that profile to reason about the attack surface and dispatch specialized agents to higher-risk components. Each agent gets scoped work: modules, threat context, and adversarial questions. AWS says agents can follow imports and callers beyond their starting scope if the code path demands it.
Third, candidate findings are triaged. Duplicate findings are grouped when they share the same sink or root cause. Low-confidence noise is filtered before validation.
Fourth, an independent validator re-reads the source and traces the attack chain. AWS says the validator argues both sides: looking for evidence that the issue is real and evidence that it is not, such as compensating controls or intentional design. The finding is rejected only when the evidence against it is as strong as the evidence that promoted it.
This is the most important claim in the announcement. Security teams do not only need more alerts. They need alerts with evidence, scope, uncertainty, and a clear path to reproduce or dismiss.
Why this differs from normal SAST#
The practical difference is not that old tools use rules and new tools use AI. That framing is too shallow.
The real difference is whether the tool understands enough application context to make a claim about behavior. A rule can say a dangerous function is present. A repository-level review can try to answer a harder question: can attacker-controlled data reach this code path under the application’s actual trust and validation model?
AWS gives a SQL injection example. A traditional SAST tool might flag one specific call. The full-repository scanner, according to AWS, identified that a central validation function failed to block single quotes across five regex profiles. It listed the profiles, explained why that mattered for the database engine, and noted that another stored procedure skipped the validation function entirely.
That kind of result changes remediation. Instead of patching one call site, the team can address a shared validation weakness and the code paths that bypass it.
AWS also gives an XSS example where the same value was used in different contexts in the same file, with encoding applied in one place but not another. A pattern-based tool may see the encoding function and treat the area as handled. A context-aware scanner should notice that the protection does not cover every output context.
These examples are still AWS-provided. They should be treated as claims from the vendor, not independent benchmark results. But they describe the right problem class.
What developers should expect from findings#
AWS says findings are structured for developer triage. The announcement describes several expected parts: what the code does wrong, what the attacker gains, what was verified in code, what could not be verified, and concrete remediation suggestions.
The “verified and could not verify” split is especially useful. Application security findings often depend on runtime facts the scanner may not know: network segmentation, deployment topology, feature flags, identity provider behavior, production configuration, or compensating controls outside the repository.
A good finding should not pretend those facts are known. It should say what the code proves and what the operator must confirm.
This also helps avoid the two usual failure modes of automated security review. One failure mode is false precision: the tool states a vulnerability as fact when it only has a partial path. The other is useless caution: the tool emits vague risk language that no engineer can act on.
If AWS can consistently produce findings with code evidence, attack chain, uncertainty, and specific fixes, that would be materially better than another noisy alert stream.
What not to overclaim#
This is a preview feature. That matters.
Preview means teams should expect rough edges, changing behavior, and possible limits in coverage or integration. AWS is not presenting this as a final replacement for existing application security programs. The announcement positions it as a new capability for customers to try and provide feedback on.
It also does not make human review obsolete. The strongest use case is likely first-pass deep review, backlog discovery, pre-release checks, and help with large repositories where manual coverage is uneven. Human security engineers still need to judge business logic, threat model assumptions, exploitability in the deployed environment, and the right remediation tradeoff.
It is also not clear from the source material how the feature performs across languages, frameworks, repository sizes, monorepos, generated code, private dependencies, or unusual build systems. Those are the questions teams should test before trusting it in production workflows.
Practical takeaways#
For defenders, the preview is worth watching because it targets a real weakness in current code scanning: bugs that emerge from system behavior, not isolated syntax.
Teams evaluating it should look beyond the number of findings. Better questions are:
- Does it explain the source-to-sink path clearly?
- Does it identify trust boundaries and authorization assumptions correctly?
- Does it separate code-confirmed facts from environment-dependent claims?
- Does it find systemic root causes, or only local symptoms?
- Are remediation suggestions specific enough for a developer to use?
- Does it reduce triage time, or just move noise into a new format?
The direction is obvious. Code security tools are moving from pattern matching toward agentic review over whole repositories. The value will depend less on the AI label and more on evidence quality, uncertainty handling, and whether the tool can survive contact with real production code.