Политика раскрытия уязвимостей

Кратко

Эта страница определяет политику скоординированного раскрытия уязвимостей NextPDF. Здесь описано, как связаться с сопровождающими через закрытые каналы, каких сроков ответа ожидать и как применяется эмбарго.

Границы. Политика раскрытия — это обязательство соблюдать процесс, а не гарантия сроков или результата. Указанные ниже целевые сроки — это добросовестно принятые обязательства сопровождающих перед вами как перед сообщающим; они описывают процесс, которому следует проект, а не договорное обещание, что конкретное сообщение будет подтверждено, рассмотрено, исправлено или раскрыто к конкретной дате. Сроки скоординированного раскрытия согласуются, а не гарантируются в одностороннем порядке.

Установка

Неприменимо. Чтобы сообщить об уязвимости, ничего устанавливать не нужно. Машиночитаемые контактные данные опубликованы по адресу /.well-known/security.txt (Request for Comments (RFC) 9116). Файл SECURITY.md в репозитории — это авторитетная политика в человекочитаемом виде.

Концептуальный обзор

Эта политика реализует скоординированное раскрытие уязвимостей в соответствии с ISO/IEC 29147 и процессом обработки, описанным в ISO/IEC 30111 (iso_iec_30111#x9.x43.p2): закрытый приём, рассмотрение и оценка серьёзности, устранение под эмбарго и скоординированная публичная публикация. Если уязвимость затрагивает несколько поставщиков, затронутые стороны согласуют сроки публикации бюллетеня, а не устанавливают их в одностороннем порядке (iso_iec_29147#x3.x110.p13).

Этот процесс также согласуется с обязательствами производителя по обработке уязвимостей, предусмотренными Актом Европейского союза (EU) о киберустойчивости (Cyber Resilience Act, CRA) (eu_cra#x1.p191), и с практикой “реагирования на уязвимости” в Secure Software Development Framework (SSDF) Национального института стандартов и технологий (NIST) (nist_sp_800_218#x15). Оба документа описывают соответствующие обязанности как воспроизводимый процесс, а не как гарантию достижения конкретного результата.

Состав API

Неприменимо. Раскрытие — это процесс, а не программный интерфейс приложения (API). Машиночитаемые данные для обнаружения предоставляет файл security.txt, определённый в RFC 9116; инструменты считывают его поля Contact: и Expires:. Эта страница не дублирует содержимое этого файла, кроме перечисленных ниже каналов.

Пример кода — быстрый старт

Неприменимо. При сообщении об уязвимости нет кода, который нужно запускать. Используйте закрытый канал:

• GitHub Security Advisories (предпочтительно: шифрование при хранении, журнал аудита): создайте черновик бюллетеня на вкладке GitHub Security проекта.
• Электронная почта: [email protected] с [SECURITY] в теме письма. Если вам нужно сквозное шифрование, а опубликованный ключ OpenPGP ещё не указан в security.txt, используйте вместо этого канал GitHub Security Advisory.

Сообщайте об уязвимостях не через публичные issue, публичные списки рассылки, социальные сети или чат. Публичное раскрытие до выпуска исправления подвергает риску пользователей версий без патча.

Пример кода — рабочая среда

Неприменимо.

Граничные случаи и подводные камни

• Целевые сроки — это обязательства, а не соглашения об уровне обслуживания (SLA). Приведённый ниже график показывает, к чему стремится проект. Сложная многокомпонентная проблема или проблема, требующая согласования с вышестоящими проектами, может занять больше времени; проект держит сообщающего в курсе.
• Длительность эмбарго обсуждаема, но имеет верхний предел. Эмбарго по умолчанию действует с момента рассмотрения до выпуска исправления. Если вам нужно больше времени, запросите его явно при создании бюллетеня. По истечении максимального срока проект опубликует бюллетень независимо от того, доступно исправление или нет, в соответствии с отраслевыми нормами скоординированного раскрытия. Это защищает пользователей от бесконечного откладывания бюллетеня.
• График определяется серьёзностью. Критическая, активно эксплуатируемая проблема обрабатывается по сжатому графику; предложение по усилению защиты с низкой серьёзностью — нет. Серьёзность оценивается при рассмотрении и может быть пересмотрена.
• Присвоение идентификатора Common Vulnerabilities and Exposures (CVE) входит в этап рассмотрения. Сопровождающий запрашивает CVE через регистрацию проекта в качестве CVE Numbering Authority (CNA) в GitHub Security Advisory на этапе рассмотрения; сообщающему не нужно запрашивать его отдельно.

Производительность

Неприменимо.

Примечания по безопасности

Целевые сроки ответа — это обязательства перед сообщающими, которые задают базовый уровень обработки уязвимостей в проекте. Это целевые сроки, а не гарантии:

Этап	Целевой срок
Подтверждение получения	в течение 1–2 рабочих дней
Первичное рассмотрение + оценка серьёзности	в течение ~5 рабочих дней / 7 календарных дней
Разработка исправления + закрытое рецензирование	обычно 14 рабочих дней; 30–90 дней для сложных подтверждённых CVE в зависимости от серьёзности
Присвоение CVE (если принято)	вместе с исправлением, через канал GitHub CNA
Скоординированное публичное раскрытие	при выпуске исправления, в дату, согласованную совместно с сообщающим
Эмбарго (от рассмотрения до выпуска)	по умолчанию ~90 дней, сокращается при активной эксплуатации, продлевается по явному запросу до фиксированного максимума

Рецензенты могут проверить соблюдение этих правил процесса:

1. Сначала закрыто. Публичные каналы для сообщений не принимаются. Принимаются только два канала: GitHub Security Advisory и электронная почта безопасности.
2. Скоординированно, а не в одностороннем порядке. Сроки раскрытия согласуются с сообщающим и всеми совместно затронутыми поставщиками (iso_iec_29147#x3.x110.p13).
3. Ограниченное эмбарго. У эмбарго есть значение по умолчанию и жёсткий верхний предел; проект не откладывает бюллетень бесконечно.
4. Упоминание по запросу. Исследователи упоминаются после снятия эмбарго, если они не попросили об анонимности.

Эти положения описывают процесс, которому проект обязуется следовать. Они не гарантируют, что то или иное сообщение приведёт к исправлению, выдаче CVE или раскрытию к определённой дате.

Соответствие

Это не профиль соответствия. Эта политика согласуется с ISO/IEC 29147, ISO/IEC 30111, а также с процессными обязанностями CRA и SSDF, указанными выше; формулировка “согласуется с” выбрана намеренно. Проект не заявляет о сертификации по какой-либо из этих схем. Они определяют надёжный процесс; эта страница документирует обязательство проекта применять такой процесс.

См. также

• Центр доверия
• Модель угроз движка
• Модель безопасности подписи и шифрования
• Файл SECURITY.md в репозитории и /.well-known/security.txt (RFC 9116)