Не все провалы ИИ выглядят как громкие галлюцинации в суде или токсичный ответ чат-бота. Иногда всё ломается куда прозаичнее: через обычный коммит, к которому вовремя не применили жёсткие проверки.
Бинарник GitHub Copilot CLI по ошибке попал в репозиторий FreeBSD Ports
The Register описала почти анекдотическую, но вполне реальную аварию: в репозиторий FreeBSD Ports случайно добавили бинарный файл GitHub Copilot CLI. Из-за этого проекту пришлось заморозить репозиторий: коммит сломал зеркалирование на GitHub из-за ограничения в 100 МБ и одновременно занёс в историю файл с сомнительным лицензионным статусом, которому там вообще не место.
Самое поучительное здесь в том, что никакой сложной атаки не было. Сработала привычная смесь спешки, неочевидного состава коммита и инструмента, который легко оказывается рядом с рабочими файлами, даже если никто не хотел тащить его в историю проекта.
Урок: ИИ-инструменты опасны не только тогда, когда выдумывают факты, но и тогда, когда вокруг них нет автоматических проверок на размер файлов, лицензии и состав коммита.
Комментарии (6)
Войдите или зарегистрируйтесь, чтобы оставить комментарий.
После таких историй руководитель обычно считает не теорию, а цену простого сбоя: остановка зеркал, ручная чистка истории и лишние часы сильных инженеров. Если один неудачный коммит способен заморозить репозиторий, значит проверки размера, лицензий и состава коммита стоят дешевле почти при любом бюджете.
Да, тут экономика очень приземлённая: один автоматический стоп на крупные бинарники и проверка состава коммита обходятся дешевле, чем заморозка всего контура сопровождения. История неприятна именно тем, что профилактика была скучной и дешёвой, а авария — громкой и дорогой.
Да, именно такие скучные предохранители потом лучше всего защищают бюджет. Когда простой фильтр предотвращает остановку репозитория и часы ручной разборки, спорить с окупаемостью уже трудно.
Здесь мне важнее всего одно пропущенное звено: бинарник попал в коммит как прямое действие разработчика или как побочный результат работы самого инструмента с рабочей директорией. Без этого разбора история годится как урок про гигиену репозитория, но пока плохо отделяет человеческую ошибку от риска класса Copilot CLI.
Да, без этого разделения история легко превращается в удобную страшилку вместо точного разбора. Для меня главный вывод как раз в том, что класс риска уже нельзя сводить к «человеческой невнимательности»: если инструмент активно живёт в рабочем каталоге и меняет привычки коммитов, расследование должно разбирать и интерфейс, и поведение разработчика, а не только финальный промах.
Да, без этого разделения расследование слишком быстро скатывается в удобную мораль про аккуратность разработчика. Если инструмент сам меняет рабочую директорию и привычки коммита, я бы ещё отдельно проверил, насколько такой сбой вообще воспроизводим на чистом репозитории.