Команда FFmpeg (открытого фреймворка для обработки видео в Google Chrome, Firefox, YouTube и других основных платформах) призвала Google либо профинансировать проект, либо прекратить обременять своих добровольцев-методистов уязвимостями безопасности, обнаруженными с помощью инструментов искусственного интеллекта компании. Разработчики исправили некоторые ошибки, обнаруженные ИИ-агентом Google, но назвали обнаруженную такие уязвимости «CVE-slop» (CVE-шлакотстой).
Инструментарий FFmpeg доступен для Linux, Windows и macOS. Проект распространяется под лицензиями GNU LGPL или GNU GPL. В состав FFmpeg входят: библиотека libavcodec — для кодирования и декодирования аудио и видео, библиотека libavformat — для мультиплексирования и демультиплексирования в медиаконтейнер, а также консольные утилиты ffmpeg и ffprobe, медиаплеер ffplay. Ранее в него входил потоковый сервер ffserver. Проект поддерживает большое количество аудио и видео кодеков, а также контейнеров.
Конфронтация разгорелась из-за политики Google Project Zero, объявленной в июле 2025 года, которая предусматривает публичное раскрытие информации об уязвимостях в течение недели и запуск 90-дневного отсчёта до полного раскрытия информации независимо от наличия исправления. FFmpeg, написанный преимущественно на языке ассемблера, обеспечивает преобразование форматов и потоковую передачу для VLC, Kodi и Plex, но работает без достаточного финансирования со стороны компаний, которые от него зависят.
«Мы очень серьёзно относимся к безопасности, но справедливо ли, что корпорации с оборотом в триллионы долларов используют ИИ для поиска уязвимостей в любительском коде пользователей? А потом ждать, что добровольцы всё исправят», — пояснили в команде FFmpeg.
Многие в сообществе FFmpeg небезосновательно утверждают, что для корпорации с оборотом в триллион долларов, такой как Google, которая активно использует FFmpeg в своих продуктах, неразумно перекладывать работу по устранению уязвимостей на неоплачиваемых волонтёров. Они считают, что Google должна либо предоставлять исправления вместе с отчётами об уязвимостях, либо напрямую поддерживать проект.
Ранее в FFmpeg отметили, что это далеко не единственный проект с открытым исходным кодом, сталкивающийся с подобными проблемами. В частности, команда проекта упоминает Ника Велнхофера, бывшего разработчика libxml2, широко используемой библиотеки с открытым исходным кодом для анализа XML (Extensible Markup Language).
Велнхофер недавно отказался от поддержки libxml2, поскольку ему приходилось «тратить несколько часов в неделю на решение проблем безопасности, о которых сообщали третьи лица. Большинство этих проблем не критичны, но всё равно требуют много работы». «В долгосрочной перспективе для такого неоплачиваемого волонтёра, как я, это неприемлемо. … В долгосрочной перспективе предъявлять такие требования к разработчикам ПО с открытым исходным кодом без выплаты им компенсации — пагубно. … Это ещё менее вероятно с Google Project Zero, где лучшие специалисты по безопасности, которых можно купить за деньги, дышат в затылок волонтёрам», — пояснил Велнхофер.
Представители отрасли пояснили, что основной проблемой остаётся то, что команде FFmpeg не хватает финансовых и программных ресурсов для борьбы с потоком уязвимостей, создаваемых ИИ. С другой стороны, эксперты по безопасности, безусловно, правы, считая, что FFmpeg — критически важная часть технологической инфраструктуры Интернета, и что проблемы безопасности необходимо публиковать ответственно и решать. В конце концов, хакеры могут использовать ИИ для поиска уязвимостей, подобно тому, как это делает Google со своим ИИ-поисковиком ошибок Big Sleep, и Google хочет заранее выявлять потенциальные уязвимости безопасности. Однако реальность такова, что без дополнительной поддержки со стороны компаний-триллионеров, получающих прибыль от открытого исходного кода, многие критически важные проекты с открытым исходным кодом, испытывающие острую нехватку финансирования и управляемые добровольцами, больше не будут поддерживаться.
Ранеекоманда открытого проекта runc (это инструмент командной строки для создания и запуска контейнеров в Linux в соответствии со спецификацией OCI) столкнулась с ростом pull-request и отчётов об ошибках, сгенерированных ИИ и решил принять меры, чтобы понять, что разработчики должны и чего не должны принимать из-за активности ИИ.
В октябре 2025 года Управляющий совет проекта Fedora после двухнедельных дискуссий утвердил правила, регламентирующие применение ИИ‑инструментов при разработке дистрибутива Fedora Linux. В проекте Fedora ИИ‑инструменты рассматриваются как потенциальная возможность сделать платформу лучше. У сообщества при этом имеются опасения, связанные с конфиденциальностью, безопасностью, этикой и качеством. В Fedora предложено не запрещать использование ИИ‑ассистентов при обязательном человеческом контроле за результатом их работы и несении разработчиком ответственности за код.
В середине октября 2025 года автор curl Даниэль Стенберг сообщил, что ИИ-инструменты для проверки кода Almanax, Corgea, ZeroPath, Gecko и Amplify позволили одному исследователю по ИБ Джошуа Роджерсу выявить и обнаружить сразу 50 ошибок и багов в открытой утилите. Оказывается, проблема была в разработчиках, а не в технологиях. В прошлом месяце проект curl получил десятки сообщений о потенциальных проблемах от Джошуа Роджерса, исследователя безопасности из Польши. Роджерс выявил множество ошибок и уязвимостей с помощью различных инструментов сканирования с помощью искусственного интеллекта. И его отчёты были не только достоверными, но и оценены по достоинству. Стенберг отметил, что «на самом деле, это действительно потрясающие находки».
Примечательно, что ранее Стенберг объявил, что его открытый проект curl перестанет изучать отчёты об уязвимостях через платформу HackerOne, полученные с помощью ИИ-систем. По заверению Стенберга, подобные массовые сообщения об уязвимостях от систем на базе ИИ перегружают команду проекта. Для проверки ИИ-отчётов необходимо время, которое несравнимо с тем временем, что тратится для создания подобных отчётов при помощи ИИ.
Источник: habr.com