Кратко

  • В снимке официального индекса CVE от 30 октября было 370 записей с датой публикации в 2026 году и девять — в 2025-м. Число опубликованных записей выросло примерно в 41 раз; это не число исправлений и не подсчёт находок ИИ.
  • На RIPE 93 Alistair Woodman ожидал, что за 2026 год EEF опубликует более 500 CVE. Он говорил о дорогой работе после обнаружения: сопровождающим нужно проверить сообщение, исправить код и убедиться, что исправление работает.

Счётчик растёт. Публичного таймера до исправления нет.

На 08:59 UTC 30 октября в машиночитаемом индексе CVE Erlang Ecosystem Foundation было 370 записей с датой публикации в 2026 году и девять — в 2025-м. Это примерно в 41 раз больше опубликованных записей. Индекс не сообщает, сколько затронутых пакетов уже получили проверенное исправление и сколько времени заняла работа сопровождающих.

Свой прогноз Woodman озвучил тремя днями раньше на заседании рабочей группы RIPE 93 по безопасности. По его словам, EEF охватывает более 20 000 пакетов Elixir, Erlang и Gleam. Он оценил число постоянных пользователей примерно в 100 000, а число известных фонду корпоративных пользователей — как минимум в 5 000. За предыдущий год команда насчитала около десяти CVE; на 2026-й Woodman ожидал более 500. Он назвал это ростом нагрузки более чем в 50 раз и пояснил, что уязвимости существовали и раньше: анализ с помощью ИИ лишь облегчил их поиск.

EEF выступает органом нумерации CVE. Её группа безопасности назначает идентификаторы и координирует раскрытие для проектов, входящих в область её работы. Woodman описал команду из пяти основных участников: двое выполняют большую часть работы с CVE и исследованиями с ИИ. Инструмент может быстро подсветить проблему. Но сопровождающему всё равно нужно выяснить, действительно ли сообщение указывает на уязвимость, изменить код, выпустить новую версию и проверить результат.

Именно здесь количество записей перестаёт быть показателем результата безопасности. По словам Woodman, EEF пробует группировать сообщения по проектам. Вместо того чтобы отвлекать сопровождающего при каждом новом отчёте, команда выделяет время на разбор сразу нескольких проблем. Это попытка решить задачу ограниченных человеческих ресурсов: поиск можно распараллелить, а исправление остаётся за людьми, которые знают код конкретного проекта.

Опубликованная политика EEF обещает подтвердить получение сообщения в течение двух рабочих дней, а оценить его — в течение двух рабочих дней после подтверждения. Если по непубличной уязвимости в пакете Hex из области работы CNA сопровождающий не отвечает 14 дней, организация указывает, что переходит к публикации. Согласованное раскрытие может длиться до трёх месяцев. Эти правила задают сроки приёма и раскрытия, но не измеряют путь от обнаружения до выпуска исправленной версии.

Индекс EEF хранит идентификатор CVE, заголовок, описание, дату публикации и дату обновления. В открытых данных нет ответа сопровождающего, номера исправленной версии или времени проверки исправления для каждой записи. Публичная связь между сообщением и проверенным релизом показала бы, сокращает ли рост раскрытий время, в течение которого пользователи остаются уязвимы.

Woodman входит в совет EEF и просил компании, использующие эту экосистему, помочь финансировать работу по безопасности. Причина проста: тысячам организаций нужны открытые пакеты, тогда как значительная часть работы по поиску и обработке CVE ложится на небольшую группу людей. Опубликованная CVE предупреждает о проблеме. Следующее полезное число — срок до версии, которая её исправляет.

Источники: сессия RIPE 93; официальная стенограмма; страницы EEF о CNA, области работы, политике безопасности и индексе CVE; совет EEF.