Закрытые ИИ-модели все чаще продают как помощников для безопасной работы с кодом. Но в реальной отладке они могут упереться в собственные фильтры. Исследователь безопасности Daniel Fox Franke рассказал, что GPT-5.6 Sol не помог ему разобрать повторяющийся segfault в ripgrep, и в итоге расследование пришлось продолжать на моделях с открытыми весами.
Для команд разработки и ИБ это неприятный сигнал. Если инструмент блокирует обычный разбор падения, он перестает быть рабочим инструментом и превращается в демонстрацию того, что у вендора свои приоритеты.
Что произошло во время разбора segfault
О кейсе 29 июля 2026 года написал The Register. По словам Franke, проблема началась с повторяющегося segfault в ripgrep во время долгой сессии Codex. Он поручил агенту выяснить причину сбоя, но почти сразу столкнулся со срабатываниями отдельного классификатора OpenAI по кибербезопасности.
Franke привел конкретный пример: система не дала модели ответить даже на вопрос о том, какие точки входа из rg в musl приводят к выделениям памяти в куче mallocng. То есть речь шла не о написании эксплойта и не о вскрытии чужой инфраструктуры, а о вполне рутинной технической трассировке причин падения.
Исследователь отдельно подчеркнул, что проблема была не в самой модели, а во внешнем фильтре. По его словам, Sol продолжал работать добросовестно и сам понимал, что часть блокировок выглядит неуместно. Чтобы снять лишние подозрения, Franke завел новый контекст и заранее ограничил задачу: анализировать только исходники ripgrep и musl, не воспроизводить падение и не разбирать core dump. Это не помогло.
Почему помогли модели с открытыми весами
После нескольких неудачных попыток Franke переключился на две модели китайских разработчиков: Z.ai GLM-5.2 и Moonshot AI Kimi K3. Здесь история стала интереснее. Kimi K3, по его словам, первой вывела расследование на верный след и показала, что проблема, вероятно, находится не в пользовательском пространстве, а в ядре Linux.
Но дальше Kimi K3 начала спешить с выводами, путать собственную доказательную базу и заметно просела на длинном контексте. Финальную работу, как утверждает Franke, довела до конца уже GLM-5.2: перепроверила промежуточные выводы и помогла собрать аккуратный, непротиворечивый разбор.
Здесь важна оговорка, без которой новость легко скатить в драму. Пока это не история про готовую критическую уязвимость. Патча нет, подтвержденной эксплуатируемости тоже нет. На текущем этапе Franke уверен в двух вещах: сбои вызывает баг в ядре, и конкретный баг он уже локализовал. Но связь между этим дефектом и наблюдаемыми крашами еще нужно окончательно доказать перед отправкой материалов в Linux Kernel Mailing List.
Доступ к закрытым моделям стал отдельным барьером
OpenAI предлагает специальные программы доступа для исследователей безопасности, где часть ограничений может быть ослаблена. Franke этим путем не пошел. Он рассказал The Register, что не спешит проходить отдельную верификацию и считает саму процедуру лишним унижением, пока на рынке есть рабочие альтернативы без дополнительного согласования с вендором.
Это, пожалуй, и есть главный нерв всей истории. Спор уже не про идеологию open source, а про операционную пригодность. Можно ли закончить задачу здесь и сейчас, не выпрашивая разрешение у поставщика модели на каждый неудобный запрос.
Значение для рынка
Для русскоязычных команд вывод довольно приземленный. Закрытые модели подходят для многих задач разработки, но в low-level debugging, разборе падений и техническом triage они могут дать неожиданный отказ в самый неподходящий момент. Поэтому ИБ-командам, разработчикам системного ПО и тем, кто работает с C, Rust, Linux и собственной инфраструктурой, имеет смысл держать резервный стек: хотя бы одну модель с открытыми весами или локальный контур для чувствительных сценариев.
Иначе выбор инструмента получится странным: код он вроде понимает, но как только разговор доходит до памяти, ядра или причин segfault, в комнату входит модерация и выключает свет.
Источник: The Register, публикация от 29 июля 2026 года.
Следующий тест для рынка будет простым: смогут ли поставщики закрытых моделей отделить реальный вредоносный сценарий от обычной инженерной отладки, не ломая работу тем, кто действительно ищет и чинит баги.