GitHub добавил в security overview метрики AI Scan для pull request

GitHub 13 октября 2026 года расширил security overview: администраторы организаций и enterprise-аккаунтов теперь могут отслеживать, как AI Scan работает в pull request. Панель показывает, сколько находок AI Scan сгенерировал и сколько из них разработчики закрыли. Анонс в GitHub Changelog занимает несколько строк, а перечень метрик в нём обрывается на полуслове. Поэтому ниже только то, что подтверждено, и честная оговорка о том, чего пока не видно.

Что именно появилось

AI Scan для pull request проверяет изменения в коде на уязвимости ещё до слияния. Это часть code scanning. Раньше админ мог включить функцию, но оценить её отдачу было трудно: находки смешивались с результатами других сканеров, а оценку приходилось строить по косвенным признакам.

Теперь у security overview есть отдельный срез по AI Scan. Из анонса известно следующее:

• метрики доступны администраторам организаций и enterprise-аккаунтов;
• они показывают, сколько находок сгенерировал AI Scan;
• они показывают, сколько находок было устранено;
• в тексте анонса перечислены и другие показатели, но сообщение обрезано, и полный набор из него восстановить нельзя.

Почему это важно для тех, кто платит за инструмент

AI-сканер, как и классический статический анализ, легко превращается в источник шума. Если он выдаёт много находок, а закрывается малая их часть, разработчики начинают пролистывать комментарии в pull request не читая. Пара показателей «сгенерировано» и «устранено» даёт первый грубый ответ на вопрос, приносит ли функция пользу. Высокая доля закрытых находок говорит, что сигналы попадают в цель. Низкая указывает на ложные срабатывания, плохо подобранный охват или команды, которые просто игнорируют проверку.

Есть и управленческая сторона. Безопасность обычно выбивает бюджет аргументами вроде «мы нашли и закрыли столько-то проблем до продакшена». Раньше такие цифры по AI-части приходилось собирать вручную, теперь они лежат в той же панели, где уже видны алерты по остальным сканерам. Для enterprise-клиентов с десятками и сотнями репозиториев это экономит время на отчётности.

Что с этим делать на практике

Данных в анонсе мало, поэтому разумно действовать по шагам:

1. Откройте security overview и найдите новый срез по AI Scan. Если его нет, проверьте права: функция адресована администраторам организаций и enterprise.
2. Зафиксируйте стартовые значения. Без базовой линии через месяц нечего будет сравнивать.
3. Сопоставьте число сгенерированных и закрытых находок. Если разрыв большой, выборочно разберите несколько десятков находок и выясните, чем они были: реальными дырами или шумом.
4. Сравнивайте репозитории между собой. Если в одном команда закрывает почти всё, а в другом почти ничего, дело скорее в процессе, чем в сканере.
5. Не делайте выводов о качестве самой модели только по этим метрикам. Закрытая находка не равна найденной уязвимости, а пропущенные проблемы в такую статистику не попадают.

По масштабу это небольшое обновление: новая вкладка с метриками, а не новая модель или агент. Но именно такие вещи показывают, что AI-проверки в GitHub переходят из режима «включили и надеемся» в режим, где их эффективность можно измерить. Когда GitHub раскроет полный список показателей, станет понятно, насколько глубоко эта аналитика позволит копать.