Инженеры Google описали в блоге Bug Hunters пилот, в котором модель Gemini переписала классическую C-библиотеку giflib для декодирования GIF объёмом около трёх тысяч строк в безопасную по памяти Rust-версию. Результат задуман как ABI-совместимая drop-in замена для продакшн-инфраструктуры и прошёл жёсткую проверку эквивалентности: бит-в-бит совпадение с оригиналом на корпусе из десятков миллионов реальных GIF и многодневный параллельный фаззинг двух версий без единого логического расхождения. Вскоре после начала развёртывания в оригинальном giflib 5.2.2 публично раскрыли CVE-2026-26740, heap buffer overflow, — и уже мигрировавшие на Rust-версию системы Google оказались к нему иммунны.

image

Что произошло

Инженеры Google Bastian Kersting и Max Hils описали пилот по миграции giflib, библиотеки Эрика Рэймонда для декодирования GIF, из C в Rust с помощью Gemini; целевой результат — ABI-совместимая drop-in замена, которую можно ставить в продакшн-инфраструктуру без изменения вызывающего кода. Работа не свелась к одной генерации: за ней шла итеративная починка FFI-границы, при этом весь unsafe-код финально ревьюили эксперты. Валидация опиралась на три слоя: регресс-прогон более чем на 30 млн реальных GIF, где вывод Rust-версии совпал с оригиналом бит-в-бит; дифференциальный фаззинг C- и Rust-версий параллельно — более 200 млн итераций за шесть с лишним дней без логических расхождений; и LLM-adversarial review, которая дополнительно нашла edge-case в LZW-декодере и out-of-bounds write, унаследованный из внутреннего патча Google. Компиляторные проверки границ не дали ценового штрафа: производительность осталась нейтральной, хвостовая латентность декодирования снизилась, а песочницу вокруг библиотеки сняли. Развёртывание шло поэтапно, с заранее подготовленным планом отката.

Контекст

Мотивировка миграции количественная: примерно 70% уязвимостей в C/C++-коде относится к классу проблем безопасности памяти. Исторически у владельцев такого кода было два пути — вечный патчинг старых библиотек или ручное переписывание людьми; как пример второго пути в материале упоминается проект zlib-rs от Trifecta Tech Foundation. giflib оказался удачным первым кандидатом по структуре задачи: это компактный, жёстко специфицированный декодер формата, для которого существует готовый оракул эквивалентности в виде бит-в-бит сравнения выходов и огромный естественный корпус входных данных. Именно требование эквивалентности задаёт цену метода: поведение замены обязано совпасть с оригиналом, что невозможно без больших датасетов реальных данных, дифференциального тестирования и интенсивного фаззинга, а доверие команды к сгенерированному коду зарабатывается объёмом такой валидации, а не верой в модель.

Почему это важно для индустрии

Для отрасли это воспроизводимый конвейер структурной санации зависимостей: одношаговое LLM-переписывание, итеративная починка FFI-границы с экспертным ревью unsafe-кода, дифференциальный фаззинг плюс adversarial-LLM-анализ и поэтапный деплой с планом отката — схему можно переносить на другие библиотеки. Кейс CVE-2026-26740 стал первой натурной демонстрацией главного тезиса: такая миграция устраняет ещё не раскрытые zero-day уязвимости зависимости как класс, а не патчами по одному CVE, то есть миграция превращается в страховку от будущих уязвимостей, а не только в разовую статью расходов. Прагматичный вывод для строителей продуктов: генерация кода через модели коммодитизируется, а ценность смещается в обвязку доказательной эквивалентности — регресс на реальных данных, параллельный фаззинг, adversarial-ревью и CI-интеграция такой проверки. Приоритеты тоже понятны уже сейчас: первыми кандидатами на миграцию выглядят декодеры и парсеры, которые интенсивно разбирают недоверенный ввод.

Почему это важно для пользователей

Методология переиспользуема уже сегодня без ожидания готового продукта. Для своей небольшой C-зависимости можно собрать регресс-корпус реальных входов, сравнивать поведение старой и новой версий бит-в-бит, запустить дифференциальный фаззинг двух вариантов параллельно и добавить LLM-adversarial review — последний приём применим даже к коду, который никто не собирается переписывать, и может найти скрытые дефекты в существующем проекте. Материал честно откалибрует ожидания: доверие к сгенерированному коду зарабатывается валидацией, а быстрые победы не гарантированы. Практический аргумент против тезиса «безопасное значит медленное» тоже получен: компиляторные проверки границ не снизили производительность, а хвостовая латентность декодирования даже уменьшилась. Отправное действие для команды — картографировать свои C/C++-зависимости и выбрать кандидатов с хорошо специфицированным форматом и большим потоком недоверенного ввода.

Что пока неизвестно / ограничения

Это пока кейс n=1: около 3000 строк компактного, жёстко специфицированного декодера с готовым оракулом эквивалентности и огромным естественным корпусом входов. Неизвестно, масштабируется ли конвейер на библиотеки большего размера, слабее специфицированные интерфейсы или домены, где бит-в-бит эквивалентность недостижима; ответ должны дать независимые репликации с метриками по размеру кода и типу домена. Готового продукта под ключ не существует: нужны доступ к Gemini, корпус реальных входных данных и фаззинг-инфраструктура. Граница C/Rust (FFI) остаётся небезопасной зоной даже после успешной миграции, поэтому без экспертного ревью unsafe-кода метод не работает. Наконец, встречающийся в обсуждениях вывод, что LLM-переписывание «перестало быть экспериментом», преждевременен: барьер для миграций заметно снизился, но не исчез.

Источники

Автор

Look at AI, редакция