Сведения о помощниках по безопасности репозитория
Дополнительные сведения см. в разделе Сведения о скоординированном раскрытии информации об уязвимостях безопасности.
Рекомендации по безопасности репозитория позволяют поддерживать общедоступные репозитории для частного обсуждения и устранения уязвимости безопасности в проекте. После совместной работы над исправлением разработчики репозиториев могут публиковать рекомендации по безопасности, чтобы сообщить об уязвимости системы безопасности сообществу проекта. Публикуя рекомендации по безопасности, разработчики репозитория упрощают для сообщества обновление зависимостей пакетов и ознакомление с последствиями уязвимостей системы безопасности.
С помощью помощников по безопасности репозитория можно:
- Создать черновик рекомендации по безопасности и с его помощью в частном порядке обсудить влияние уязвимости на проект.
- Осуществляйте закрытую совместную работу для устранения уязвимости во временной частной вилке.
- Опубликовать рекомендацию по безопасности, чтобы уведомить сообщество об уязвимости после выпуска исправления.
Вы также можете использовать рекомендации по безопасности репозитория для повторной публикации сведений об уязвимости безопасности, которую вы уже раскрыли в другом месте, скопировав и вставив сведения об уязвимости в новый совет по безопасности.
Вы можете поблагодарить лиц, которые внесли свой вклад в создание рекомендации по безопасности. Дополнительные сведения см. в разделе Изменение рекомендаций по безопасности репозитория.
Вы можете создать политику безопасности, чтобы предоставить пользователям инструкции о том, как сообщать об уязвимостях системы безопасности в проекте. Дополнительные сведения см. в разделе Добавление политики безопасности в репозиторий.
Если вы создали рекомендацию по безопасности в репозитории, она останется в репозитории. Мы публикуем рекомендации по безопасности для всех экосистем, поддерживаемых схемой зависимостей, в GitHub Advisory Database в github.com/advisories. Любой пользователь может отправить изменение для рекомендации, опубликованной в GitHub Advisory Database. Дополнительные сведения см. в разделе Изменение рекомендаций по безопасности в базе данных рекомендаций по GitHub.
Если рекомендация по безопасности относится к npm, мы также опубликуем ее в рекомендациях по безопасности для npm. Дополнительные сведения см. в разделе npmjs.com/advisories.
Вы также можете присоединить GitHub Security Lab для просмотра тем, связанных с безопасностью, и внести свой вклад в средства безопасности и проекты.
Идентификационные номера CVE
GitHub Security Advisories основаны на списке распространенных уязвимостей (CVE). Форма рекомендаций по безопасности для GitHub — это стандартная форма, соответствующая формату описания CVE.
GitHub — это центр нумерации CVE (CNA), которому разрешено назначать идентификационные номера CVE. Дополнительные сведения см. в разделе ["Сведения о центрах нумерирования CVE и ](https://www.cve.org/ProgramOrganization/CNAs)CVE" на веб-сайте CVE.
При создании рекомендации по безопасности для общедоступного репозитория в GitHub для уязвимости безопасности можно указать существующий идентификационный номер CVE. Если вы хотите получить идентификационный номер CVE для уязвимости системы безопасности вашего проекта, и у вас его еще нет, то можно запросить идентификационный номер CVE в GitHub. Обычно GitHub проверяет запрос в течение 72 часов. Запрос идентификационного номера CVE не делает ваши рекомендации по безопасности общедоступными. Если ваша рекомендация по безопасности имеет разрешение на CVE, GitHub зарезервирует идентификационный номер CVE для вашей рекомендации. Затем мы опубликуем сведения о CVE после того, как ваши рекомендации по безопасности станут общедоступными. Любой пользователь с разрешениями администратора для рекомендаций по безопасности может запросить идентификационный номер CVE.
Если у вас уже есть номер CVE, который вы хотите использовать, например, в случае использования центра нумерации CVE (CNA), отличающегося от GitHub, добавьте номер CVE в форму рекомендаций по безопасности. Например, это может произойти, если вы хотите настроить рекомендации по безопасности в соответствии с другими взаимодействиями, которые планируете отправить во время публикации. GitHub не может назначать номера CVE проекту, если он охватывается другой CNA.
Когда мы опубликуем рекомендацию по безопасности и GitHub присвоит уязвимости идентификационный номер CVE, GitHub опубликует CVE в базе данных MITRE.
Публикация уведомлений по безопасности
Публикация предупреждения по безопасности уведомляет ваше сообщество о уязвимости, которую оно устраняет, облегчая им обновление зависимостей пакетов и исследование её влияния.
Когда вы публикуете черновик предупреждения из публичного репозитория, уровень видимости варьируется следующим образом:
-
**Любой** может увидеть текущую версию данных рекомендаций, а также любые кредиты, которые приняли указанные пользователями. -
**Сотрудники** могут просматривать историю разговоров в консультации.
URL уведомления о безопасности не меняется после публикации.
Если вам нужно обновить или исправить сведения в опубликованной рекомендации по безопасности, ее можно отредактировать. См . раздел AUTOTITLE.
Dependabot alerts для опубликованных рекомендаций по безопасности
GitHub проверяет каждую опубликованную рекомендацию по безопасности, добавляет ее в GitHub Advisory Database и может использовать ее для отправки Dependabot alerts в затронутые репозитории. Если рекомендация по безопасности поступает из вилки, мы отправим оповещение только в том случае, если пакет принадлежит вилке и опубликован под уникальным именем в общедоступном реестре пакетов. Этот процесс может занять до 72 часов, и с GitHub может поступить запрос дополнительных сведений.
Значение фикс-версий
По возможности следует добавить исправленную версию в предупреждение по безопасности перед его публикацией. Если этого не сделать, рекомендация будет опубликована без исправленной версии, и Dependabot оповестит пользователей о проблеме, не предоставив им безопасную версию для обновления.
В зависимости от уязвимости, возможно, придётся корректировать подход. Если фиксированная версия такова:
-
**Это скоро доступно**, и вы можете подождать, чтобы сообщить о проблеме, когда исправление будет готово. -
**В разработке, но пока недоступно**, укажите об этом в рекомендации и отредактируйте его позже, после публикации. -
**Это не планируется**, но уточните это в уведомлении, чтобы пользователи не связывались с вами с вопросом, когда будет внесена поправка. В этом случае полезно указать шаги, которые пользователи могут предпринять для устранения проблемы.