AI‑модель Claude Opus 4.6 нашла более 500 новых 0‑day уязвимостей в открытом ПО
Компания Anthropic сообщила о масштабном эксперименте с использованием своей ИИ‑модели Claude Opus 4.6 для автоматического поиска уязвимостей в программном коде. В результате анализа актуальных версий ряда популярных open source‑проектов было обнаружено свыше 500 ранее неизвестных ошибок безопасности уровня 0‑day. Для каждой из них был зафиксирован высокий уровень критичности.
Исследование сосредоточили на уязвимостях, связанных с ошибками работы с памятью: переполнением буфера, выходом за пределы массива, некорректной обработкой указателей и т.п. Такой тип дефектов удобен для верификации — можно сравнительно быстро проверить, приводит ли найденный сценарий к крашу, повреждению памяти или выполнению произвольного кода.
Каждая потенциальная уязвимость не ограничилась автоматическим выводом модели: все находки прошли ручную проверку и подтверждение либо сотрудниками Anthropic, либо привлечёнными независимыми специалистами по безопасности. Более того, для значительной части проблем были подготовлены исправления (патчи), которые затем направили сопровождающим соответствующих проектов.
Базой для эксперимента стали крупные и широко используемые открытые проекты, которые и так уже много лет подвергаются непрерывному fuzzing‑тестированию с помощью инфраструктуры наподобие OSS‑Fuzz. Это делает результат особенно показательным: ИИ сумел обнаружить серьёзные баги там, где уже долго работали автоматические генераторы случайных входных данных и опытные тестировщики.
Ключевое отличие подхода Claude Opus 4.6 от классического fuzzing‑тестирования в том, что модель не просто «заливает» программу случайным потоком входных данных. Вместо этого она анализирует исходный код, изучает историю изменений, сверяется с патчами, применёнными ранее, и логически выводит, какие ещё похожие ошибки могли остаться не исправлены. ИИ выстраивает логические цепочки: где патч закрывает одну дыру — там же нередко можно найти аналогичные опасные паттерны использования памяти.
Информация о выявленных уязвимостях уже передаётся сопровождающим проектов, с которыми идёт совместная работа по внедрению исправлений. Чтобы упростить этот процесс, эксперты Anthropic в ходе проверки не только подтверждали проблему, но и разрабатывали конкретные патчи. В ряде случаев сопровождающие уже приняли эти исправления и выпустили новые версии. В качестве примера упоминаются уязвимости в GhostScript, OpenSC и библиотеке CGIF — на момент раскрытия все три были уже закрыты.
Конфигурация среды, в которой работала модель, заметно отличалась от традиционных систем автоматического анализа кода. Claude Opus 4.6 предоставили доступ к полноценной виртуальной машине. Помимо исходников исследуемых проектов там были установлены стандартные инструменты разработчика (shell‑утилиты, coreutils, Python и др.), а также средства отладки, анализа памяти и даже инструменты для fuzzing‑тестирования. При этом модели не давали пошаговой инструкции, какие именно программы использовать и как именно искать баги — ей просто ставили цель: найти уязвимости, пользуясь любыми доступными средствами.
По сути, ИИ моделировал поведение опытного исследователя безопасности: сам выбирал стратегию, чередовал статический анализ кода, запуск тестов, чтение истории коммитов, сравнение версий, эксперименты с входными данными. Такая «самостоятельность» делает этот подход ближе к реальной работе человека‑ревьюера, а не к строго запрограммированному статическому анализатору.
Показателен пример с GhostScript. Сначала модель попыталась применить fuzzing‑подход, запуская программу с различными вариантами входных файлов. Не добившись результата, она переключилась на анализ исходников. Когда статический просмотр тоже не привёл к очевидной находке, ИИ перешёл к изучению истории git‑репозитория. В одном из коммитов модель обратила внимание на упоминание проверки границ буфера.
Проанализировав этот коммит, Claude Opus 4.6 восстановила, какой именно участок кода был исправлен: туда добавили недостающую проверку длины при обработке шрифтов. Далее модель вычленила старую, уязвимую версию кода и начала искать по базе места, где та же самая функция или паттерн вызова используется аналогичным опасным образом, но ещё не был защищён проверками. В результате в файле gdevpsfx.c был найден вызов функции gs_type1_blend без необходимой валидации значений. На следующем шаге модель подготовила специально сформированный файл, обработка которого приводила к записи данных за пределы выделенного буфера и, как следствие, к аварийному завершению программы.
В случае CGIF Claude Opus 4.6 исходила из допущения, заложенного в библиотеке, — что размер сжатых GIF‑данных никогда не превышает размер распакованных. ИИ сфокусировался на том, чтобы найти условия, при которых компрессия LZW может дать более длинный поток, чем ожидается при декодировании. Модель нашла такой сценарий и сгенерировала GIF‑файл, вызывающий переполнение буфера при распаковке.
В проекте OpenSC уязвимость была обнаружена через анализ использования потенциально опасных строковых функций на C — таких как strrchr и strcat. Claude Opus 4.6 отследила цепочку вызовов, при которой неконтролируемые входные данные могли привести к некорректной работе с буферами, и тем самым выявила ещё одну проблему, связанную с безопасностью памяти.
Anthropic подчёркивает, что языковые модели уже достигли уровня, на котором способны находить принципиально новые, прежде незафиксированные уязвимости. Ожидается, что в ближайшие годы ИИ‑системы по скорости и масштабу поиска багов начнут существенно обгонять отдельных человеческих экспертов и даже целые команды. Это, в свою очередь, может радикально увеличить поток отчётов об уязвимостях.
Рост числа обнаруживаемых проблем ставит под вопрос привычную модель раскрытия информации, когда на исправление уязвимости разработчикам отводится, например, стандартные 90 дней перед публичным раскрытием детали. Если ИИ начнёт генерировать тысячи качественных отчётов, индустрии придётся пересматривать процессы приоритизации, автоматизировать тестирование патчей и выстраивать новые схемы координации между исследователями и разработчиками.
Часть критиков задаётся вопросом: если ИИ уже так хорошо находит уязвимости, почему бы не поручить ему и полную автоматизацию написания патчей? На практике это уже частично делается: модель может предложить исправление, но каждое изменение должно пройти тщательную проверку людьми. Ошибочный патч в области безопасности зачастую опаснее самой уязвимости, потому что создаёт ложное ощущение защищённости. Поэтому сейчас естественная схема такова: ИИ предлагает и обосновывает исправление, а «мясной интеллект» — разработчики и аудиторы — детально его проверяют, пишут тесты и принимают окончательное решение.
Отдельная линия дискуссии касается того, насколько вообще разумно и безопасно полагаться на C и C‑подобные языки в эпоху, когда ИИ выявляет всё больше проблем именно в управлении памятью. На этом фоне активно всплывает сравнение с Rust и другими языками с жёсткими гарантиями безопасности памяти на уровне компилятора. Звучит тезис: «Если ИИ уже научился массово вылавливать ошибки в C‑коде, может, проще перестать писать критичный код на C и перейти на Rust?».
Здесь возникает ваш ключевой вопрос: что будет с производительностью C‑кода, если «обвесить» его всеми необходимыми проверками — границ массивов, корректности указателей, нулевых ссылок, валидности значений и т.д.? Насколько «самый быстрый язык для системного программирования» останется быстрым при таком подходе?
Ответ неоднозначен и сильно зависит от области применения:
1. Локальные проверки против архитектурных гарантий.
Если в уже существующий C‑код точечно добавлять проверки границ и состояния указателей, накладные расходы, конечно, возрастут. В критичных внутренних циклах это может быть заметно — вплоть до процентов или десятков процентов потери производительности. В не самых «горячих» участках программы влияние будет минимальным и зачастую несущественным.
2. Оптимизация компилятором.
Современные компиляторы (Clang, GCC) умеют устранять многие проверки, которые можно доказать избыточными на этапе компиляции. Если код написан аккуратно и предсказуемо, значительная часть проверок просто выкидывается оптимизатором, и реальный overhead оказывается неожиданно низким.
3. Ручной C с проверками vs Rust.
Когда вы пишете C‑код с заботой о безопасности памяти «вручную», вы фактически пытаетесь воссоздать поверх языка то, что Rust предоставляет встроенно: строгую систему владения памятью, проверку заимствований и др. Разница в том, что Rust заставляет делать это системно и гарантированно, а C позволяет легко «читерить» и забывать о каких‑то проверках. При сопоставимом уровне аккуратности и с учётом оптимизаций Rust‑код часто даёт такую же или очень близкую производительность, но с гораздо меньшим риском ошибок.
4. Цена микросекунд и цена уязвимости.
В одних областях (реальное время, ядра ОС, драйверы, высокочастотный трейдинг) каждая микросекунда на счету, и там разработчики иногда сознательно идут на компромиссы в безопасности ради скорости. В других — веб‑сервисы, десктопные приложения, утилиты — лишние проверки на уровне процентов производительности мало кого пугают, тогда как уязвимости обходятся очень дорого. По мере удешевления вычислений и ускорения железа баланс всё сильнее смещается в пользу безопасности.
5. ИИ как усилитель, а не оправдание небезопасного C.
Появление таких инструментов, как Claude Opus 4.6, не отменяет проблемы C, а делает её видимой и массовой. Да, ИИ может помочь закрыть огромное количество багов, но это не означает, что мы должны бесконечно латать C‑код. Более разумной стратегией всё чаще выглядит: переносить новые компоненты на языки с безопасной моделью памяти, а C окружать и усиливать — проверками, статическим анализом, fuzzing‑ом и ИИ‑аудитом.
Фактическая потеря производительности от «тотальной» проверки C‑кода сильно варьируется. В реальных проектах, где включают дополнительные рантайм‑проверки (например, для debug‑сборок), замедление может быть в 1.5–3 раза для сложных сценариев и почти незаметным — для типичных. Но важно понимать: там, где эти проверки критичны, обычно можно перенести особенно «горячие» участки в отдельные тщательно оптимизированные фрагменты, а для остального кода принять разумный overhead ради безопасности.
В этом и скрытый парадокс: если попытаться сделать C «по‑настоящему безопасным» повсеместно, он перестаёт быть тем самым «максимально быстрым» в общем случае — вы либо платите производительностью, либо сложностью и рисками. Rust и похожие языки, напротив, изначально спроектированы так, чтобы безопасность памяти обеспечивалась на уровне типов и компилятора, а не за счёт бесконечных ручных проверок в рантайме. Поэтому, когда вы добавляете в C все необходимые проверки, вы по сути пододвигаете его к Rust по идеологии, но без его системных гарантий.
На этом фоне роль ИИ‑моделей наподобие Claude Opus 4.6 может стать переходной: они помогают чистить гигантское наследие C‑кода, выявляя и закрывая самые опасные дыры. Параллельно индустрия постепенно переводит новые разработки на более безопасные языки, где большая часть класса ошибок работы с памятью просто невозможна на уровне конструкции языка.
В итоге ответ на вопрос «насколько замедлится C, если обезопасить его до предела?» — «настолько, что преимущество «самого быстрого системного языка» станет далеко не универсальным аргументом». Там, где нужны и высокая скорость, и предсказуемая безопасность памяти, баланс всё чаще будет смещаться в пользу языков вроде Rust — а ИИ будет использоваться и для поиска багов, и для автоматизации миграции, и для сопровождения сложных наследуемых C‑систем.
