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

Можно включить сканирование секретов для отдельных репозиториев или для всех репозиториев в организации. Дополнительные сведения см. в разделе Управление параметрами безопасности и анализа для репозитория или Управление параметрами безопасности и анализа для организации.

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

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

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

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

1. Уведомление. Используйте веб-перехватчики, чтобы все новые оповещения о секретах показывались нужным командам как можно быстрее. Веб-перехватчик срабатывает при создании, разрешении или повторном открытии оповещения о секрете. Затем вы можете проанализировать полезные данные веб-перехватчика и интегрировать их в любые инструменты, которые используете вы и ваша команда, такие как Slack, Teams, Splunk и электронная почта. Дополнительные сведения см. в разделах Сведения о веб-перехватчиках и События и полезные данные веб-перехватчика.

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

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

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

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

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

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

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

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

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

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

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

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

   • План
   • Хранилище
   • Тип секрета
   • Значение секрета
   • Контакты ответственных за репозитории

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

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

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

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

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

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

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