Skip to main content
Мы публикуем частые обновления нашей документации, и перевод этой страницы может все еще выполняться. Актуальные сведения см. в документации на английском языке.

Сведения о скоординированном раскрытии информации об уязвимостях безопасности

Раскрытие информации об уязвимостях требует скоординированной работы специалистов по безопасности и специалистами по обслуживанию репозиториев.

Как раскрывается информация об уязвимостях в отрасли

Раскрытие уязвимостей — это область, в которой очень важно сотрудничество между специалистами, сообщающими об уязвимостях, такими как исследователи по безопасности и специалисты по поддержке проектов. Обе стороны должны работать как одна команда с того момента, когда обнаружена потенциально вредная уязвимость безопасности, и до тех пор, пока уязвимость не будет раскрыта миру (в идеале — с доступным исправлением). Как правило, когда кто-то сообщает специалисту-специалисту об уязвимости системы безопасности в частном порядке, специалист по поддержке разрабатывает исправление, проверяет его и уведомляет пользователей о проекте или пакете.

Первоначальное сообщение об уязвимости делается в частном порядке, и все сведения публикуются только после того, как координатор подтвердил проблему и, в идеале, предоставил исправления. Иногда выдерживается пауза, которая дает время на установку исправлений. Дополнительные сведения см. в статье о раскрытии уязвимостей на сайте памяток по OWASP.

Рекомендации по предоставлению отчетов об уязвимостях

Рекомендуется сообщать об уязвимостях координаторам в частном порядке. Если вы являетесь информирующим об уязвимости:

  • не сообщайте о ней публично, дайте координаторам возможность ее исправить;
  • не действуйте в обход координаторов;
  • не сообщайте об уязвимости до появления исправленной версии кода;
  • не ожидайте вознаграждения за сообщение о проблеме, если она не подпадает под действие общедоступной программы поощрений.

Информирующие об уязвимостях могут раскрывать информацию через определенное время, если до этого они пытались связаться с координаторами и не получили ответа либо их попросили не раскрывать эту информацию слишком долго.

Мы рекомендуем информирующим об уязвимостях четко указывать условия своей политики раскрытия информации. Даже если информирующий об уязвимости не придерживается строгих правил, рекомендуется сообщить координаторам четкие сроки предполагаемого раскрытия сведений об уязвимостях. Пример политики раскрытия информации см. в разделе "Политика раскрытия информации лаборатории безопасности" на веб-сайте лаборатории безопасности GitHub.

Рекомендации для координаторов

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

Координаторы должны своевременно сообщать об уязвимостях. Если в вашем репозитории есть уязвимость безопасности:

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

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

Сведения о раскрытии информации об уязвимостях в проектах на GitHub

В GitHubдоступны два процесса:

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

Стандартный процесс

Процесс создания отчетов и раскрытия информации об уязвимостях для проектов на GitHub.com выглядит следующим образом:

Если вы являетесь информирующим об уязвимости (например, аналитиком в области безопасности) и хотите сообщить об уязвимости, сначала проверьте наличие политики безопасности для связанного репозитория. Дополнительные сведения см. в разделе Добавление политики безопасности в репозиторий. При наличии такой политики следуйте содержащимся в ней инструкциям перед тем, как обращаться в группу безопасности этого репозитория.

Если политика безопасности отсутствует, то установите закрытый канал связи с координаторами. Для этого создайте проблему, в которой укажите запрос на помощь предпочтительного контактного лица по вопросам безопасности. Стоит отметить, что эта проблема будет общедоступна, поэтому в ней не должно быть информации об ошибке. После установления связи вы можете предложить координаторам сформулировать политику безопасности на будущее.

Примечание. Только для npm — если мы получаем отчет о вредоносных программах в пакете npm, мы пытаемся связаться с вами в частном порядке. Если вы своевременно не решите проблему, мы ее раскрываем. Дополнительные сведения см. в разделе "Создание отчетов о вредоносных программах в пакете npm" на веб-сайте документации npm.

Если вы обнаружили уязвимость безопасности в GitHub.com, сообщите о ней с помощью нашего скоординированного процесса раскрытия. Дополнительные сведения см. на веб-сайте bounty ошибки безопасности GitHub.

Если вы являетесь координатором, то можете взять на себя ответственность за процесс с самого начала, настроив политику безопасности для репозитория или предоставив доступ к инструкциям по отчетам о безопасности, например в файле README проекта. Сведения о добавлении политики безопасности см. в разделе Добавление политики безопасности в репозиторий. Если политика безопасности отсутствует, скорее всего, информирующий об уязвимости попытается отправить вам письмо по электронной почте или иным образом связаться с вами в частном порядке. Либо кто-то может открыть (общедоступную) проблему с подробными сведениями о проблеме безопасности.

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

Чтобы приступить к работе, см. раздел Создание рекомендаций по безопасности репозитория.

Частные отчеты об уязвимостях

Владельцы и администраторы общедоступных репозиториев могут включить частные отчеты об уязвимостях в своих репозиториях. Дополнительные сведения см. в разделе Настройка частных отчетов об уязвимостях для репозитория.

Частные отчеты об уязвимостях обеспечивают простой способ для отчетов об уязвимостях в частном порядке сообщать о рисках безопасности для ведения репозитория в GitHub и таким образом, чтобы немедленно уведомлять поддержку репозитория о проблеме. Дополнительные сведения для исследователей безопасности и поддержку репозитория см. в разделах Конфиденциальное сообщение об уязвимости системы безопасности и Управление обнаруженными в частном порядке уязвимостями системы безопасности соответственно.

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