Skip to content

Спецификация

Введение

Работа с вопросами безопасности имеет два аспекта: один — это процесс, посредством которого проблемы безопасности сообщаются и устраняются в проектах, другой — то, как широкая общественность информируется о проблемах и доступных способах их устранения. В то время как PSR-9 касается первого, данный PSR, то есть PSR-10, рассматривает второй. Таким образом, цель PSR-10 — определить, как проблемы безопасности раскрываются публично и какому формату должны следовать такие раскрытия. Особенно сегодня, когда PHP-разработчики обмениваются кодом между проектами более активно, чем когда-либо, данный PSR призван упростить задачу отслеживания проблем безопасности во всех зависимостях и шагов, необходимых для их устранения.

Ключевые слова «ОБЯЗАН», «НЕ ДОЛЖЕН», «REQUIRED», «SHALL», «SHALL NOT», «СЛЕДУЕТ», «SHOULD NOT», «RECOMMENDED», «МОЖЕТ» и «OPTIONAL» в данном документе следует интерпретировать так, как описано в RFC 2119.

Цель

Цель данного PSR — предоставить руководителям проектов чётко определённый подход к обеспечению возможности конечным пользователям обнаруживать раскрытия уязвимостей безопасности, используя чётко определённый структурированный формат для таких раскрытий.

Обнаружение раскрытий

Каждый проект ОБЯЗАН предоставить ссылку на свою базу данных уязвимостей безопасности в очевидном месте. В идеале это должно быть на корневой странице главного домена соответствующего проекта. Это МОЖЕТ быть поддомен в случае, если проект является частью более крупной инициативы. Если у проекта есть специальная страница для обнаружения процесса раскрытия, она также считается подходящим местом для этой ссылки. Ссылка МОЖЕТ использовать пользовательское отношение php-vuln-disclosures, например: <link rel="php-vuln-disclosures" href="http://example.org/disclosures"/>.

Обратите внимание, что проекты МОГУТ хранить файлы раскрытий на домене, отличном от главной страницы проекта. РЕКОМЕНДУЕТСЯ не хранить раскрытия в VCS, поскольку это может вызвать путаницу относительно того, какая ветка является актуальной. Если VCS используется, СЛЕДУЕТ предпринять дополнительные шаги для чёткого документирования для пользователей того, в какой ветке содержатся все уязвимости для всех версий. При необходимости проекты однако МОГУТ разделять файлы раскрытия уязвимостей по номерам основных версий. В этом случае это СЛЕДУЕТ чётко задокументировать.

Формат раскрытия

Формат раскрытия основан на Atom [1], который в свою очередь основан на XML. В нём используется «The Common Vulnerability Reporting Framework (CVRF) v1.1» [2]. В частности, для базовой терминологии применяется его словарь [3].

TODO: Следует ли также предоставить JSON-сериализацию для снижения порога вхождения для проектов. Службы агрегации могут затем появиться для предоставления представления Atom этих раскрытий в формате JSON.

Расширения Atom [4] позволяют дать структурированное описание уязвимости, чтобы автоматизированные инструменты могли определить, вероятно ли затронута установленная система данной уязвимостью. Однако удобочитаемость для человека считается крайне важной, поэтому полный CVRF не используется.

TODO: Пересмотреть формат Atom и предоставленный XSD

Обратите внимание, что для каждой уязвимости ОБЯЗАНА быть создана только одна запись. В случае изменения любой информации исходный файл ОБЯЗАН быть обновлён вместе с полем последнего обновления.

Каждое раскрытие использует entryType со следующими тегами из пространства имён Atom (обязательные теги помечены «ОБЯЗАН»):

  • title (краткое описание уязвимости и затронутых версий, ОБЯЗАН)
  • summary (описание уязвимости)
  • author (контактная информация, ОБЯЗАН)
  • published (дата первоначальной публикации, ОБЯЗАН)
  • updated (дата последнего обновления)
  • link (ссылка для получения дополнительной информации)
  • id (идентификатор уязвимости, специфичный для проекта)

Кроме того, добавлены следующие теги:

  • reported (дата первоначального сообщения)
  • reportedBy (контактная информация лиц или организации, первоначально сообщивших об уязвимости)
  • resolvedBy (контактная информация лиц или организации, устранившей уязвимость)
  • name (название продукта, ОБЯЗАН)
  • cve (уникальный идентификатор CVE)
  • cwe (уникальный идентификатор CWE)
  • severity (низкая, средняя, высокая)
  • affected (версия(и) с использованием синтаксиса composer [5])
  • status (открыта, в работе, оспаривается, завершена, ОБЯЗАН)
  • remediation (текстовое описание способа устранения проблемы в затронутой системе)
  • remediationType (обходное решение, смягчение, исправление поставщика, нет доступного, не будет исправлено)
  • remediationLink (URL для получения дополнительной информации об устранении)

[1] https://tools.ietf.org/html/rfc4287 [2] http://www.icasi.org/cvrf-1.1 [3] http://www.icasi.org/cvrf-1.1-dictionary [4] security-disclosure-publication.xsd [5] https://getcomposer.org/doc/01-basic-usage.md#package-versions