Этим летом случилось странное совпадение. За несколько недель друг от друга частный проект, компания, потратившая пять миллиардов долларов на пресс-релиз, и Белый дом — все использовали одно и то же слово: clearinghouse, «расчётная палата» для данных об уязвимостях. Когда три настолько разных игрока одновременно хватаются за один термин, это не мода. Это сигнал, что с проблемой безопасности что-то реально изменилось. Но вот в чём подвох: сама эта палата данных — наименее важная часть из всего, что нужно построить. Важно то, что происходит после — превращение находки в реально закрытую дырку.
Компания Chainguard тихо собирала свой продукт Athena месяцами, и он уже работал, когда конкуренты начали публично анонсировать похожие штуки. Объявили о нём только тогда, чтобы не выглядеть так, будто отсиживаются в кустах. К моменту анонса Athena уже впитала больше 20 000 находок, выпустила свыше 2000 патчей по 500 проектам. Но сама Athena — это просто новая труба, подключённая к старому заводу. У Chainguard годами работал конвейер: система следит за тысячами открытых проектов, при появлении advisory сама забирает исходники, пересобирает, тестирует, подписывает. Большинство CVE закрываются за пару дней без участия человека вообще. Для уязвимостей, помеченных CISA как активно эксплуатируемые, действует правило одного дня. За всё время через этот конвейер прошло больше 100 000 устранённых уязвимостей.
Сама идея пула данных об уязвимостях не новая. NVD, GitHub Advisory Database, OSV, десятки вендорских порталов — все они по сути один и тот же принцип: собрать данные и приделать к ним входную дверь. Что реально новое летом 2025 года — эти палаты начали копить уязвимости до публичного раскрытия, причём не только по крупным проектам, но и по совсем малоизвестным библиотекам глубоко в зависимостях. Из-за того, как устроена процессная модель в Unix, дефект в самой захолустной зависимости получает те же привилегии, что и родительское приложение. Мелкая библиотека способна скомпрометировать весь процесс целиком. Отсюда простой вывод: если сам пул не новость, то и не в пуле дело.
Данные сами по себе мёртвые. Запись в базе никого и никогда не патчила. Тяжёлая и по-настоящему ценная часть работы — доведение находки до пересобранного, протестированного, подписанного артефакта, который лежит там, где его уже ищут существующие инструменты. Chainguard делает это годами, ниже по течению от любой публичной палаты данных. Athena появилась не потому, что кто-то придумал новую концепцию, а потому что команды, работающие над передовыми AI-моделями, попросили придумать способ закрывать уязвимости, которые нельзя разглашать публично.
И вот здесь начинается самое интересное. Поток приватных уязвимостей — это побочный продукт нового метода их поиска с помощью AI. Модель (внутри называют её Mythos) наводят на работающее приложение, дают ей дебаггер, песочницу и исходный код, а потом просят напрямую: «Сломай это». С кодом первого лица модели справляются легко — это же ваш собственный код, вы его владелец. Проблема в том, что реальное приложение почти всегда состоит из открытых зависимостей, часто устаревших. Модель не видит границы между вашим кодом и чужим — она спокойно выстраивает цепочку эксплойта через неподдерживаемую библиотеку, которую никто не сопровождает уже годы. В итоге получается рабочий, живой эксплойт для кода, у которого формально нет владельца. Заряженное оружие, которому некуда идти. Отсюда два свойства новых данных: они приватны, потому что это работающее оружие, и они концентрируются на общих целях, потому что одни и те же несколько десятков библиотек встречаются во множестве разных приложений и моделей. Сами находки редко пересекаются, а вот код, в котором они всплывают, — постоянно.
Скорость атакующих подтверждает срочность. Среднее время до эксплуатации сейчас составляет минус семь дней — то есть в среднем атаки начинаются ещё до того, как патч стал публичным. Раньше этот показатель был больше 60 дней, а через нулевую отметку он прошёл в 2024 году. Цифры подтверждают Mandiant, Google и CrowdStrike. По данным CrowdStrike, 42% эксплуатируемых уязвимостей атакующие используют ещё до публичного раскрытия. Сам опубликованный патч — это карта: диффы прямо указывают на баг. Собственные эксперименты автора показали, что advisory превращается в рабочий эксплойт менее чем за час, даже без публичного proof-of-concept.
Почему большие пулы выигрывают у мелких — здесь работают четыре механизма. Находки кучкуются вокруг одних и тех же нескольких библиотек, и крупный пул полнее покрывает эту общую поверхность атаки. Каждое исправление общей библиотеки защищает сразу всех, кто от неё зависит, — покрытие растёт нелинейно с числом участников. Масштаб даёт рычаг влияния на мейнтейнеров — они охотнее идут на контакт с одной узнаваемой командой безопасности, чем с толпой незнакомцев. И масштаб даёт возможность оркестровать реакцию сразу на нескольких уровнях — только те, кто «в комнате» (CDN, сетевые правила, вендоры безопасности, контент детекции, продакшн-доступ, бэкпорты), способны действовать одновременно. Отдельно стоит заметить: канал, где хранятся неразглашённые эксплойты, сам по себе становится самой лакомой целью во всей экосистеме — защитить его способна только серьёзная, хорошо финансируемая структура. Маленький, тонкий пул — это не облегчённая версия хорошей идеи, это отмычка от всего.
Отсюда логичный вопрос: почему не сделать одну гигантскую палату на всех? Риск монокультуры реален — единый пул с чужими предраскрытыми эксплойтами становится универсальной отмычкой для всего интернета. Австралийский банковский регулятор APRA прямо требует от банков одновременно двигаться со скоростью AI и управлять риском концентрации — задача почти противоречивая сама по себе. Ни одна компания, потратившая пять миллиардов долларов на собственную палату, не станет вливать её в инфраструктуру конкурента. И ни одна страна не станет пускать поток предраскрытых эксплойтов для своей критической инфраструктуры через чужой национальный пул.
Но и десятки мелких палат — не решение. Общий код означает пересекающиеся эмбарго, конкурирующие исправления и ситуацию, когда раскрытие в одном пуле обрушивает защиту, построенную другим. Поверхность переговоров растёт пропорционально квадрату числа палат: несколько штук — это управляемая рабочая группа, десятки — та же фрагментация, от которой все пытались уйти. Правильная модель ближе к тому, как устроена другая критическая инфраструктура доверия — корневые DNS-серверы, крупные облачные провайдеры, сертификационные центры после появления Let's Encrypt. Не одна структура и не тысяча — несколько крупных операторов. При этом палата данных — не облачный провайдер: здесь нет эффекта заложника и привязки к вендору. Перестал доверять — прекратил слать данные и через один период эмбарго перешёл к другому.
Есть ещё контринтуитивный момент. Риск утечки определяется не тем, сколько всего накопилось в базе за всё время, а тем, что именно находится в обороте под эмбарго прямо сейчас. Снижение риска означает не сокращение числа принимаемых находок, а ускорение их обработки. По-настоящему опасная палата — медленная, где скопился хвост необработанных находок, потому что скорость закрытия дыр не успевает за притоком новых. Именно этот накопленный хвост и есть поверхность утечки. Отсюда прямое обязательство: «если наш пул растёт — мы проигрываем». Здоровая палата данных работает в устойчивом состоянии: приток равен оттоку, размер не меняется. Размер пула — это термометр, а не трофей.
Классическая координированная модель раскрытия (CVD) — один исследователь, один мейнтейнер, согласованный график — строилась под медленную эпоху и физически не масштабируется на тысячи одновременных находок. Новая модель называется оркестрованным раскрытием: автоматизация приводит в действие сразу множество контрольных точек — правила WAF, сетевые сигнатуры, бэкпорты, VEX-данные, контент детекции, upstream pull request'ы — так, чтобы все они сработали в момент раскрытия одновременно, как дирижёр, ведущий весь оркестр к одной общей ноте. Показательный пример отсутствия такой оркестровки — история с Log4j. Сам процесс раскрытия и патча там сработал нормально, хаос возник из-за того, что около ста тысяч команд безопасности независимо друг от друга проделывали одну и ту же экстренную работу руками: искали один и тот же класс через grep, писали одинаковые правила WAF, дёргали одинаковые флаги, охотились за скопированными теневыми версиями библиотеки, а потом переделывали всё заново, когда первый патч оказался неполным. Потерянный месяц — не провал раскрытия, а отсутствие слоя оркестрации. Человек всё ещё нужен для переговоров об эмбарго и для того, чтобы устойчивое исправление приняли в апстрим. Всё, что идёт после этой общей ноты, можно и нужно автоматизировать.
Дальше будет ещё много анонсов подобных палат данных, и большинство окажется шумом — сам запуск никогда не был метрикой. Есть простой тест из двух вопросов для оценки любого вендора: какое медианное время от находки до пересобранного, протестированного и подписанного исправления, и какая доля закрывается без участия человека; и сколько из выпущенных фиксов действительно попали в апстрим — в реальный исходный код — а не осели только у прямых клиентов вендора. Находки — это тщеславие. Фикс, до которого никто не может дотянуться, немногим лучше просто найденной проблемы. Настоящая метрика — сколько людей защищено за месяц, считая и прямых клиентов, и всех, кого прикрыло исправление, попавшее выше по течению. Chainguard обещает публиковать эти цифры: медианное время от находки до фикса, долю без ручного вмешательства, долю фиксов, дошедших до апстрима. Ранние показатели, как признаётся автор, «не будут красивыми» — массовый апстриминг в таком масштабе существует всего несколько недель, но публиковать их всё равно нужно: «тест, который сам не готов пройти, — не тест». Серьёзных игроков можно узнать по неоплачиваемой работе — интеграциям, партнёрствам, апстрим pull request'ам, которые строят доверие, а не выручку. Тем, кто думает строить собственную палату данных, стоит сначала спросить себя, есть ли у них «завод» — конвейер fetch/rebuild/test/sign. Без него палата данных — это просто почтовый ящик, который никто не проверяет.
Есть и неопределённость на горизонте: следующее поколение AI-моделей может найти намного больше дыр в уже отсканированном коде. Патчинг уязвимостей — это постоянная беговая дорожка, которая теперь просто разогналась быстрее. Команды безопасности знают правильную гигиену — своевременный патчинг, минимизацию поверхности атаки, актуальность зависимостей — уже лет десять, но редко удерживают её постоянно. Палаты данных — это страховочная сетка под этой дорожкой, возможно она чуть притормаживает бег, но не отменяет саму необходимость бежать. Настоящий выход с дорожки — пересобрать библиотеки, фреймворки и инструменты так, чтобы целые классы уязвимостей стали структурно невозможны, а не просто исправлялись реактивно постфактум. Финальная цель — открытый исходный базовый слой настолько крепкий, что AI-модели остаются с пустыми руками, а сами палаты данных простаивают без работы. Верный признак серьёзных игроков — они гонятся за тем, чтобы сделать себя ненужными. Secure by design было правильным ответом последние тридцать лет, но так и не стало массовой практикой, и никакой гарантии, что получится сейчас, нет. Как формулирует сам автор: «Мы никогда не собирались выигрывать эту гонку скоростью. Это лето clearinghouses не будет длиться вечно. Если мы всё сделаем правильно — оно и не должно.»
Компания Chainguard тихо собирала свой продукт Athena месяцами, и он уже работал, когда конкуренты начали публично анонсировать похожие штуки. Объявили о нём только тогда, чтобы не выглядеть так, будто отсиживаются в кустах. К моменту анонса Athena уже впитала больше 20 000 находок, выпустила свыше 2000 патчей по 500 проектам. Но сама Athena — это просто новая труба, подключённая к старому заводу. У Chainguard годами работал конвейер: система следит за тысячами открытых проектов, при появлении advisory сама забирает исходники, пересобирает, тестирует, подписывает. Большинство CVE закрываются за пару дней без участия человека вообще. Для уязвимостей, помеченных CISA как активно эксплуатируемые, действует правило одного дня. За всё время через этот конвейер прошло больше 100 000 устранённых уязвимостей.
Сама идея пула данных об уязвимостях не новая. NVD, GitHub Advisory Database, OSV, десятки вендорских порталов — все они по сути один и тот же принцип: собрать данные и приделать к ним входную дверь. Что реально новое летом 2025 года — эти палаты начали копить уязвимости до публичного раскрытия, причём не только по крупным проектам, но и по совсем малоизвестным библиотекам глубоко в зависимостях. Из-за того, как устроена процессная модель в Unix, дефект в самой захолустной зависимости получает те же привилегии, что и родительское приложение. Мелкая библиотека способна скомпрометировать весь процесс целиком. Отсюда простой вывод: если сам пул не новость, то и не в пуле дело.
Данные сами по себе мёртвые. Запись в базе никого и никогда не патчила. Тяжёлая и по-настоящему ценная часть работы — доведение находки до пересобранного, протестированного, подписанного артефакта, который лежит там, где его уже ищут существующие инструменты. Chainguard делает это годами, ниже по течению от любой публичной палаты данных. Athena появилась не потому, что кто-то придумал новую концепцию, а потому что команды, работающие над передовыми AI-моделями, попросили придумать способ закрывать уязвимости, которые нельзя разглашать публично.
И вот здесь начинается самое интересное. Поток приватных уязвимостей — это побочный продукт нового метода их поиска с помощью AI. Модель (внутри называют её Mythos) наводят на работающее приложение, дают ей дебаггер, песочницу и исходный код, а потом просят напрямую: «Сломай это». С кодом первого лица модели справляются легко — это же ваш собственный код, вы его владелец. Проблема в том, что реальное приложение почти всегда состоит из открытых зависимостей, часто устаревших. Модель не видит границы между вашим кодом и чужим — она спокойно выстраивает цепочку эксплойта через неподдерживаемую библиотеку, которую никто не сопровождает уже годы. В итоге получается рабочий, живой эксплойт для кода, у которого формально нет владельца. Заряженное оружие, которому некуда идти. Отсюда два свойства новых данных: они приватны, потому что это работающее оружие, и они концентрируются на общих целях, потому что одни и те же несколько десятков библиотек встречаются во множестве разных приложений и моделей. Сами находки редко пересекаются, а вот код, в котором они всплывают, — постоянно.
Скорость атакующих подтверждает срочность. Среднее время до эксплуатации сейчас составляет минус семь дней — то есть в среднем атаки начинаются ещё до того, как патч стал публичным. Раньше этот показатель был больше 60 дней, а через нулевую отметку он прошёл в 2024 году. Цифры подтверждают Mandiant, Google и CrowdStrike. По данным CrowdStrike, 42% эксплуатируемых уязвимостей атакующие используют ещё до публичного раскрытия. Сам опубликованный патч — это карта: диффы прямо указывают на баг. Собственные эксперименты автора показали, что advisory превращается в рабочий эксплойт менее чем за час, даже без публичного proof-of-concept.
Почему большие пулы выигрывают у мелких — здесь работают четыре механизма. Находки кучкуются вокруг одних и тех же нескольких библиотек, и крупный пул полнее покрывает эту общую поверхность атаки. Каждое исправление общей библиотеки защищает сразу всех, кто от неё зависит, — покрытие растёт нелинейно с числом участников. Масштаб даёт рычаг влияния на мейнтейнеров — они охотнее идут на контакт с одной узнаваемой командой безопасности, чем с толпой незнакомцев. И масштаб даёт возможность оркестровать реакцию сразу на нескольких уровнях — только те, кто «в комнате» (CDN, сетевые правила, вендоры безопасности, контент детекции, продакшн-доступ, бэкпорты), способны действовать одновременно. Отдельно стоит заметить: канал, где хранятся неразглашённые эксплойты, сам по себе становится самой лакомой целью во всей экосистеме — защитить его способна только серьёзная, хорошо финансируемая структура. Маленький, тонкий пул — это не облегчённая версия хорошей идеи, это отмычка от всего.
Отсюда логичный вопрос: почему не сделать одну гигантскую палату на всех? Риск монокультуры реален — единый пул с чужими предраскрытыми эксплойтами становится универсальной отмычкой для всего интернета. Австралийский банковский регулятор APRA прямо требует от банков одновременно двигаться со скоростью AI и управлять риском концентрации — задача почти противоречивая сама по себе. Ни одна компания, потратившая пять миллиардов долларов на собственную палату, не станет вливать её в инфраструктуру конкурента. И ни одна страна не станет пускать поток предраскрытых эксплойтов для своей критической инфраструктуры через чужой национальный пул.
Но и десятки мелких палат — не решение. Общий код означает пересекающиеся эмбарго, конкурирующие исправления и ситуацию, когда раскрытие в одном пуле обрушивает защиту, построенную другим. Поверхность переговоров растёт пропорционально квадрату числа палат: несколько штук — это управляемая рабочая группа, десятки — та же фрагментация, от которой все пытались уйти. Правильная модель ближе к тому, как устроена другая критическая инфраструктура доверия — корневые DNS-серверы, крупные облачные провайдеры, сертификационные центры после появления Let's Encrypt. Не одна структура и не тысяча — несколько крупных операторов. При этом палата данных — не облачный провайдер: здесь нет эффекта заложника и привязки к вендору. Перестал доверять — прекратил слать данные и через один период эмбарго перешёл к другому.
Есть ещё контринтуитивный момент. Риск утечки определяется не тем, сколько всего накопилось в базе за всё время, а тем, что именно находится в обороте под эмбарго прямо сейчас. Снижение риска означает не сокращение числа принимаемых находок, а ускорение их обработки. По-настоящему опасная палата — медленная, где скопился хвост необработанных находок, потому что скорость закрытия дыр не успевает за притоком новых. Именно этот накопленный хвост и есть поверхность утечки. Отсюда прямое обязательство: «если наш пул растёт — мы проигрываем». Здоровая палата данных работает в устойчивом состоянии: приток равен оттоку, размер не меняется. Размер пула — это термометр, а не трофей.
Классическая координированная модель раскрытия (CVD) — один исследователь, один мейнтейнер, согласованный график — строилась под медленную эпоху и физически не масштабируется на тысячи одновременных находок. Новая модель называется оркестрованным раскрытием: автоматизация приводит в действие сразу множество контрольных точек — правила WAF, сетевые сигнатуры, бэкпорты, VEX-данные, контент детекции, upstream pull request'ы — так, чтобы все они сработали в момент раскрытия одновременно, как дирижёр, ведущий весь оркестр к одной общей ноте. Показательный пример отсутствия такой оркестровки — история с Log4j. Сам процесс раскрытия и патча там сработал нормально, хаос возник из-за того, что около ста тысяч команд безопасности независимо друг от друга проделывали одну и ту же экстренную работу руками: искали один и тот же класс через grep, писали одинаковые правила WAF, дёргали одинаковые флаги, охотились за скопированными теневыми версиями библиотеки, а потом переделывали всё заново, когда первый патч оказался неполным. Потерянный месяц — не провал раскрытия, а отсутствие слоя оркестрации. Человек всё ещё нужен для переговоров об эмбарго и для того, чтобы устойчивое исправление приняли в апстрим. Всё, что идёт после этой общей ноты, можно и нужно автоматизировать.
Дальше будет ещё много анонсов подобных палат данных, и большинство окажется шумом — сам запуск никогда не был метрикой. Есть простой тест из двух вопросов для оценки любого вендора: какое медианное время от находки до пересобранного, протестированного и подписанного исправления, и какая доля закрывается без участия человека; и сколько из выпущенных фиксов действительно попали в апстрим — в реальный исходный код — а не осели только у прямых клиентов вендора. Находки — это тщеславие. Фикс, до которого никто не может дотянуться, немногим лучше просто найденной проблемы. Настоящая метрика — сколько людей защищено за месяц, считая и прямых клиентов, и всех, кого прикрыло исправление, попавшее выше по течению. Chainguard обещает публиковать эти цифры: медианное время от находки до фикса, долю без ручного вмешательства, долю фиксов, дошедших до апстрима. Ранние показатели, как признаётся автор, «не будут красивыми» — массовый апстриминг в таком масштабе существует всего несколько недель, но публиковать их всё равно нужно: «тест, который сам не готов пройти, — не тест». Серьёзных игроков можно узнать по неоплачиваемой работе — интеграциям, партнёрствам, апстрим pull request'ам, которые строят доверие, а не выручку. Тем, кто думает строить собственную палату данных, стоит сначала спросить себя, есть ли у них «завод» — конвейер fetch/rebuild/test/sign. Без него палата данных — это просто почтовый ящик, который никто не проверяет.
Есть и неопределённость на горизонте: следующее поколение AI-моделей может найти намного больше дыр в уже отсканированном коде. Патчинг уязвимостей — это постоянная беговая дорожка, которая теперь просто разогналась быстрее. Команды безопасности знают правильную гигиену — своевременный патчинг, минимизацию поверхности атаки, актуальность зависимостей — уже лет десять, но редко удерживают её постоянно. Палаты данных — это страховочная сетка под этой дорожкой, возможно она чуть притормаживает бег, но не отменяет саму необходимость бежать. Настоящий выход с дорожки — пересобрать библиотеки, фреймворки и инструменты так, чтобы целые классы уязвимостей стали структурно невозможны, а не просто исправлялись реактивно постфактум. Финальная цель — открытый исходный базовый слой настолько крепкий, что AI-модели остаются с пустыми руками, а сами палаты данных простаивают без работы. Верный признак серьёзных игроков — они гонятся за тем, чтобы сделать себя ненужными. Secure by design было правильным ответом последние тридцать лет, но так и не стало массовой практикой, и никакой гарантии, что получится сейчас, нет. Как формулирует сам автор: «Мы никогда не собирались выигрывать эту гонку скоростью. Это лето clearinghouses не будет длиться вечно. Если мы всё сделаем правильно — оно и не должно.»