Почему список алертов больше не решает проблему
Security backlog у зрелой команды редко ломается из-за того, что алертов слишком мало видно. Чаще наоборот: сигналов много, а инженерного времени на их разбор не хватает. Если все проблемы лежат в одной плоской очереди, команда неизбежно начинает выбирать по шумным признакам: критичность из advisory, популярность пакета, давность алерта, давление аудита. Но это не всегда отвечает на главный вопрос: что реально опасно для работающей системы прямо сейчас.
Анонс GitHub от 7 апреля про runtime context from Dynatrace важен именно поэтому. Он добавляет к security-alerts контекст развёрнутых артефактов и runtime-risk signals. Например, можно отфильтровать алерты до тех, которые затрагивают deployed artifacts и одновременно exposed to the internet. Это уже не просто сортировка по CVSS, а попытка привязать ремедиацию к реальной поверхности риска.
Где помогает агент, а где достаточно Dependabot
Dependabot давно хорошо закрывает простой класс задач: есть уязвимая зависимость, есть ближайшая исправленная версия, можно открыть pull request на обновление. Но GitHub прямо пишет, что часть dependency vulnerabilities требует больше, чем version bump. Major upgrade может сломать API, устаревшие вызовы, типы и тесты. В этот момент rule-based механизм заканчивает свою работу, а дальше нужен анализ кода.
Новый сценарий с assignable AI agents как раз находится на этом стыке. Из страницы Dependabot alert можно назначить alert агенту: Copilot, Claude или Codex. Агент анализирует advisory, смотрит использование зависимости в репозитории, открывает draft pull request и пытается разобраться с тестовыми падениями. Это не отменяет Dependabot. Это продолжает его работу там, где простое обновление превращается в кодовую миграцию.
Ссылки на источники
- GitHub описывает сценарий, где Dependabot alerts можно назначать AI coding agents, включая Copilot, Claude и Codex, для анализа уязвимости и draft pull request.
- GitHub отдельно поясняет, что Dependabot security updates покрывают простые обновления, а агенты нужны там, где major upgrade требует изменений в коде.
Почему несколько агентов на один alert — не странность
GitHub позволяет назначить несколько агентов на один Dependabot alert: каждый работает независимо и открывает свой draft pull request. На первый взгляд это звучит избыточно. Но для сложных dependency updates это может быть полезным способом сравнить подходы. Один агент может выбрать минимальный патч, другой — более широкий рефакторинг, третий — безопасный downgrade, если исправленной версии нет или пакет скомпрометирован.
Компромисс очевиден: несколько pull request дают больше вариантов, но увеличивают нагрузку на ревью. Поэтому такой режим имеет смысл не для каждого алерта. Он полезен там, где цена ошибки высока или обновление затрагивает большую часть проекта. Для рутинного patch upgrade это будет лишний шум. Сильная команда должна уметь отличать alert, который нужно просто обновить, от alert, где разумно попросить несколько агентных вариантов.
Что меняет batch-исправление code scanning
В тот же день GitHub добавил batch apply для suggestions по code scanning alerts в pull requests. Это менее громкий, но важный шаг. Когда у вас несколько однотипных замечаний в Files changed, каждое отдельное исправление может запускать отдельный цикл сканирования и ревью. Batch-подход собирает исправления в один коммит, снижая количество повторных проходов.
Этот сценарий показывает вторую сторону агентной ремедиации: не всё должно делать автономное существо. Иногда лучшая автоматизация — это более компактный интерфейс для серии точечных исправлений. Если задача локальная и паттерн понятен, batch-фикс лучше сложной агентной сессии. Если же исправление требует понять, как зависимость используется по всему проекту, тогда агентная работа становится оправданной.
Где риск особенно высок
Security-исправления опасны тем, что дают ложное чувство завершённости. Pull request есть, тесты прошли, alert закрыт — значит проблема решена. Но агент может выбрать патч, который закрывает симптом и ломает поведение на границах. Он может недооценить backward compatibility, не заметить runtime-конфигурацию или заменить вызов API на формально новый, но неэквивалентный в вашей доменной логике.
Именно поэтому GitHub отдельно подчёркивает: AI-generated fixes are not always correct, agent output нужно ревьюить, проверять тесты и подтверждать уместность исправления до merge. Это не формальная оговорка. Для security-ремедиации она центральная. Агент ускоряет путь от alert к draft PR, но ответственность за принятие изменения остаётся на команде.
Какой рабочий процесс выглядит зрелым
Зрелая схема начинается не с кнопки Assign to Agent, а с приоритизации. Сначала команда понимает, какие алерты затрагивают реально развёрнутые артефакты и имеют runtime-risk. Затем отделяет простые обновления, где хватает Dependabot security update, от сложных случаев, где нужен агентный draft PR. После этого pull request проходит обычный контур: тесты, ревью, проверка поведения и осознанное решение о merge.
Главный вывод простой: security-ремедиация становится агентной не потому, что теперь можно доверить безопасность модели. Она становится агентной потому, что путь от алерта к исправлению слишком часто включает анализ кода, миграцию, тесты и сравнение вариантов. Хороший агент сокращает этот путь. Плохой процесс превращает его в красивую кнопку, за которой никто не проверяет цену ошибки.
Ссылки на источники
- Runtime context from Dynatrace даёт фильтры вроде has:deployment и runtime-risk:internet-exposed, которые помогают отделять приоритетные алерты от фонового шума.
- Сценарий назначения Dependabot alerts агентам подтверждает, что агентная ремедиация должна оставаться частью обычного контура pull request, тестов и ревью.
Вывод
Исправление security-алертов становится агентным не потому, что безопасность теперь можно отдать модели, а потому что путь от алерта к исправлению всё чаще требует анализа кода, миграции зависимостей, тестов и сравнения вариантов. Агент ускоряет этот путь, но качество результата по-прежнему держится на приоритизации, ревью и ответственности команды.
