КИБЕРБЕЗОПАСНОСТЬ

Snyk выходит в AI-пентестинг: код уже быстрее AppSec

Snyk 27 мая представила Evo Continuous Offensive Security: сервис для непрерывного AI-пентестинга там, где годовой аудит уже не успевает за релизами.

✍️ Редакция iTech News | 30.05.2026 | ⏱ 5 мин | Источник: The New Stack
🛡

Snyk 27 мая представила Evo Continuous Offensive Security — новый сервис для непрерывного AI-пентестинга, который должен закрыть дыру между скоростью генерации кода и возможностями классического AppSec. Для команд, где релизы уже давно идут не по кварталам, а почти по расписанию CI/CD, новость простая: ежегодный или даже ежеквартальный пентест начинает выглядеть как музейный экспонат, а не как рабочий инструмент защиты.

О запуске сообщает The New Stack. По данным издания, Snyk заходит в сегмент AI-пентестинга с продуктом внутри платформы Evo by Snyk и делает ставку не на очередной одиночный LLM-сканер, а на более тяжелую конструкцию: многомодельный offensive-security harness, который использует контекст из уже существующих проверок SAST, SCA, прошлых DAST-сканов и инвентаризации активов. Идея в том, чтобы искать не просто потенциальную уязвимость по сигнатуре, а реально эксплуатируемый сценарий в конкретном приложении.

Главный тезис Snyk звучит без особой дипломатии: код теперь выходит быстрее, чем безопасность успевает его осмыслить. В пресс-релизе компания приводит показательный разрыв: средний пентест длится 15 дней, а остальное время — около 350 дней в году — система живет без сопоставимого по глубине offensive-покрытия. Для эпохи, когда AI-агенты пишут, правят и доставляют код почти конвейерно, это уже не техническая мелочь, а структурная проблема. Чем короче цикл разработки, тем хуже работает модель, в которой безопасность приходит в конце с папкой замечаний и мрачным лицом.

Отсюда и архитектура продукта. Evo Continuous Offensive Security, по версии Snyk, строится на четырех опорах. Первая — платформенный контекст: сервис подхватывает данные из других слоев платформы и направляет атаку туда, где риск действительно может сложиться в инцидент. Вторая — разделение труда между детерминированными проверками и модельным рассуждением: классические баги вроде XSS и SQL-инъекций машина ищет по привычным правилам, а бизнес-логические ошибки, проблемы авторизации и странное поведение AI-функций отдает на разбор моделям. Третья — управляемая среда исполнения с памятью, планированием многошаговых атак и аудитом. Четвертая — не список алертов, а связный сценарий эксплуатации, где видно, как несколько слабостей складываются в один рабочий путь атаки.

Это важный сдвиг в формулировке самой задачи. Рынок безопасности много лет продавал разработчикам длинные таблицы находок, которые потом неделями сортировались по severity, ownership и настроению тимлида. Snyk пытается продавать не список, а доказательство эксплуатируемости. Для AppSec-команд это куда более прагматичный формат: не 400 строк с одинаково тревожными названиями, а конкретный нарратив атаки, который можно положить в backlog или сразу отправить в remediation. С практической точки зрения это означает смену единицы измерения: вместо «сколько нашли» все чаще будет важно «что реально ломается».

Контекст для такого запуска более чем подходящий. The New Stack цитирует аналитика Forrester Джанет Уортингтон: предприятия уже сжимают циклы разработки с недель до часов благодаря AI-кодинговым агентам. Проблема в том, что приложения, которые эти агенты выпускают, несут не только старые добрые уязвимости вроде SQL-инъекций, XSS и утечек секретов, но и новый набор рисков — prompt injection, data leakage, privilege escalation и прочие радости AI-native-разработки. То есть темп изменился, а поверхность атаки не сократилась. Скорее наоборот: она стала шире, быстрее и местами менее понятной даже тем, кто эту систему строил.

На этом фоне Snyk явно пытается застолбить позицию не просто в AppSec, а именно в AI-пентестинге как отдельной дисциплине. Компания подчеркивает, что point solutions без контекста часто тестируют приложение «в вакууме» и потому дают шум вместо приоритизации. Логика понятна: если вендор уже знает ваш код, зависимости, активы и результаты прошлых проверок, ему проще довести offensive-тестирование до чего-то похожего на инженерный инструмент, а не на шоу с красивым демо. В раннем доступе продукт уже используют дизайн-партнеры, а общую доступность Snyk ожидает к Black Hat USA в августе 2026 года.

При этом Snyk приходит не на пустое место. The New Stack называет среди конкурентов Aikido и Beagle Security, которые тоже предлагают continuous AI-powered pentesting. И это, возможно, самая интересная часть истории. Появляется новый рынок, где спор пойдет не о том, нужен ли вообще AI-пентестинг, а о том, чей AI-пентестинг лучше работает в проде: у кого меньше шума, лучше доказательная база, понятнее интеграция в DevSecOps и меньше риск, что «умный» сканер просто начнет генерировать еще одну очередь тикетов, которые никто не успеет разобрать.

Для русскоязычной IT-аудитории здесь есть вполне прикладной вывод. Если в компании уже используют GitHub Copilot, Cursor, Claude Code, внутренние кодогенераторы или агентные пайплайны, то старый спор «ускорять разработку или не ускорять» уже закончился. Вопрос теперь другой: успевает ли контур безопасности за этой скоростью и умеет ли он проверять не только код, но и поведение системы. Там, где релизный цикл ужался до часов, безопасность по календарю начинает проигрывать безопасности по сигналам, контексту и непрерывной атакующей проверке. Похоже, в ближайшие месяцы именно это и станет новой нормой для зрелого AppSec: меньше формального сканирования, больше проверки того, что действительно можно сломать.

Если этот подход приживется, рынок безопасности придется пересобрать не вокруг количества найденных проблем, а вокруг качества доказанного риска. И тогда неудобный вопрос будет уже не к AI-агентам, которые штампуют код, а к самим компаниям: готовы ли они перестроить AppSec под машинную скорость разработки, или будут еще пару лет делать вид, что годовой пентест в июле закрывает все, что AI успел выкатить к октябрю.

Поделиться: Telegram X LinkedIn