CNCF 7 сентября 2026 года опубликовала инструктивную карточку под названием «Работа с сообщениями об уязвимостях» (Handling vulnerability reports: Recipe card), предназначенную для небольших и средних проектов с открытым исходным кодом, которые не сосредоточены главным образом на безопасности. Материал подготовили Marina Moore из Edera, сопредседатель TAG Security, и Sherine Khoury из Red Hat, руководитель TAG Security.
Основная идея руководства заключается в сокращении дополнительной работы для сопровождающих и пользователей и предотвращении превращения сообщения о безопасности в публичное обсуждение до того, как исправление будет готово. CNCF поясняет, что уязвимость — это дефект, который можно использовать для воздействия на конфиденциальность, целостность или доступность системы, однако не каждый программный дефект можно эксплуатировать или классифицировать как уязвимость.
Начните с понятного и частного канала для сообщений
Рекомендации предполагают, что файл README.md должен содержать понятный и легко находящийся раздел о безопасности с инструкциями непосредственно в этом файле или ссылкой на файл SECURITY.md в корне репозитория. Цель — направить исследователей в частный канал вместо публикации сведений о проблеме в общедоступной issue, которую могут прочитать все.
Инструкции по отправке сообщения должны разъяснять несколько элементов, включая модель угроз или минимальные критерии, по которым сообщение считается сообщением об уязвимости, место отправки, формат сообщения, ожидаемый срок до его рассмотрения и примерный срок до раскрытия. Можно использовать механизм частого сообщения об уязвимостях в GitHub или частный почтовый список. Программа вознаграждений не является обязательной для небольших и средних проектов, если у них нет возможности её поддерживать.
Проверьте характер сообщения, прежде чем считать его уязвимостью
После получения сообщения сначала следует определить, действительно ли оно указывает на уязвимость, которую можно эксплуатировать, либо на неэксплуатируемый дефект, неправильное понимание ожидаемого поведения или ошибку в документации. CNCF предлагает обсудить сообщение с его автором и подходящими экспертами проекта, ограничив число участников и сохраняя конфиденциальность до момента, когда сообщение станет публичным.
Среди практических вопросов, которые можно задать: существует ли доступный пользователям механизм снижения риска? Может ли дефект привести к компрометации, утечке данных или другой вредоносной активности? Связана ли проблема только с документацией? Если выяснится, что сообщение не является сообщением об уязвимости, его автора можно направить на создание общедоступной issue, используя при необходимости соответствующие процедуры публикации для информирования пользователей.
В случае неопределённости рекомендации указывают на возможность обратиться за советом к TAG Security and Compliance или сотрудникам CNCF, сохраняя сведения о сообщении вне общедоступных каналов. Участников периода конфиденциального embargo также следует выбирать тщательно и привлекать только тех, кому действительно нужна помощь в устранении проблемы, чтобы сведения не просочились к злоумышленникам до выпуска исправления.
Разработайте и протестируйте исправление вне публичного доступа
CNCF предупреждает, что публикация исправления или его обсуждение в общедоступном pull request может раскрыть характер уязвимости до того, как пользователи получат возможность обновиться. Если используется механизм частых сообщений в GitHub, из сообщения можно создать частную ветку. В противном случае исправление можно разрабатывать и проверять через частный канал.
Исправление необходимо протестировать, даже если обычная среда непрерывной интеграции не работает с частными ветками. В этом случае тесты можно выполнять локально по усмотрению сопровождающих и с учётом масштаба изменения. После подтверждения того, что исправление устраняет проблему и тестов достаточно, рекомендации советуют быстро объединить его, привлекая достаточное число сопровождающих к созданию и тестированию. Перед публичным выпуском следует ещё раз проверить код и убедиться, что уязвимость действительно устранена.
Скоординируйте выпуск с раскрытием CVE
После завершения исправления CNCF считает распространённой практикой раскрытие информации о нём в течение 90 дней с момента получения сообщения. Если ресурсы проекта позволяют, он может заранее уведомить частный список пользователей, однако поддержание актуального списка контактов представляет собой нагрузку, которую большинство небольших проектов не может себе позволить.
Поэтому карточка предлагает более простой подход: одновременно сделать доступным выпуск с исправлением и объявить об уязвимости, чтобы пользователи получили исправление в момент объявления проблемы. Для этого нужно создать новый выпуск сразу после внесения исправления, а затем опубликовать CVE. Если используется частный механизм GitHub, это можно выполнить через интерфейс GitHub.
Номер CVE должна назначить организация CNA, то есть орган нумерации CVE. GitHub является одним из таких органов и может выполнить эту процедуру; проект и исследователь также могут напрямую связаться с одним из перечисленных органов CNA. Степень серьёзности CVE определяется набором вопросов, и проекту следует работать с исследователем, чтобы проверить точность ответов и согласовать присвоенную оценку.
Почему эти рекомендации важны?
На практике карточка переводит ответственность за управление уязвимостью от случайной реакции к выполнимому процессу: частный канал, ограниченная проверка, непубличное исправление, затем согласованные выпуск и раскрытие. После публикации CVE сведения появляются в OSV и других базах данных уязвимостей, что помогает инструментам проверки пользователей обнаружить необходимость обновления.
Однако область применения рецепта чётко ограничена: он предназначен для небольших и средних проектов, не специализирующихся на безопасности, и не заменяет более сложную программу для проектов с высоким уровнем риска или повышенными требованиями безопасности. CNCF также предлагает рассмотреть публикацию подтверждения концепции спустя некоторое время после предоставления исправления, чтобы дать пользователям дополнительную возможность обновиться, признавая, что это может быть трудно реализовать при использовании частого механизма сообщений.