Этап 6. Развертывание и масштабирование сканирования секретов

Вы можете быстро активировать функции безопасности в масштабе с помощью security configuration — набора настроек обеспечения безопасности, которые можно применить к репозиториям организации. Вы можете настроить Advanced Security функции на уровне организации с помощью global settings. См . раздел AUTOTITLE.

В этой статье объясняется высокоуровневый процесс, ориентированный на обеспечение secret scanning всех репозиториев в организации. Принципы, описанные в этой статье, всё равно могут применяться даже при более поэтапном подходе к созданию secret scanning отдельных репозиториев.

1. Сосредоточьтесь на недавно зафиксированных секретах

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

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

1.        **Уведомление**. Используйте веб-перехватчики, чтобы все новые оповещения о секретах показывались нужным командам как можно быстрее. Веб-перехватчик срабатывает при создании, разрешении или повторном открытии оповещения о секрете. Затем вы можете проанализировать полезные данные веб-перехватчика и интегрировать их в любые инструменты, которые используете вы и ваша команда, такие как Slack, Teams, Splunk и электронная почта. Дополнительные сведения см. в разделе [AUTOTITLE и [AUTOTITLE](/webhooks-and-events/webhooks/about-webhooks)](/webhooks-and-events/webhooks/webhook-events-and-payloads#secret_scanning_alert).
   

2.        **Дальнейшие действия**. Создайте высокоуровневый процесс исправления, который работает для всех типов секретов. Например, вы можете связаться с разработчиком, который создал секрет, и его техническим руководителем этого проекта, подчеркнув опасности сохранения секретов GitHubв , и попросить их отозвать и обновить обнаруженный секрет.
   

   Примечание.

   Этот шаг можно автоматизировать. Для крупных предприятий и организаций с сотнями репозиториев выполнение этих действий вручную является нецелесообразным. Вы можете встроить автоматизацию в процесс веб-перехватчика, определенный на первом шаге. Полезные данные веб-перехватчика содержат сведения об утечке секретов в репозитории и организации. Используя эти сведения, вы можете связаться с текущими ответственными специалистами по репозиторию и отправить им электронное письмо или текстовое сообщение или открыть проблему.

3.        **Обучение**. Создайте внутренний обучающий документ, предназначенный для разработчиков, которые фиксируют секреты. В этом обучающем документе вы можете объяснить риски, создаваемые фиксацией секретов, и предложить ознакомиться с рекомендациями по безопасному использованию секретов в разработке. Если разработчик не учится на опыте и продолжает фиксировать секреты, можно создать процесс эскалации, но образование обычно работает хорошо.
   

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

2. Включение защиты push-уведомлений

После включения secret scanningтакже следует включить защиту от пуша. При защите secret scanning от push проверяет наличие поддерживаемых секретов и блокирует push до GitHub_того, как_ секреты будут раскрыты другим пользователям. Сведения о включении защиты push-уведомлений см. в разделе Включение защиты push-уведомлений для репозитория.

После включения можно выполнить следующее:

1.        **Дайте советы:** Настройте пользовательскую ссылку в сообщении, чтобы участники увидели, заблокирован ли их push .secret scanning Связанный ресурс может предоставить рекомендации для участников по устранению заблокированной отправки. Дополнительные сведения см. в разделе [AUTOTITLE](/code-security/secret-scanning/enabling-secret-scanning-features/enabling-push-protection-for-your-repository).
   

2.        **Уведомление:** Определите вебхук, который специально отслеживает Оповещения о сканировании секретов , когда кто-то обходит защиту от пуша, используя свойство `"push_protection_bypassed": true`оповещения . Или используйте API для получения обновлений, которые Оповещения о сканировании секретов были результатом обхода от push-защиты, фильтруя список результатов для `"push_protection_bypassed": true`. Дополнительные сведения см. в разделе [AUTOTITLE](/code-security/getting-started/auditing-security-alerts).
   

3.        **Мониторинг.** Используйте обзор безопасности для просмотра метрик о том, как защита от принудительной отправки выполняется в репозиториях в вашей организации, чтобы быстро определить все репозитории, в которых может потребоваться выполнить действия. Дополнительные сведения см. в разделе [AUTOTITLE](/code-security/concepts/secret-security/push-protection-metrics).
   

3. Исправление ранее зафиксированных секретов, начиная с наиболее критически важных

После того как вы наладили процесс снижения добавления секретов в ваши кодовые базы, вы готовы приступить к исправлению секретов, которые были совершёны до вашего внедрения GitHub Advanced Security.

Определение наиболее важных секретов зависит от процессов и интеграций в вашей организации. Например, компания, скорее всего, не беспокоится о входящих секретах веб-перехватчика Slack, если она не использует Slack. Возможно, вам будет полезно сначала сосредоточиться на пяти наиболее важных типах учетных данных для вашей организации.

После выбора типов секретов можно выполнить следующие действия.

1. Определите процесс исправления каждого типа секрета. Фактические процедуры для каждого типа секрета часто сильно отличаются. Запишите процесс для каждого типа секрета в документе или внутренней базе знаний.

   Примечание.

   При создании процесса отзыва секретов попробуйте и присвойте команде ответственность за отзыв секретов команде, поддерживающей репозиторий, а не центральной команды. Один из принципов GHAS заключается в том, что разработчики берут на себя ответственность за безопасность и несут ответственность за устранение проблем безопасности, особенно если это они их создали.

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

   Общие сведения о безопасности можно использовать для сбора этих сведений. Дополнительные сведения об использовании системы безопасности см. в разделе Обзор фильтрации оповещений в области безопасности.

   Сведения, которые может потребоваться собрать, включают следующие.

   • Организация

   • Репозиторий

   • Тип секрета

   • Значение секрета

   • Контакты ответственных за репозитории

   Примечание.

   Используйте пользовательский интерфейс, если у вас есть несколько секретов этого типа. Если у вас сотни утечек секретов, используйте API для сбора информации. Дополнительные сведения см. в разделе Конечные точки REST API для проверки секретов.

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

4. Разверните программу, чтобы включить дополнительные типы секретов и пользовательские шаблоны

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

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

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