Когда ИИ показывает накопленный долг в коде
Первые цифры по проекту Glasswing - не история про умную модель. Это история про то, сколько старых уязвимостей лежит в коде, который мы используем каждый день.
Anthropic опубликовали первые результаты по проекту Glasswing - программе, в которой их модель Claude Mythos ищет уязвимости в коде партнёров. За полтора месяца работы с пятьюдесятью компаниями модель нашла больше десяти тысяч критических багов. Cloudflare получил две тысячи находок, из них четыреста класса high и critical. Mozilla исправила двести семьдесят одну уязвимость в Firefox 150. Сами Anthropic просканировали более тысячи опенсорсных проектов и получили двадцать три тысячи потенциальных уязвимостей, из которых после ручной проверки реальными оказались около девяноста процентов.
Заголовки в духе «ИИ обнаружил столько-то багов» правильны технически, но они скрывают то, что мне кажется главным наблюдением.
Эти баги были там и раньше
Модель не создала эти уязвимости. Она их увидела. Код wolfSSL, в котором Mythos нашёл критическую дыру с подделкой сертификатов, существует много лет. Через него проходит трафик банков, IoT-устройств, корпоративных VPN. Уязвимость спокойно жила в продакшене всё это время, пока никто не догадался посмотреть с правильного угла.
Похожую логику мы уже видели в истории с Heartbleed: уязвимость в OpenSSL существовала годами, но обнаружить её удалось только когда исследователи целенаправленно проверили библиотеку. Glasswing показывает, что таких «спящих» проблем в индустрии не десятки и не сотни, а тысячи в каждом крупном проекте.
Это и есть основная новость. Не «ИИ стал лучше искать баги», а «весь стек, на котором мы работаем, содержит большой запас непрочитанного технического долга». И этот долг теперь становится видимым.
Узкое место сместилось
Anthropic пишут, что скорость обнаружения выросла примерно в десять раз. Но мейнтейнеры опенсорсных проектов уже просят отложить раскрытие, потому что не успевают писать патчи. Это интересный момент: раньше узким местом был поиск проблем, теперь - их закрытие.
Для руководителя это значит простую вещь. Когда такие инструменты станут массово доступны (а Anthropic пишут, что работают над этим), вы получите не «инструмент, который найдёт все ваши баги», а длинный отчёт, который кто-то должен прочитать, расставить приоритеты и закрыть. Команда, у которой нет процесса работы с уязвимостями, получит очередь, с которой не справится.
Что это означает для бизнеса
Накопленный долг в коде - не абстракция. Это реальные деньги и реальный риск, и мы уже писали о том, как переводить это на язык бизнес-решений. Просто раньше большая часть этого долга была невидимой и поэтому отсутствовала в управленческих разговорах. Теперь её становится видно.
Для собственников и руководителей это означает три вещи.
Первое - готовиться к волне. Если ваш бизнес зависит от опенсорсных компонентов, в ближайший год вы получите поток новых CVE по библиотекам, которые годами работали без замечаний. Это не значит, что они стали хуже. Это значит, что их наконец посмотрели внимательно. Вопрос «знаем ли мы, какие из этих компонентов у нас в продакшене» становится практическим.
Второе - честный взгляд на свой код. Если внешние библиотеки годами накапливали долг, ваш собственный код, скорее всего, тоже. Доступ к таким инструментам внутри компании покажет картину, которую мало кто хочет видеть. Лучше увидеть её до того, как кто-то другой увидит её снаружи.
Третье - перестроить процесс реагирования. Десятикратный рост скорости обнаружения требует десятикратной готовности к патчингу. Это не только разработчики. Это процесс приоритизации, регрессионное тестирование, релиз-цикл, коммуникация с клиентами при простое. Список вопросов, которые имеет смысл задать после любого крупного раскрытия уязвимости, теперь становится регулярной операцией, а не реакцией на отдельный инцидент.
Вопросы для разговора с командой
Несколько вопросов, которые имеет смысл задать ИТ- и ИБ-команде до того, как очередная такая новость придёт в виде CVE:
- Какой список сторонних компонентов и библиотек у нас сейчас в продакшене и кто его поддерживает?
- Сколько времени проходит между публикацией патча в апстриме и установкой у нас?
- Если завтра придёт отчёт на сто уязвимостей одновременно, кто и по каким критериям расставит приоритеты?
- Какие наши собственные модули не пересматривались дольше всего - и какие из них работают с чувствительными данными?
- Что в нашем релиз-процессе ограничивает скорость выпуска security-патчей сильнее всего?
Раньше можно было сказать: «у нас нет известных проблем». Скоро это перестанет быть аргументом. Известных проблем станет много у всех, и разница между компаниями будет в том, кто умеет с ними работать.