IBM планирует встроить Claude Mythos в поиск уязвимостей в начале 2027 года

Сканер безопасности прислал очередную пачку предупреждений. Разработчику нужно понять, какая ошибка действительно открывает путь к данным клиентов, а какая может подождать. Без этого новый инструмент поиска только увеличивает очередь работы. Именно эту проблему IBM собирается решать с помощью Claude Mythos: связать обнаружение ошибки, проверку возможности атаки и подготовку исправления в одном процессе.

Для разработчика ценность такого подхода понятна: получить достаточно доказательств, чтобы принять решение и проверить предложенный патч. Для продакта — увидеть, какие работы действительно снижают риск для сервиса. Но пока это анонс: оценивать результат придётся после появления продукта и испытаний на собственном коде.

Что IBM собирается связать

В анонсе IBM описаны три этапа. Mythos будет анализировать выбранные заказчиком репозитории и искать ранее неизвестные уязвимости. Concert Protect должен оценивать возможность эксплуатации с учётом кода, настроек и инфраструктуры. Затем инструменты IBM и Red Hat помогут подготовить изменения, которые разработчики проверят и одобрят. Общую доступность компания планирует на начало 2027 года и предупреждает, что планы могут измениться.

Практический смысл здесь — в передаче контекста между этапами. Сама по себе находка ещё не отвечает на вопрос, насколько срочно нужно отвлекать команду от релиза. Для решения нужны условия, при которых ошибка становится опасной, и понятное объяснение последствий. Именно качество этой связки стоит проверять на пилоте: помогает ли система быстрее принять обоснованное решение по конкретной находке.

Как это выглядит на обычном сервисе

Представим сервис для работы с документами. Пользователь открывает свой файл по ссылке, а сервер проверяет авторизацию. Однако в одном обработчике разработчик забыл проверить, принадлежит ли документ именно этому пользователю. Подмена идентификатора потенциально позволяет прочитать чужой файл. Это условный пример логической ошибки, а не опубликованный результат тестирования Mythos.

Для такой находки важно выяснить несколько вещей. Доступен ли обработчик извне? Можно ли подобрать идентификатор? Есть ли дополнительная проверка прав в другом слое приложения? Если инструмент покажет только подозрительную строку, расследование останется на разработчике. Если объяснит доступный путь атаки и условия его работы, команда получит основание для приоритета.

Дальше нужен патч. Допустим, система предложила добавить проверку владельца документа. Разработчик должен убедиться, что изменение действительно закрывает доступ к чужим файлам и сохраняет легальные сценарии: например, совместную работу или доступ администратора. Полезный результат здесь измеряется временем до проверенного исправления и объёмом ручной работы, который потребовался команде.

Что проверить перед внедрением

В доступных материалах нет чисел, по которым можно оценить точность будущей интеграции, долю ложных тревог или экономию времени разработчиков. Поэтому обещание находить неизвестные ошибки пока стоит воспринимать как заявленную возможность. На собственном проекте результат может зависеть от языка, архитектуры и того, насколько полно инструмент видит окружение приложения.

Отдельный вопрос — доступ к исходникам. До пилота команде стоит выяснить, где обрабатывается код, какие данные передаются поставщикам и кто может просматривать результаты анализа. Ещё один критерий — воспроизводимость: сможет ли инженер самостоятельно проверить доказательство уязвимости и убедиться, что патч устраняет причину ошибки.

Разработчику уже сейчас полезно подготовить небольшой набор известных проблем и безопасных похожих случаев для будущей проверки. Продакту или основателю — заранее определить критерий успеха пилота: например, сколько подтверждённых опасных ошибок команда закрывает за неделю и сколько времени тратит на разбор ложных тревог. Тогда появление ещё одного ИИ-инструмента можно будет оценить по изменению рабочего процесса, а решение о покупке — принять на данных своей команды.