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

Вы можете включить проверку секретов для отдельных репозиториев или для всех репозиториев в организации или организации. Дополнительные сведения см. в разделе "[AUTOTITLE", "Управление параметрами безопасности и анализа для репозитория" илиУправление функциями расширенной безопасности GitHub для вашего предприятия](/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/managing-security-and-analysis-settings-for-your-organization)".

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Уведомление. Определите веб-перехватчик, который специально отслеживает Оповещения о сканировании секретов , созданный при обходе защиты push-уведомлений с помощью свойства "push_protection_bypassed": trueоповещения. Кроме того, используйте API для получения обновлений, в которых Оповещения о сканировании секретов был результатом обхода принудительной защиты путем фильтрации списка результатов."push_protection_bypassed": true Дополнительные сведения см. в разделе Аудит оповещений системы безопасности.

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

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

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

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

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

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

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

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

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

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

   • Организация
   • Репозиторий
   • Тип секрета
   • Значение секрета
   • Контакты ответственных за репозитории

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

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

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

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

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

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