Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этом руководстве приведены действия по настройке и другие действия, помогающие интегрировать GitHub Advanced Security (GHAS) и Microsoft Defender для облака, а затем проверить конец интеграции. Интеграция помогает максимизировать безопасность облачных приложений Microsoft путем сопоставления рисков среды выполнения и контекста с исходным кодом для ускорения исправления на основе ИИ.
Следуя этому руководству, вы:
- Настройте репозиторий GitHub для Microsoft Defender для облака.
- Создайте фактор риска среды выполнения.
- Тестирование реальных вариантов использования в Defender для облака.
- Связывание кода с ресурсами среды выполнения.
- Запустите кампанию безопасности на сайте GitHub. Эта кампания использует контекст среды выполнения для определения приоритета оповещений безопасности GHAS.
- Создайте задачи GitHub из Defender для облака, чтобы начать исправление.
- Закройте цикл между командами инженеров и командами по безопасности.
Prerequisites
| Аспект | Сведения |
|---|---|
| Требования к окружающей среде | — учетная запись GitHub с соединителем, созданным в Defender для Облака — лицензия GitHub Advanced Security (GHAS) на подключенных репозиториях — план управления позицией безопасности Defender Cloud Security (DCSPM), активированный в подписке — Microsoft Security Copilot (необязательно для автоматического исправления на основе ИИ) |
| Роли и разрешения | — Разрешения администратора безопасности — Администратор безопасности в подписке Azure (для просмотра результатов в Defender для облака) — владелец организации GitHub (для подключения репозиториев и настройки кампаний безопасности) |
| Облачные среды | — Доступно только в коммерческих облаках (не в Azure для государственных организаций, Azure, управляемых 21Vianet или другими независимыми облаками) |
Подготовьте вашу среду
Шаг 1. Настройка репозитория GitHub и запуск рабочего процесса
Чтобы протестировать интеграцию, используйте собственные репозитории или проект-песочницу для примера, который имеет тестовый репозиторий GitHub со всем содержимым для создания уязвимого образа контейнера.
Войдите на портал Azure.
Перейдите к Microsoft Defender для облака>DevOps security.
Введите имя репозитория кода в строке поиска (пример: zava-webshop).
Убедитесь, что она принадлежит организации, которую вы отслеживаете, например, организации zava-corporation .
Проверьте наличие каких-либо результатов для репозитория.
Убедитесь, что состояние расширенной безопасностивключено. Это означает, что в отслеживаемом репозитории включена расширенная безопасность GitHub.
Если репозиторий не найден, обратитесь к документации Microsoft Defender для облака по устранению неполадок и подключению соединителя GitHub.
Убедитесь, что для соединителя GitHub включено безагентное сканирование.
Screenshot of Plan Configuration in Defender CSPM with Agentless code scanning toggled on and all scanner options enabled.
Screenshot of Plan Configuration in Defender CSPM with Agentless code scanning toggled on and all scanner options enabled.Скриншот конфигурации плана в Defender CSPM с агентским сканированием, включенным, и включенными всеми параметрами сканера.
Шаг 2. Проверка готовности среды
Проверка подтверждает правильность настройки вашей среды для вывода кода на рекомендации среды выполнения и генерации реализуемых результатов. На этом шаге Defender проверяет следующее:
Полный код для видимости среды выполнения
- Microsoft Defender для облака постоянно отслеживает репозитории исходного кода для уязвимостей безопасности.
- Артефакты сборки, такие как образы контейнеров, сканируются в контейнерных реестрах перед развертыванием.
- Нагрузки среды выполнения, развернутые в кластерах Kubernetes, отслеживаются на предмет рисков безопасности.
- Defender для облака сопоставляет и отслеживает каждый артефакт от кода, через этап сборки и развертывания, до времени выполнения и обратно.
Note
После применения предыдущих шагов может потребоваться до 24 часов, чтобы просмотреть следующие результаты.
Проверьте, что сканирование без агента GitHub находит репозиторий.
Перейдите к Microsoft Defender для облака>Cloud Security Explorer и выполните запрос. Запросы валидации тестируют, способен ли Defender идентифицировать артефакты, произведенные вашими конвейерами и рабочими нагрузками. Если запросы возвращают результаты, это означает, что сканирование и корреляция работают должным образом.
Note
Если результаты не возвращаются, это может указывать на то, что артефакты еще не созданы, сканирование не настроено или отсутствуют разрешения. Дополнительные сведения см. в разделе "Роли пользователей и разрешения ".
Убедитесь, что Defender для облака (в реестре контейнеров Azure) сканировал образ контейнера и использовал его для создания контейнера.
В запросе добавьте условия для конкретного развертывания.
Скриншот Cloud Security Explorer в Defender для облака с запросом об изменениях в репозитории GitHub, загружающих контейнерные образы с уязвимостями.
Убедитесь, что контейнер запущен и что Defender для облака сканировал кластер AKS.
Убедитесь, что факторы риска настроены правильно на стороне Defender для облака. Найдите имя контейнера на странице инвентаризации Defender для облака, и вы увидите, что он помечен как критически важный.
Note
Этот шаг необходим, только если факторы риска еще не настроены в вашей среде. Если вы уже используете факторы риска, можно проверить их конфигурацию в разделе " > Критически важные параметры ресурса".
Успешная валидация обеспечивает, что следующие шаги, такие как рекомендации, кампании и создание задач в GitHub, дают осмысленные результаты.
Note
После того как вы классифицируете ресурс как критический, может потребоваться до 12 часов, чтобы Defender для облака отправил данные в GitHub. Дополнительные сведения.
Шаг 3. Создание кампании GitHub
Чтобы создать кампанию сканирования, необходимо работать на уровне GitHub организации. Этот интерфейс недоступен на уровне отдельного репозитория.
В GitHub перейдите в организацию GitHub, используемую для тестирования установки.
Выберите Кампании безопасности>Создать кампанию>из фильтров сканирования кода>.
Эта кампания помогает определить приоритеты результатов GHAS, которые относятся к коду, который действительно развернут и запущен.
Выберите фильтры рисков среды выполнения для кампании.
Выберите Сохранить>Опубликовать как кампанию. Введите необходимые сведения и опубликуйте кампанию.
Шаг 4. Мобилизация рекомендаций
Используйте функциональность преобразования кода в время выполнения и корреляцию определенных CVEs с оповещениями безопасности Dependabot, чтобы понять статус проблем безопасности на основе рекомендаций VA для запущенных контейнеров. Затем вы можете назначить рекомендацию по устранению соответствующей группе инженеров на основе сопоставления кода с средой выполнения.
На портале Defender для облака перейдите на вкладку "Рекомендации ".
Найдите имя контейнера, созданного из репозитория кода.
Откройте одну из рекомендаций по обновлению программного обеспечения; имя рекомендации начинается с Обновление.
Выберите вкладку Связанные CVEs, оповещения системы безопасности отображаются в рамках потока оценки рекомендаций. Эти оповещения указывают на результаты проверки GitHub Advanced Security, уже известные инженерной команде. Обратите внимание, что некоторые идентификаторы CVE имеют ссылку "Посмотреть на GitHub" в столбце "Связанные оповещения на GitHub".
Выберите ссылку, чтобы открыть соответствующее оповещение системы безопасности GHAS. (Чтобы просмотреть содержимое оповещения GHAS в GitHub, необходимо иметь разрешения на доступ к соответствующему репозиторию GitHub. Если у вас нет разрешений на доступ, вы всегда можете скопировать ссылку для следующего использования или обратиться к администратору GitHub.)
Если есть улучшение оповещений, есть оповещение Dependabot, которое уже известно инженерам. Если состояние Активный, никто еще не исправил его, и проблема должна быть приоритетной для исправления.
Если нет выявления обогащения, это означает риск времени выполнения, неизвестный инженерам и требующий первоочередного исправления.
Дальнейшие действия Как узнать, какая команда является подходящей для решения проблемы? Как узнать, какой контекст может помочь инженерии с исправлением?
Создать проблему на GitHub
Чтобы закрыть цикл между группами безопасности и инженерами, можно создать проблему GitHub, которая определяет приоритеты проблем безопасности, на которые должна сосредоточиться команда инженеров. Эта приоритетность может включать передачу результатов, которые GHAS не обнаружил, но Defender для облака обнаружил CVE-идентификаторы, которые не входят в состав прямых зависимостей. Эти результаты могут включать уязвимости в базовом образе, операционной системе или программном обеспечении, например NGINX.
Проблема GitHub автоматически создается в репозитории исходного кода со всеми идентификаторами CVE, найденными в области рекомендации, включая другие контексты среды выполнения и контейнера SDLC, которые могут помочь в исправлении и тестировании.
В представлении рекомендаций можно непосредственно создать задачу GitHub для отслеживания работы по устранению.
Перейдите на вкладку "Обзор исправлений" и просмотрите диаграмму взаимосвязи кода и среды выполнения. Схема сопоставляет запущенный контейнер с образом контейнера в репозитории кода и репозиторием кода источника в GitHub.
На вкладке Аналитика по исправлению просмотрите затронутое поле Runtime.
Проверьте, существует ли уже задача в GitHub. Если проблема GitHub уже существует, в поле отображается значок GitHub. Наведите указатель мыши на значок, чтобы просмотреть сведения о проблеме.
Если проблема не существует и у вас есть необходимые разрешения, можно создать новую GitHub проблему. Выберите Принять меры.
Выберите параметр Создать задачу в GitHub из всплывающего окна.
Если проблема была создана успешно, появится всплывающее уведомление со ссылкой на проблему. Проблема создается в репозитории кода источника.
Note
Если параметр Generate GitHub для создания задачи недоступен, возможно, отсутствуют необходимые разрешения GitHub или репозитория. Чтобы запросить доступ, обратитесь к администратору GitHub или репозитория.
Сделайте агентные исправления
На стороне GitHub, если у вас есть лицензия на GitHub Copilot, вы можете устранить проблему с помощью агента GitHub кодирования:
- Назначьте агент GitHub для кодирования на задачу.
- Просмотрите созданное исправление.
- Если исправление кажется разумным, примените его.
- Обратите внимание, что Defender для облака обновляет состояние проблемы на закрытое.