Как раскрывается информация об уязвимостях в отрасли
Раскрытие уязвимостей — это область, в которой очень важно сотрудничество между специалистами, сообщающими об уязвимостях, такими как исследователи по безопасности и специалисты по поддержке проектов. Обе стороны должны работать как одна команда с того момента, когда обнаружена потенциально вредная уязвимость безопасности, и до тех пор, пока уязвимость не будет раскрыта миру (в идеале — с доступным исправлением). Как правило, когда кто-то сообщает специалисту-специалисту об уязвимости системы безопасности в частном порядке, специалист по поддержке разрабатывает исправление, проверяет его и уведомляет пользователей о проекте или пакете.
Первоначальное сообщение об уязвимости делается в частном порядке, и все сведения публикуются только после того, как координатор подтвердил проблему и, в идеале, предоставил исправления. Иногда выдерживается пауза, которая дает время на установку исправлений. Дополнительные сведения см. в серии памяток OWASP о раскрытии уязвимостей на веб-сайте серии памяток OWASP.
Рекомендации по предоставлению отчетов об уязвимостях
Рекомендуется сообщать об уязвимостях координаторам в частном порядке. Если вы являетесь информирующим об уязвимости:
- не сообщайте о ней публично, дайте координаторам возможность ее исправить;
- не действуйте в обход координаторов;
- не сообщайте об уязвимости до появления исправленной версии кода;
- не ожидайте вознаграждения за сообщение о проблеме, если она не подпадает под действие общедоступной программы поощрений.
Информирующие об уязвимостях могут раскрывать информацию через определенное время, если до этого они пытались связаться с координаторами и не получили ответа либо их попросили не раскрывать эту информацию слишком долго.
Мы рекомендуем информирующим об уязвимостях четко указывать условия своей политики раскрытия информации. Даже если информирующий об уязвимости не придерживается строгих правил, рекомендуется сообщить координаторам четкие сроки предполагаемого раскрытия сведений об уязвимостях. Для примера политики раскрытия информации см. политику раскрытия Security Lab на сайте GitHub Security Lab.
Рекомендации для координаторов
Если вы — координатор, четко укажите, как и где вы хотите получать отчеты об уязвимостях. Если эта информация недоступна, информирующие об уязвимостях не будут знать, как связаться с вами, и могут искать адреса электронной почты разработчиков в журналах фиксаций Git с целью выйти на контактное лицо по безопасности. Это может приводить к конфликтам, потере отчетов или публикации отчетов по неисправленным проблемам.
Координаторы должны своевременно сообщать об уязвимостях. Если в вашем репозитории есть уязвимость безопасности:
- рассматривайте уязвимость как проблему безопасности, а не простую ошибку, и в ответе, и в раскрытии информации. Например, явно укажите, что проблема является уязвимостью безопасности в заметках о выпуске;
- подтверждайте получение отчета об уязвимостях как можно быстрее, даже если у вас нет доступных специалистов, которые взялись бы за ее исследование. Этим вы заявляете, что быстро реагируете на проблемы, а также задаете положительный тон для дальнейшего общения с информирующим об уязвимости;
- при оценке влияния и достоверности отчета привлекайте информирующего об уязвимости. Скорее всего, этот человек уже рассматривал уязвимость в различных сценариях, и среди них могут быть те, которые вы не учитывали;
- исправьте проблему по своему усмотрению, внимательно прислушиваясь к замечаниям и советам от информирующего об уязвимости; Зачастую этот человек знает о крайних случаях и обходных решениях, которые легко не заметить, не имея опыта в области информационной безопасности.
- при раскрытии информации всегда благодарите информирующего об уязвимости;
- старайтесь публиковать исправления как можно скорее;
- При раскрытии сведений об уязвимости старайтесь сообщить о проблеме и ее решении как можно более широкому кругу лиц. Зачастую бывает так, что признанная проблема безопасности устраняется в текущей ветви разработки проекта, однако фиксация или последующий выпуск не имеют явной отметки о том, что это исправление или выпуск, устраняющие проблемы безопасности. Это может привести к проблемам для нижестоящих пользователей.
Публикация сведений об уязвимости безопасности не выставляет координатора в дурном свете. Такие проблемы в программном обеспечении повсеместны, и пользователи будут доверять координаторам, у которых есть четкий и отработанный процесс по раскрытию информации об уязвимостях безопасности в коде.
О сообщении и раскрытии уязвимостей в проектах на GitHub
На GitHub доступны два процесса:
- Стандартный процесс: репортеры уязвимостей обращаются к ответственный за репозиторий, используя контактные данные, расположенные в политике безопасности репозитория. При необходимости ответственный за репозиторий создайте черновик рекомендаций по репозиторию.
- Отчеты о частных уязвимостях: репортеры уязвимостей раскрывают сведения об уязвимостях напрямую и в частном порядке в ответственный за репозиторий, предлагая проект рекомендаций по репозиторию и предоставляя подробные сведения о своих результатах.
Стандартный процесс
Процесс отчёта и раскрытия уязвимостей для проектов на GitHub выглядит следующим образом:
Если вы являетесь информирующим об уязвимости (например, аналитиком в области безопасности) и хотите сообщить об уязвимости, сначала проверьте наличие политики безопасности для связанного репозитория. Дополнительные сведения см. в разделе Добавление политики безопасности в репозиторий. При наличии такой политики следуйте содержащимся в ней инструкциям перед тем, как обращаться в группу безопасности этого репозитория.
Если политика безопасности отсутствует, то установите закрытый канал связи с координаторами. Для этого создайте проблему, в которой укажите запрос на помощь предпочтительного контактного лица по вопросам безопасности. Стоит отметить, что эта проблема будет общедоступна, поэтому в ней не должно быть информации об ошибке. После установления связи вы можете предложить координаторам сформулировать политику безопасности на будущее.
Примечание.
_Только для npm_ — если мы получаем отчет о вредоносных программах в пакете npm, мы пытаемся связаться с вами в частном порядке. Если вы своевременно не решите проблему, мы ее раскрываем. Дополнительные сведения см. в статье ["Отчеты о вредоносных программах" в пакете](https://docs.npmjs.com/reporting-malware-in-an-npm-package) npm на веб-сайте документации npm.
Если вы обнаружили уязвимость безопасности в GitHub, пожалуйста, сообщите о ней через наш скоординированный процесс раскрытия информации. Для получения дополнительной информации смотрите сайт GitHub Security Bug Bounty .
Если вы являетесь координатором, то можете взять на себя ответственность за процесс с самого начала, настроив политику безопасности для репозитория или предоставив доступ к инструкциям по отчетам о безопасности, например в файле README проекта. Сведения о добавлении политики безопасности см. в разделе Добавление политики безопасности в репозиторий. Если политика безопасности отсутствует, скорее всего, информирующий об уязвимости попытается отправить вам письмо по электронной почте или иным образом связаться с вами в частном порядке. Либо кто-то может открыть (общедоступную) проблему с подробными сведениями о проблеме безопасности.
В качестве сопровождающего, чтобы выявить уязвимость в коде, вы сначала создаёте черновик совета по безопасности в репозитории пакета в GitHub. Рекомендации по безопасности репозитория позволяют поддерживать общедоступные репозитории для частного обсуждения и устранения уязвимости безопасности в проекте. После совместной работы над исправлением разработчики репозиториев могут публиковать рекомендации по безопасности, чтобы сообщить об уязвимости системы безопасности сообществу проекта. Публикуя рекомендации по безопасности, разработчики репозитория упрощают для сообщества обновление зависимостей пакетов и ознакомление с последствиями уязвимостей системы безопасности. Дополнительные сведения см. в разделе Сведения о помощниках по безопасности репозитория.
Сведения о начале работы см. в разделе Создание рекомендаций по безопасности репозитория.
Отчеты о частных уязвимостях
Владельцы и администраторы общедоступных репозиториев могут включать отчеты о частных уязвимостях в своих репозиториях. См . раздел AUTOTITLE.
Отчётность о частных уязвимостях предоставляет безопасный и структурированный способ для исследователей безопасности приватно раскрывать риски для поддерживающих репозиториев непосредственно внутри GitHub. Когда уязвимость сообщается, сопровождающие репозитории немедленно уведомляются, что позволяет им рассматривать и реагировать без риска преждевременного публичного раскрытия.
Без чётких рекомендаций по связям с сопровождающими специалисты могут быть вынуждены публично раскрывать уязвимости, например, публикуя сообщения в социальных сетях, открывая публичные вопросы или связываясь с сопровождающими через неформальные каналы, что может подвергнуть пользователей ненужному риску.
Для исследователей безопасности преимущества использования частных отчетов об уязвимостях:
- Понятный, структурированный способ связи с обслуживающими специалистами
- Более гладкий процесс раскрытия и обсуждения деталей уязвимостей
- Возможность приватно обсуждать детали уязвимости с поддерживающим репозитория
- Снижение риска того, что детали уязвимости станут публичными до появления исправления
Для сопровождающих преимущества использования частной отчётности о уязвимостях заключаются в следующем:
- Получение отчётов на той же платформе, где они разрешаются
- Исследователи безопасности создают или инициируют консультативный отчет от имени сопровождающих
- Снижение риска того, что уязвимости появятся в поле зрения до появления исправления
- Возможность приватно обсудить детали уязвимостей с исследователями безопасности и сотрудничать над патчем
Исследователи по безопасности также могут использовать REST API для частного отчета об уязвимостях безопасности. См . раздел AUTOTITLE.
Примечание.
Если репозиторий, содержащий уязвимость, не включает отчеты о частных уязвимостях, исследователи безопасности и ответственный за репозиторий должны следовать инструкциям, описанным в разделе "Стандартный процесс" выше.
Дальнейшие шаги
Если вы исследователь в области безопасности, ознакомьтесь с разделом AUTOTITLE , чтобы узнать, как приватно сообщать о уязвимости поддерживающему репозиторию.
Если вы являетесь сопровождающим репозиторий, см. Настройка отчетов о частных уязвимостях для репозитория , чтобы включить отчётность о закрытых уязвимостях для вашего репозитория, или Создание настраиваемой конфигурации безопасности для управления этим в вашей организации.