22 октября AWS вывела в общий доступ AWS Continuum for code vulnerabilities — сервис, который ищет и исправляет уязвимости в коде с учётом того, как этот код реально развёрнут.
Как работает
- Строит граф контекста из ваших репозиториев и AWS-окружения: какой сервис куда смотрит, какие роли и данные доступны.
- Воспроизводит эксплуатируемые находки в песочнице и прикладывает proof-of-concept — то есть отсеивает теоретические срабатывания.
- Ранжирует находки по влиянию на бизнес, а не только по CVSS.
- Открывает исправления как pull request в GitHub. Каждое исправление требует одобрения человека.
Доступность
- Источники кода: GitHub или S3. Поддержка GitLab в анонсе не упоминается.
- Регионы: us-east-1 и us-west-2.
- Цена в анонсе не приведена.
Почему это важно
Главная боль AppSec — не нехватка сканеров, а шум: сотни находок без понимания, какие из них реально опасны в вашем окружении. Подтверждение через PoC и привязка к инфраструктуре — попытка решить именно это. Перед внедрением стоит оценить, какие права на код и облако получает сервис, и прогнать его на одном репозитории, сравнив с текущим SAST.
On Oct 22 AWS made AWS Continuum for code vulnerabilities generally available — a service that finds and fixes code vulnerabilities in light of how that code is actually deployed.
How it works
- Builds a context graph from your repositories and AWS environment: which service talks to what, which roles and data are reachable.
- Reproduces exploitable findings in a sandbox and attaches a proof of concept — filtering out theoretical hits.
- Ranks findings by business impact, not just CVSS.
- Opens fixes as GitHub pull requests. Every fix needs human approval.
Availability
- Code sources: GitHub or S3. GitLab support is not mentioned.
- Regions: us-east-1 and us-west-2.
- Pricing is not given in the announcement.
Why it matters
AppSec’s main pain is not a lack of scanners but noise: hundreds of findings with no sense of which are actually dangerous in your environment. PoC confirmation and infrastructure context aim at exactly that. Before adopting it, assess what code and cloud permissions the service gets, and trial it on one repo against your current SAST.