Среднее время до эксплуатации уязвимости уже ушло в минус: автор колонки ссылается на оценку в минус семь дней, а CrowdStrike говорит, что 42% реально эксплуатируемых багов начинают использовать еще до публичного раскрытия. На этом фоне клиринговые центры уязвимостей внезапно стали главным жанром лета 2026 года: рынок пытается придумать, как обмениваться опасными находками быстрее, чем их успевают монетизировать атакующие.
Поводом стала колонка CEO и сооснователя Chainguard Дэна Лоренка: как пишет The Hacker News, компания официально объявила о своем clearinghouse-проекте Athena только сейчас, хотя, по ее версии, сервис уже несколько месяцев работал в закрытом режиме. Лоренц подчеркивает, что Athena собирает не обычные CVE из публичных лент, а pre-disclosure-уязвимости в open source, то есть баги, которые еще не раскрыты публично и потому особенно токсичны. Для русскоязычной IT-аудитории смысл простой: проблема уже не в том, чтобы узнать о баге, а в том, чтобы успеть встроить исправление в сборку до того, как опубликованный патч превратится в инструкцию для эксплойта.
Сама идея clearinghouse, если убрать маркетинг, не новая. NVD, GitHub Advisory Database, OSV и вендорские базы уязвимостей много лет делают ровно одно и то же: складывают данные в общую точку входа. Новизна, по версии Chainguard, в другом типе данных. Теперь туда летят не только опубликованные CVE, а частные находки из длинного хвоста open source-пакетов: от популярных библиотек до зависимостей, о которых разработчик узнает только в момент инцидента. И тут неприятная правда для любого CTO: в Unix-процессе маленькая забытая библиотека нередко получает те же привилегии, что и само приложение. Поэтому компрометация «листа» в dependency tree спокойно превращается в компрометацию всего процесса.
Лоренц отдельно настаивает на мысли, которая многим вендорам может не понравиться: база находок сама по себе почти ничего не стоит. Ценность не в том, что у вас есть запись об уязвимости, а в том, что вы умеете превратить ее в пересобранный, протестированный, подписанный и доставленный артефакт. Chainguard утверждает, что ее конвейер автоматически следит за тысячами open source-проектов, а большинство CVE закрывает примерно за два дня без участия человека. Для уязвимостей, которые CISA относит к категории активно эксплуатируемых, заявлен SLA в один день. Еще одна цифра из колонки: компания уже устранила более 100 тысяч уязвимостей, а в рамках Athena приняла свыше 20 тысяч находок и выпустила более 2 тысяч патчей в 500 проектах. Даже если воспринимать эти числа как самоотчет вендора, они хорошо показывают, куда сместился центр тяжести: из витрины с advisory в фабрику исправлений.
Почему таких инициатив вдруг стало много именно сейчас, ответ тоже неприятно приземленный: это побочный эффект бума ИИ-моделей для безопасности. По описанию автора, frontier-модели уже не просят «посмотри файл и найди баг», а запускают против живого приложения почти атакующую сессию: приложение работает, отладчик подключен, исходники и окружение под рукой, запрос к модели звучит примерно как «сломай это». В собственном коде компании еще могут быстро чинить найденное сами. Но основная масса продакшн-приложения давно состоит не из first-party-кода, а из стареющих open source-зависимостей. Модель не уважает границу между «написали сами» и «подтянули из npm, PyPI или Maven»: если рабочий эксплойт проходит через библиотеку третьего уровня, именно она и становится новой головной болью. Отсюда и поток закрытых, но общих для рынка находок.
Отсюда же вытекает второй тезис колонки: больших площадок обмена будет немного, потому что десятки мелких только ухудшат ситуацию. Логика такая: уязвимости редко совпадают один в один, но почти всегда упираются в один и тот же набор популярных библиотек, которые живут во всех стеках сразу. Чем больше пул участников, тем полнее покрытие этого общего слоя. Плюс возникает рычаг давления и помощи upstream-мейнтейнерам: вместо тридцати странных писем от разных исследователей у них появляется один внятный канал работы. Но и монополия тут тоже выглядит плохо: один хаб с нераскрытыми эксплойтами был бы слишком привлекательной целью. Лоренц прямо пишет о риске концентрации, ссылается на позицию австралийского регулятора APRA и делает вывод, что рынок, скорее всего, придет не к одному центру и не к сотне, а к нескольким крупным операторам.
Для разработчиков, продуктовых команд и ИБ-служб из этой истории есть вполне прикладной вывод. Если вендор приходит продавать вам очередной clearinghouse, спрашивать надо не про размер базы, а про две вещи. Первая: сколько в среднем проходит времени от находки до готового исправленного артефакта и какая доля кейсов проходит без ручного труда. Вторая: сколько исправлений реально доходит upstream, в исходный проект, а сколько остается только внутри закрытого канала поставщика. Иначе вы покупаете не снижение системного риска, а частный сервис по латанию последствий для избранных клиентов. На фоне модели эксплуатации «патч как карта к багу» это уже не тонкость, а разница между контролируемой поставкой и красивой презентацией.
Самый интересный сдвиг здесь даже не в новых названиях, а в смене режима раскрытия. Классическая coordinated disclosure строилась вокруг медленного человеческого ритуала: исследователь, мейнтейнер, согласование сроков, публикация. В логике машинного поиска багов такой ритуал просто не масштабируется. На смену ему приходит оркестрация: не один maintainer и один репортер, а цепочка из автоматической пересборки, backport, подписи артефактов, обновления detection-контента, сетевых правил, VEX-данных и upstream pull request в один такт. Если этот подход взлетит, следующей метрикой зрелости supply chain security станет не количество найденных багов, а способность сделать так, чтобы очередной Log4j заканчивался еще до того, как половина команд успеет открыть ноутбук. Подробности исходной колонки и цифры автора можно посмотреть в .