Как раскрывается информация об уязвимостях в отрасли
Раскрытие уязвимостей — это область, в которой очень важно сотрудничество между специалистами, сообщающими об уязвимостях, такими как исследователи по безопасности и специалисты по поддержке проектов. Обе стороны должны работать как одна команда с того момента, когда обнаружена потенциально вредная уязвимость безопасности, и до тех пор, пока уязвимость не будет раскрыта миру (в идеале — с доступным исправлением). Как правило, когда кто-то сообщает специалисту-специалисту об уязвимости системы безопасности в частном порядке, специалист по поддержке разрабатывает исправление, проверяет его и уведомляет пользователей о проекте или пакете.
Первоначальное сообщение об уязвимости делается в частном порядке, и все сведения публикуются только после того, как координатор подтвердил проблему и, в идеале, предоставил исправления. Иногда выдерживается пауза, которая дает время на установку исправлений. Дополнительные сведения см. в статье о раскрытии уязвимостей на сайте памяток по OWASP.
Рекомендации по предоставлению отчетов об уязвимостях
Рекомендуется сообщать об уязвимостях координаторам в частном порядке. Если вы являетесь информирующим об уязвимости:
- не сообщайте о ней публично, дайте координаторам возможность ее исправить;
- не действуйте в обход координаторов;
- не сообщайте об уязвимости до появления исправленной версии кода;
- не ожидайте вознаграждения за сообщение о проблеме, если она не подпадает под действие общедоступной программы поощрений.
Информирующие об уязвимостях могут раскрывать информацию через определенное время, если до этого они пытались связаться с координаторами и не получили ответа либо их попросили не раскрывать эту информацию слишком долго.
Мы рекомендуем информирующим об уязвимостях четко указывать условия своей политики раскрытия информации. Даже если информирующий об уязвимости не придерживается строгих правил, рекомендуется сообщить координаторам четкие сроки предполагаемого раскрытия сведений об уязвимостях. Пример политики раскрытия информации см. в разделе "Политика раскрытия информации лаборатории безопасности" на веб-сайте лаборатории безопасности GitHub.
Рекомендации для координаторов
Если вы — координатор, четко укажите, как и где вы хотите получать отчеты об уязвимостях. Если эта информация недоступна, информирующие об уязвимостях не будут знать, как связаться с вами, и могут искать адреса электронной почты разработчиков в журналах фиксаций Git с целью выйти на контактное лицо по безопасности. Это может приводить к конфликтам, потере отчетов или публикации отчетов по неисправленным проблемам.
Координаторы должны своевременно сообщать об уязвимостях. Если в вашем репозитории есть уязвимость безопасности:
- рассматривайте уязвимость как проблему безопасности, а не простую ошибку, и в ответе, и в раскрытии информации. Например, явно укажите, что проблема является уязвимостью безопасности в заметках о выпуске;
- подтверждайте получение отчета об уязвимостях как можно быстрее, даже если у вас нет доступных специалистов, которые взялись бы за ее исследование. Этим вы заявляете, что быстро реагируете на проблемы, а также задаете положительный тон для дальнейшего общения с информирующим об уязвимости;
- при оценке влияния и достоверности отчета привлекайте информирующего об уязвимости. Скорее всего, этот человек уже рассматривал уязвимость в различных сценариях, и среди них могут быть те, которые вы не учитывали;
- исправьте проблему по своему усмотрению, внимательно прислушиваясь к замечаниям и советам от информирующего об уязвимости; Зачастую этот человек знает о крайних случаях и обходных решениях, которые легко не заметить, не имея опыта в области информационной безопасности.
- при раскрытии информации всегда благодарите информирующего об уязвимости;
- старайтесь публиковать исправления как можно скорее;
- При раскрытии сведений об уязвимости старайтесь сообщить о проблеме и ее решении как можно более широкому кругу лиц. Зачастую бывает так, что признанная проблема безопасности устраняется в текущей ветви разработки проекта, однако фиксация или последующий выпуск не имеют явной отметки о том, что это исправление или выпуск, устраняющие проблемы безопасности. Это может привести к проблемам для нижестоящих пользователей.
Публикация сведений об уязвимости безопасности не выставляет координатора в дурном свете. Такие проблемы в программном обеспечении повсеместны, и пользователи будут доверять координаторам, у которых есть четкий и отработанный процесс по раскрытию информации об уязвимостях безопасности в коде.
Сведения о раскрытии информации об уязвимостях в проектах на GitHub
Существует два процесса, доступных для GitHub:
- Стандартный процесс: репортеры уязвимостей обращаются к ответственный за репозиторий, используя контактные данные, расположенные в политике безопасности репозитория. При необходимости ответственный за репозиторий создайте черновик рекомендаций по репозиторию.
- Отчеты о частных уязвимостях: репортеры уязвимостей раскрывают сведения об уязвимостях напрямую и в частном порядке в ответственный за репозиторий, предлагая проект рекомендаций по репозиторию и предоставляя подробные сведения о своих результатах.
Стандартный процесс
Процесс создания отчетов и раскрытия уязвимостей для проектов на GitHub выглядит следующим образом:
Если вы являетесь информирующим об уязвимости (например, аналитиком в области безопасности) и хотите сообщить об уязвимости, сначала проверьте наличие политики безопасности для связанного репозитория. Дополнительные сведения см. в разделе Добавление политики безопасности в репозиторий. При наличии такой политики следуйте содержащимся в ней инструкциям перед тем, как обращаться в группу безопасности этого репозитория.
Если политика безопасности отсутствует, то установите закрытый канал связи с координаторами. Для этого создайте проблему, в которой укажите запрос на помощь предпочтительного контактного лица по вопросам безопасности. Стоит отметить, что эта проблема будет общедоступна, поэтому в ней не должно быть информации об ошибке. После установления связи вы можете предложить координаторам сформулировать политику безопасности на будущее.
Note
Только для npm — если мы получаем отчет о вредоносных программах в пакете npm, мы пытаемся связаться с вами в частном порядке. Если вы своевременно не решите проблему, мы ее раскрываем. Дополнительные сведения см. в разделе "Создание отчетов о вредоносных программах в пакете npm" на веб-сайте документации npm.
Если вы обнаружили уязвимость безопасности в GitHub, сообщите об уязвимости через наш согласованный процесс раскрытия. Дополнительные сведения см. на веб-сайте bounty ошибки безопасности GitHub.
Если вы являетесь координатором, то можете взять на себя ответственность за процесс с самого начала, настроив политику безопасности для репозитория или предоставив доступ к инструкциям по отчетам о безопасности, например в файле README проекта. Сведения о добавлении политики безопасности см. в разделе "Добавление политики безопасности в репозиторий". Если политика безопасности отсутствует, скорее всего, информирующий об уязвимости попытается отправить вам письмо по электронной почте или иным образом связаться с вами в частном порядке. Либо кто-то может открыть (общедоступную) проблему с подробными сведениями о проблеме безопасности.
При раскрытии уязвимости в своем коде вы, как координатор, сначала создадите черновик рекомендаций по безопасности в репозитории пакета в GitHub. Рекомендации по безопасности репозитория позволяют поддерживать общедоступные репозитории для частного обсуждения и устранения уязвимости безопасности в проекте. После совместной работы над исправлением разработчики репозиториев могут публиковать рекомендации по безопасности, чтобы сообщить об уязвимости системы безопасности сообществу проекта. Публикуя рекомендации по безопасности, разработчики репозитория упрощают для сообщества обновление зависимостей пакетов и ознакомление с последствиями уязвимостей системы безопасности. Дополнительные сведения см. в разделе "Сведения о помощниках по безопасности репозитория".
Сведения о начале работы см. в разделе "Создание рекомендаций по безопасности репозитория".
Отчеты о частных уязвимостях
Владельцы и администраторы общедоступных репозиториев могут включать отчеты о частных уязвимостях в своих репозиториях. Дополнительные сведения см. в разделе Настройка отчетов о частных уязвимостях для репозитория.
Отчеты о частных уязвимостях позволяют журналистам уязвимостей в частном порядке раскрывать риски безопасности для ответственный за репозиторий, в GitHub, и таким образом, чтобы немедленно уведомлять ответственный за репозиторий проблемы. Дополнительные сведения для исследователей и ответственный за репозиторий безопасности см. в разделе "[AUTOTITLE" и "Приватный отчет об уязвимости безопасности](/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/managing-privately-reported-security-vulnerabilities)" соответственно.
Note
Если репозиторий, содержащий уязвимость, не включает отчеты о частных уязвимостях, исследователи безопасности и ответственный за репозиторий должны следовать инструкциям, описанным в разделе "Стандартный процесс" выше.