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

Введение

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

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

Цель

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

Обнаружение процесса раскрытия информации о безопасности

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

Проектам СЛЕДУЕТ в идеале сделать местоположение заметным, либо создав специальный поддомен наподобие http://security.example.org, либо сделав его каталогом верхнего уровня наподобие http://example.org/security. В качестве альтернативы проекты МОГУТ просто ссылаться на данный документ, то есть PSR-9. Ссылаясь на PSR-9, проект фактически заявляет, что следует процедурам по умолчанию, указанным в разделе «Процедуры по умолчанию» в конце данного документа. Проекты ОБЯЗАНЫ указать переменные, обозначенные в начале этого раздела в данной ссылке (то есть название проекта, домен проекта и т.д.). Проекты МОГУТ перечислить любую часть процедур, не являющуюся ОБЯЗАТЕЛЬНОЙ, которую они решают не включать.

Обратите внимание, что у проектов МОЖЕТ не быть специального домена. Например, проект, размещённый на Github, Bitbucket или другом сервисе, всё равно должен обеспечить, чтобы процесс был указан на лендинговой странице: например, http://github.com/example/somelib должен убедиться, что ветка по умолчанию содержит файл README, в котором указаны применяемые процедуры, чтобы он отображался автоматически.

При необходимости проекты МОГУТ иметь различные процессы раскрытия для разных номеров основных версий. В этом случае ОБЯЗАН быть предоставлен один URL для каждой основной версии. В случае, если основная версия больше не получает исправлений безопасности, вместо URL проект МОЖЕТ просто указать, что версия больше не получает исправлений безопасности.

Процесс раскрытия информации о безопасности

Каждый проект ОБЯЗАН указать адрес электронной почты в описании своего процесса раскрытия информации о безопасности в качестве контактного адреса электронной почты. Проекты НЕ ДОЛЖНЫ использовать контактные формы.

TODO: Добавить больше вещей, найденных здесь https://groups.google.com/d/msg/php-fig-psr-9-discussion/puGV_X0bj_M/Jr_IAS40StsJ?

Процедуры по умолчанию

[project name] обозначает название, которое проект использует для самоидентификации.
[project domain] обозначает главный (под)домен, на который опирается проект.

Если не указано иное, контактный адрес электронной почты — это security@[project domain].

TODO: Добавить больше вещей, упомянутых в предыдущем разделе