В экосистеме open source появилась новая попытка навести порядок там, где обычно царит режим «работает — не трогай». Фонд Commonhaus Foundation запустил Open Source Sustainability Initiative, или OSSI, чтобы компаниям было проще сопровождать и защищать EOL open source — то есть проекты, формально дошедшие до конца жизненного цикла, но по факту продолжающие крутиться в продакшене и тянуть за собой риски.
О запуске инициативы, как пишет Dark Reading, стало известно 26 июня 2026 года. По замыслу Commonhaus, OSSI должна помочь бизнесу разобраться сразу с несколькими задачами: что делать с уязвимостями в устаревших open source-компонентах, как мигрировать на поддерживаемые версии и как при этом не вылететь из регуляторных требований. Формулировка выглядит спокойной, но проблема у рынка совсем не академическая: проект может считаться «мертвым» для мейнтейнеров, а для корпоративной инфраструктуры он все еще вполне живой и даже критичный.
Председатель Commonhaus Foundation Эрин Шнабель прямо описывает типовой сценарий: компании продолжают использовать EOL-софт, который не могут быстро обновить, а новые CVE по нему продолжают появляться. Это как раз тот случай, когда жизненный цикл продукта закончился только на бумаге. В реальной ИТ-эксплуатации такие зависимости могут жить годами, потому что на них завязаны внутренние сервисы, интеграции, старые фреймворки и процессы, которые никто не хочет ломать перед квартальным релизом. В итоге бизнес получает неприятную комбинацию: поддержку уже сняли, а поверхность атаки никуда не делась.
Контекст у новости показательный. По данным Black Duck, на которые ссылается издание, число компонентов в одном приложении за год выросло на 30%. При этом среднее количество уязвимостей в open source-кодовой базе более чем удвоилось. Иными словами, современная разработка все сильнее зависит от внешних библиотек, а разбираться с их состоянием становится все дороже и скучнее. Параллельно, как отмечает Dark Reading, экосистема получила еще один удар после того, как Национальный институт стандартов и технологий США ранее в этом году изменил подход к обработке CVE. Для компаний это означает простую вещь: сигналов об уязвимостях больше, а свободных рук, готовых бесконечно чинить старые ветки ради чужого compliance, меньше.
Одним из учредителей OSSI стала HeroDevs. Ее операционный директор Роб Нален говорит о проблеме без дипломатии: объем работы, который перекладывается на open source-сообщества, стал попросту неподъемным. Логика инициативы здесь вполне прагматичная. Бизнесу нужен не лозунг про важность открытого кода, а понятный набор опций: где можно получить исправления для устаревшего компонента, как безопасно прожить переходный период и когда модернизация действительно неизбежна. Для разработчиков это тоже неприятная, но честная реальность: если проект давно заброшен, надеяться на добровольцев как на вечную линию техподдержки уже странно.
Отдельный слой проблемы — влияние ИИ на темп этой гонки. По словам Налена, ИИ уже помогает быстрее находить уязвимости и писать код, но это совсем не значит, что он так же легко решает проблему старого стека. Да, модели могут ускорить рутинную переработку устаревшего кода и подсказать типовые паттерны обновления. Но когда дело доходит до зависимостей нижнего уровня, несовместимых версий и длинной цепочки сторонних библиотек, магия заканчивается. ИИ может переписать кусок приложения за секунды, а вот аккуратно протащить через обновление сотни зависимостей, ничего не сломав, уже заметно сложнее. Плюс никто не отменял галлюцинации и склонность моделей недооценивать downstream-эффекты.
Для корпоративного ИТ все это упирается не только в безопасность, но и в соответствие требованиям регуляторов и стандартов. В материале упоминаются PCI DSS и европейский DORA. Особенно показателен пункт 12.3.4 в PCI DSS 4.0: организация должна ежегодно проверять, не дошли ли используемые технологии, включая софт, до конца жизненного цикла. Если дошли, нужен план ремедиации. Это уже не разговор в стиле «починим потом, когда появится окно». Если критичный компонент формально EOL, его присутствие в инфраструктуре превращается из технического долга в вопрос аудита, а иногда и в прямую головную боль для CISO, CTO и владельцев продукта.
Отсюда и еще один важный сдвиг, который фиксирует рынок. Долгое время команды могли мириться с «красными флагами», пока приложение выполняло бизнес-функции и не падало по ночам. Незапатченная уязвимость? Неприятно, но переживем до следующего цикла. Устаревший фреймворк? В бэклоге полежит. По оценке участников инициативы, такая терпимость быстро исчезает. На фоне роста числа атак и утечек руководители по безопасности все чаще перестают принимать аргумент «зато оно работает». И это, пожалуй, главный сигнал для русскоязычной ИТ-аудитории: инвентаризация зависимостей, политика замены EOL-компонентов и сценарии временной поддержки больше не выглядят как бюрократия для галочки. Это уже часть нормальной инженерной гигиены.
У OSSI амбиция здравая: сделать прозрачнее жизненный цикл стареющих open source-проектов и выстроить кооперацию между мейнтейнерами, фондами, поставщиками и компаниями-потребителями. Вопрос теперь в другом: готов ли корпоративный софтверный рынок перестать относиться к EOL open source как к неловкому секрету в dependency tree и начать платить за его сопровождение так же осознанно, как за облака, observability и incident response.