AWS выпустила в preview новую возможность full-repository code scanning для AWS Security Agent. Обещание простое и масштабное: сканировать всю codebase, рассуждать о связях между файлами и потоками данных и выдавать security findings, которые меньше похожи на сырые SAST-alerts и больше — на заметки после human review.
Именно за этим стоит следить. Не потому, что static analysis умер. Нет, не умер. А потому, что многие серьезные application bugs не живут в одной очевидной строке. Они находятся в промежутке между endpoints, validators, authorization checks, encoding contexts и deployment assumptions.
AWS говорит, что feature спроектирована так, чтобы читать весь repository, строить security model приложения, искать high-risk areas, triage candidate issues, а затем validate findings перед тем, как показать их developers. Возможность доступна в preview, при этом AWS приоритизирует бесплатный early access для customers.
Что анонсирует AWS#
Новая возможность называется full repository code review for AWS Security Agent. AWS описывает ее как AI-driven security analysis feature, которая выполняет глубокий context-aware review всей codebase.
AWS противопоставляет ее традиционному static application security testing, или SAST. Классические SAST tools хорошо работают с известными patterns: SQL injection sinks, hard-coded credentials, missing escaping, unsafe calls. Они быстрые и полезные, но часто испытывают трудности, когда weakness носит системный, а не локальный характер.
AWS приводит примеры такого класса проблем: validation function, которая покрывает большинство случаев, но пропускает один важный input; endpoint, у которого отсутствует authorization annotation, используемая соседними endpoints; или encoding, примененный корректно в одном context и некорректно в другом.
Эти примеры важны, потому что они распространены. Современные приложения — это не просто файлы. Это routes, service boundaries, identity assumptions, data flows, background jobs, configuration и framework behavior. Tool, который только сопоставляет строку с rule, может не увидеть форму bug.
AWS говорит, что full repository code review должен закрыть этот пробел, действуя скорее как automated security researcher. Это vendor language, но базовое техническое направление понятно: сначала более широкий context, потом finding.
Как работает scanning flow#
AWS описывает процесс в четыре крупных этапа: profile, search, triage и validate.
Сначала scanner читает repository и строит security model. Эта model включает entry points, trust boundaries, data flows, authorization invariants и existing defenses. AWS говорит, что profiling step учитывает source files, делая решения о coverage явными, а не скрытыми.
Затем orchestrator использует этот profile, чтобы рассуждать об attack surface и направлять specialized agents в компоненты с более высоким risk. Каждый agent получает scoped work: modules, threat context и adversarial questions. По словам AWS, agents могут следовать по imports и callers за пределы стартового scope, если этого требует code path.
На третьем этапе candidate findings проходят triage. Duplicate findings группируются, если у них один и тот же sink или root cause. Low-confidence noise фильтруется до validation.
На четвертом этапе independent validator заново читает source и трассирует attack chain. AWS говорит, что validator рассматривает обе стороны: ищет evidence, что issue реальна, и evidence, что это не так, например compensating controls или intentional design. Finding отклоняется только тогда, когда evidence против него столь же сильные, как evidence, из-за которых он был продвинут дальше.
Это самое важное утверждение в анонсе. Security teams нужны не просто дополнительные alerts. Им нужны alerts с evidence, scope, uncertainty и понятным путем к reproduce или dismiss.
Чем это отличается от обычного SAST#
Практическая разница не в том, что старые tools используют rules, а новые tools используют AI. Такая рамка слишком поверхностна.
Настоящая разница в том, понимает ли tool достаточно application context, чтобы сделать утверждение о behavior. Rule может сказать, что присутствует dangerous function. Repository-level review может попытаться ответить на более сложный вопрос: могут ли attacker-controlled data попасть в этот code path с учетом реальной trust и validation model приложения?
AWS приводит пример с SQL injection. Традиционный SAST tool мог бы отметить один конкретный call. Full-repository scanner, по словам AWS, обнаружил, что central validation function не блокировала single quotes в пяти regex profiles. Он перечислил profiles, объяснил, почему это важно для database engine, и отметил, что другая stored procedure полностью обходила validation function.
Такой результат меняет remediation. Вместо patch одного call site команда может устранить общую validation weakness и code paths, которые ее обходят.
AWS также приводит пример XSS, где одно и то же value использовалось в разных contexts в одном файле: в одном месте encoding применялся, а в другом — нет. Pattern-based tool мог бы зацепиться за отдельный фрагмент, но repository-level analysis пытается объяснить, где именно context меняется и почему защита перестает работать.