Использование инструмента сканирования уязвимостей Snyk

Учебники
Kubernetes

Введение

Snyk был разработан с целью служить платформой безопасности для разработчиков с учетом гибкости. Его основная цель – помочь вам обнаруживать и устранять уязвимости в исходном коде вашего приложения, сторонних зависимостях, образах контейнеров и конфигурационных файлах инфраструктуры (например, Kubernetes, Terraform и т. д.).

Snyk разделен на четыре компонента:

  1. Snyk Code – помогает находить и устранять уязвимости в исходном коде вашего приложения.
  2. Snyk Open Source – помогает находить и устранять уязвимости для любых сторонних библиотек или зависимостей, от которых зависит ваше приложение.
  3. Snyk Container – помогает находить и устранять уязвимости в образах контейнеров или рабочих нагрузках Kubernetes, используемых в вашем кластере.
  4. Snyk Infrastructure as Code – помогает находить и устранять ошибки конфигурации в ваших манифестах Kubernetes (поддерживаются также Terraform, CloudFormation и Azure).

Snyk можно запускать разными способами:

  • Через интерфейс командной строки, используя Snyk CLI. Это предпочтительный способ запуска внутри сценариев и различных автоматизаций, включая конвейеры CI/CD.
  • В браузере как Snyk Web UI. Snyk также предлагает облачную платформу, с помощью которой вы можете изучать отчеты о проверке, получать подсказки и выполнять необходимые действия для исправления обнаруженных проблем и т. д. Вы также можете подключить репозитории GitHub и выполнять сканирования/аудиты из веб-интерфейса.
  • Через плагины IDE. Таким образом, вы можете обнаружить проблемы на ранних этапах разработки, используя свою любимую среду разработки (например, Visual Studio Code).
  • Программным способом, через API Snyk. API Snyk доступно клиентам на платных тарифах и позволяет вам программно интегрироваться с Snyk.

Бесплатен ли Snyk?

Да, инструментарий бесплатен, за исключением API Snyk и некоторых расширенных функций веб-интерфейса (например, расширенного отчетирования). Также есть ограничение на количество тестов, которые вы можете выполнить в месяц.

См. планы тарификации для получения дополнительной информации.

Является ли Snyk открытым исходным кодом?

Да, инструментарий и, безусловно, Snyk CLI являются открытыми. Вы можете посетить домашнюю страницу Snyk на GitHub, чтобы получить более подробную информацию о реализации каждого компонента. Облачный портал и все платные функции, такие как реализация API, не являются открытыми исходными кодами.

Другой важный набор концепций, который использует Snyk, – это Цели и Проекты.

Цели представляют собой внешний ресурс, который Snyk просканировал через интеграцию, интерфейс командной строки (CLI), пользовательский интерфейс (UI) или API. Примерами целей являются репозиторий SCM, нагрузка Kubernetes и т. д.

С другой стороны, Проекты определяют элементы, которые Snyk сканирует на данной Цели. Проект включает:

  • A scannable item external to Snyk.
  • Конфигурацию для определения способа запуска этого сканирования.

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

В этом руководстве вы будете использовать Snyk CLI для выполнения анализа рисков поставки ваших приложений Kubernetes (образы контейнеров, манифесты YAML Kubernetes). Затем вы узнаете, как принять соответствующие меры по устранению ситуации. Наконец, вы узнаете, как интегрировать Snyk в конвейер непрерывной интеграции и непрерывной доставки (CI/CD), чтобы сканировать уязвимости на ранних этапах разработки.

Содержание

Предварительные требования

Для завершения всех шагов из этого руководства вам понадобятся:

  1. A working DOKS cluster running Kubernetes version >=1.21 that you have access to. For additional instructions on configuring a DigitalOcean Kubernetes cluster, see: How to Set Up a DigitalOcean Managed Kubernetes Cluster (DOKS).
  2. A DigitalOcean Docker Registry. A free plan is enough to complete this tutorial. Also, make sure it is integrated with your DOKS cluster as explained here.
  3. Kubectl CLI для взаимодействия с Kubernetes. Следуйте этим инструкциям, чтобы подключиться к вашему кластеру с помощью kubectl и doctl.
  4. Snyk CLI для взаимодействия со сканером уязвимостей Snyk.
  5. A free Snyk cloud account account used to periodically publish scan results for your Kubernetes cluster to a nice dashboard. Also, the Snyk web interface helps you with investigations and risk analysis. Please follow How to Create a Snyk Account documentation page.
  6. A Slack workspace you own, and a dedicated Slack app to get notified of vulnerability scan issues reported by Snyk.

Шаг 1 – Знакомство с Snyk CLI

Вы можете вручную сканировать уязвимости через интерфейс командной строки snyk. CLI Snyk предназначен для использования в различных сценариях и автоматизациях. Практический пример – в конвейере CI/CD, реализованном с использованием различных инструментов, таких как Tekton, Jenkins, рабочие процессы GitHub и т. д.

Когда вызывается CLI Snyk, он сразу начинает процесс сканирования и сообщает об обнаруженных проблемах в определенном формате. По умолчанию он выводит сводную таблицу с использованием стандартного вывода или консоли. Snyk также может генерировать отчеты в других форматах, таких как JSON, HTML, SARIF и т. д.

Вы можете выбрать отправку результатов на портал облачной платформы Snyk (или веб-интерфейс) с помощью флага --report, чтобы сохранить и визуализировать результаты сканирования позже.

Примечание:
Не обязательно отправлять результаты сканирования на портал облачной платформы Snyk. Большим преимуществом использования портала Snyk является видимость, потому что он предоставляет доступ к удобной панели инструментов, где вы можете проверить все отчеты о сканировании и увидеть, насколько пострадала цепочка поставок Kubernetes. Также он помогает вам на длительной дистанции с расследованиями и подсказками по устранению.

CLI Snyk разделен на несколько подкоманд. Каждая подкоманда посвящена определенной функции, такой как:

Прежде чем продолжить, убедитесь, что создали бесплатную учетную запись с использованием веб-интерфейса Snyk. Кроме того, CLI Snyk также должен быть аутентифицирован с вашей учетной записью в облаке, чтобы некоторые команды/подкоманды работали (например, snyk code test).

A few examples to try with Snyk CLI:

  1. Сканирование открытого исходного кода:
# Сканирует код вашего проекта из текущего каталога
snyk test
# Сканирует конкретный путь из каталога вашего проекта (убедитесь, что заменили соответствующие заполнители `<>`)
snyk test <path/to/dir>
  1. Сканирование кода:
# Сканируйте код вашего проекта из текущего каталога
snyk code test

# Сканируйте конкретный путь из каталога вашего проекта (убедитесь, что заменили заполнители `<>` соответственно)
snyk code test <path/to/dir>
  1. Сканирование образа:
# Сканирует образ docker debian, предварительно его загружая
snyk container debian

# Предоставьте больше контекста сканеру, предоставив Dockerfile (убедитесь, что заменили заполнители `<>` соответственно)
snyk container debian --file=<path/to/dockerfile>
  1. Сканирование инфраструктуры как кода:
# Сканируйте код вашего проекта из текущего каталога
snyk iac test

# Сканируйте конкретный путь из каталога вашего проекта (убедитесь, что заменили заполнители `<>` соответственно)
snyk iac test <path/to/dir>

# Сканируйте проекты на основе Kustomize (сначала вам нужно отрендерить конечный шаблон, а затем передать его сканеру)
kustomize build > kubernetes.yaml
snyk iac test kubernetes.yaml

Snyk CLI предоставляет страницы справки для всех доступных опций. Нижеприведенная команда может быть использована для вывода основной страницы справки:

snyk --help

Вывод выглядит аналогично:

Output
CLI commands help
  Snyk CLI scans and monitors your projects for security vulnerabilities and license issues.

  For more information visit the Snyk website https://snyk.io

  For details see the CLI documentation https://docs.snyk.io/features/snyk-cli

How to get started
  1. Authenticate by running snyk auth
  2. Test your local project with snyk test
  3. Get alerted for new vulnerabilities with snyk monitor

Available commands
  To learn more about each Snyk CLI command, use the --help option, for example, snyk auth --help or 
  snyk container --help

  snyk auth
    Authenticate Snyk CLI with a Snyk account.

  snyk test
    Test a project for open source vulnerabilities and license issues.

У каждой команды (или подкоманды) snyk CLI также есть соответствующая страница справки, к которой можно получить доступ через snyk [command] --help.

Пожалуйста, посетите официальную страницу документации snyk CLI для получения большего количества примеров.

Шаг 2 – Знакомство с веб-интерфейсом Snyk

После регистрации учетной записи в Snyk, аутентификации и входа в систему Snyk, веб-интерфейс открывается на панели инструментов с мастером, который проведет вас через шаги настройки:

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

Следующие функции доступны через веб-интерфейс:

Пожалуйста, посетите официальную страницу документации, чтобы узнать больше о веб-интерфейсе Snyk.

Понимание уровней серьезности Snyk

При каждом сканировании snyk проверяет ваши ресурсы на потенциальные уязвимости и влияние каждой на вашу систему. Уровень серьезности применяется к уязвимости, чтобы указать на риск этой уязвимости в приложении.

Уровни серьезности могут принимать одно из следующих значений:

  • Низкий: приложение может раскрывать некоторые данные, позволяя сопоставить уязвимости, которые могут использоваться с другими уязвимостями для атаки на приложение.
  • Средний: может позволить злоумышленникам при определенных условиях получить доступ к чувствительным данным на вашем приложении.
  • Высокий: может позволить злоумышленникам получить доступ к чувствительным данным на вашем приложении.
  • Критический: может позволить злоумышленникам получить доступ к чувствительным данным и выполнить код на вашем приложении.

Система общего уровня уязвимости (CVSS) определяет уровень серьезности уязвимости. Snyk использует версию 3.1 структуры CVSS для передачи характеристик и серьезности уязвимостей.

Ниже приведена таблица, отображающая каждый уровень серьезности:

Severity level CVSS score
Low 0.0 – 3.9
Medium 4.0 – 6.9
High 7.0 – 8.9
Critical 9.0 – 10.10

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

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

Помощь в устранении сообщенных проблем безопасности

Еще одна полезная функция, предоставляемая веб-интерфейсом Snyk, – это помощь в устранении проблем безопасности. Это означает, что вы получаете рекомендацию о том, как исправить каждую обнаруженную проблему безопасности сканером snyk. Это очень важно, потому что упрощает процесс и закрывает петлю для каждой итерации, которую вам нужно выполнить для исправления каждой сообщенной проблемы безопасности.

Ниже приведена иллюстрация этого процесса:

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

Основная процедура одинакова для каждой сообщенной проблемы. Это означает, что вы нажимаете на кнопку “показать детали”, затем следуете предложенным шагам для применения исправления.

Шаг 3 – Использование Snyk для сканирования уязвимостей конфигурации Kubernetes в конвейере CI/CD

Как вы можете получить выгоду от внедрения инструмента сканирования соответствия безопасности в свой конвейер CI/CD и избежать неприятных ситуаций в производственной среде?

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

Таким образом, инструмент сканирования безопасности (например, snyk) действует как преграда, останавливающая нежелательные артефакты от попадания в ваше производственное окружение с ранних этапов разработки. Таким же образом, конвейеры верхних сред используют snyk для разрешения или запрещения артефактов приложения на финальном этапе производства.

Внедрение рабочего процесса GitHub Actions CI/CD

На этом этапе вы узнаете, как создать и протестировать образец конвейера CI/CD с интегрированным сканированием уязвимостей через рабочие процессы GitHub. Чтобы изучить основы использования действий Github с Kubernetes DigitalOcean, обратитесь к этому учебному пособию.

Предоставленный в следующем разделе конвейер создает и развертывает приложение game-2048-example из репозитория DigitalOcean kubernetes-sample-apps.

На высоком уровне обзора рабочего процесса CI/CD для игры 2048, предоставленного в репозитории kubernetes-sample-apps, содержит следующие этапы:

  1. Этап сборки и тестирования приложения – создает основные артефакты приложения и запускает автоматические тесты.
  2. Этап сканирования образа приложения Snyk – сканирует образ Docker приложения на известные уязвимости. Он выступает в качестве ворот, и окончательное состояние конвейера (пройдено/не пройдено) зависит от этого этапа. В случае сбоя отправляется уведомление в Slack.
  3. Этап сборки и публикации образа приложения – создает и маркирует образ приложения с использованием последнего коммита git SHA. Затем образ отправляется в DOCR.
  4. Сцена сканирования инфраструктуры Snyk в формате кода (IAC) – сканирует известные уязвимости в манифестах Kubernetes YAML, связанных с приложением. Действует как ворота, и конечное состояние конвейера (прохождение/провал) зависит от этого шага. В случае отказа также отправляется уведомление в Slack.
  5. Этап развертывания приложения – развертывает приложение в Kubernetes (DOKS).

Ниже приведена диаграмма, иллюстрирующая каждую задачу из конвейера и связанные с ней шаги с действиями (показана только соответствующая конфигурация):

Примечания:

  • В случае проектов, основанных на kustomize, лучше всего отобразить окончательный манифест, чтобы захватить и отсканировать все (включая удаленные ресурсы). С другой стороны, может быть сложно определить, какой ресурс Kubernetes нужно патчить. Это связано с тем, что получившийся файл манифеста состоит из всех ресурсов, которые должны быть применены. Так работает kustomize – он собирает все фрагменты конфигурации из каждого оверлея и применяет их поверх базы для создания окончательного составного.
  • Вы также можете указать Snyk сканировать весь каталог, где находятся ваши конфигурации kustomize. Таким образом, легче определить, какой ресурс нужно исправить в вашем репозитории. Удаленные ресурсы, используемые kustomize, должны быть исправлены в исходном потоке. Кроме того, секреты Kubernetes и ConfigMaps, сгенерированные с помощью kustomize, не учитываются.

Каким образом можно прервать конвейер, если определенный уровень безопасности не достигнут?

Командная строка Snyk предоставляет флаг с именем --severity-threshold для этой цели. Этот флаг соотносится с общим уровнем серьезности, рассчитываемым после каждого сканирования. В случае Snyk уровень серьезности принимает одно из следующих значений: low, medium, high или critical. Вы можете проваливать или проходить конвейер на основе значения уровня серьезности и останавливать развертывание приложения, если условия не соблюдаются.

Ниже приведена схема потока для примера CI/CD-конвейера, используемого в этом руководстве:

Пожалуйста, выполните следующие шаги для создания и тестирования рабочего процесса GitHub CI/CD для Snyk, предоставленного в репозитории GitHub kubernetes-sample-apps:

  1. Склонируйте репозиторий GitHub kubernetes-sample-apps.
  2. Создайте следующие зашифрованные секреты GitHub для вашей копии kubernetes-sample-apps (вкладка Настройки -> Секреты -> Действия):
    • DIGITALOCEAN_ACCESS_TOKEN – содержит токен вашей учетной записи DigitalOcean.
    • DOCKER_REGISTRY – содержит имя вашего реестра Docker DigitalOcean, включая конечную точку (например, registry.digitalocean.com/sample-apps).
    • DOKS_CLUSTER – содержит имя вашего кластера DOKS. Вы можете выполнить следующую команду, чтобы получить имя вашего кластера DOKS: doctl k8s cluster list --no-header --format Name.
    • SNYK_TOKEN – содержит идентификатор вашей учетной записи пользователя Snyk – выполните: snyk config get api, чтобы получить идентификатор. Если это не работает, вы можете получить токен со страницы настроек вашей учетной записи.
    • SLACK_WEBHOOK_URL – содержит ваш URL входящего вебхука Slack, используемый для уведомлений о сканировании Snyk.
  3. Перейдите на вкладку Действия вашего форкнутого репозитория и выберите рабочий процесс Пример CI/CD для Game 2048 Snyk:
  4. Нажмите кнопку Запустить рабочий процесс и оставьте значения по умолчанию:

A new entry should appear in the below list after clicking the Run Workflow green button. Select the running workflow to observe the pipeline progress:

Пайплайн завершится с ошибкой, когда будет запущена задача snyk-container-security-check. Это ожидаемо, потому что значение уровня серьезности по умолчанию, используемое во входных данных рабочего процесса, которое равно medium, не соответствует ожиданиям. Вы также должны получить уведомление в Slack с деталями запуска рабочего процесса:

На следующих этапах вы узнаете, как исследовать отчет о сканировании snyk, чтобы исправить проблемы, понизить уровень серьезности и пройти пайплайн.

Шаг 4 – Исследование результатов сканирования Snyk и устранение сообщенных проблем

В случае недостижения порогового уровня серьезности, рабочий процесс GitHub game-2048 завершится неудачно, и будет отправлено уведомление в Slack с дополнительными подробностями. Также вы получите опубликованные отчеты о безопасности на GitHub и сможете получить к ним доступ во вкладке Безопасность вашего проектного репозитория.

Рабочий процесс game-2048 выполняет две проверки безопасности:

  1. Проверки безопасности образа контейнера – для этой цели используется задача snyk-container-security-check. Используемая эквивалентная команда snyk – snyk container test <GAME-2048-IMAGE>:<TAG> --file=/path/to/game-2048/Dockerfile.
  2. Проверки настройки манифестов Kubernetes – для этой цели используется задача snyk-iac-security-check. Используемая эквивалентная команда snyk – snyk iac test /path/to/project/kubernetes/manifests.

Таким образом, понижение уровня серьезности и прохождение рабочего процесса состоит в:

  1. Исследовании и устранении проблем, сообщенных задачей snyk-container-security-check.
  2. Исследовании и устранении проблем, сообщенных задачей snyk-iac-security-check.

Затем вы узнаете, как обратиться к каждому из них по очереди.

Исследование и устранение уязвимостей контейнерных образов

Образец конвейера, использованный в этом руководстве, выполняет проверку безопасности для образа контейнера game-2048 и связанного с ним Dockerfile через задачу snyk-container-security-check.

Задача snyk-container-security-check выполняет следующие шаги:

  1. Собирает образ приложения game-2048 Docker локально. Этот шаг реализуется с использованием действия GitHub docker-build-push.
  2. Запускает проверки безопасности Snyk для образа контейнера приложения и Dockerfile. Этот шаг реализуется с использованием команды snyk container test. Результаты сканирования экспортируются в формате GitHub SARIF. Порог уровня безопасности контролируется с помощью аргумента –severity-threshold – он либо устанавливается в значение параметра ввода snyk_fail_threshold, если рабочий процесс запускается вручную, либо в переменную среды SNYK_FAIL_THRESHOLD, если рабочий процесс запускается автоматически.
  3. Результаты сканирования (в формате SARIF) публикуются во вкладке безопасности репозитория вашего приложения. Этот шаг реализован с использованием действия GitHub codeql.

Ниже приведен основной код работы snyk-container-security-check:

- name: Build App Image for Snyk container scanning
  uses: docker/build-push-action@v3
  with:
    context: ${{ env.PROJECT_DIR }}
    push: false
    tags: "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}"

- name: Check application container vulnerabilities
  run: |
    snyk container test "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
      --file=Dockerfile \
      --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
      --target-name=${{ env.PROJECT_NAME }} \
      --target-reference=${{ env.ENVIRONMENT }} \
      --sarif --sarif-file-output=snyk-container-scan.sarif
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  working-directory: ${{ env.PROJECT_DIR }}

- name: Upload Snyk report SARIF file
  if: ${{ always() }}
  uses: github/codeql-action/upload-sarif@v2
  with:
    sarif_file: ${{ env.PROJECT_DIR }}/snyk-container-scan.sarif
    category: snyk-container-scan

–file=Dockerfile \

–severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \

–target-name=${{ env.PROJECT_NAME }} \

–target-reference=${{ env.ENVIRONMENT }} \

–sarif –sarif-file-output=snyk-container-scan.sarif

Для устранения отчетных проблем сначала необходимо проверить вкладку безопасности вашего форка репозитория kubernetes-sample-apps:

FROM node:18.6.0-slim AS builder
WORKDIR /usr/src/app
COPY . .
RUN npm install --include=dev
Вы увидите множество уязвимостей для базового образа Docker в данном случае. Нажмите на каждую, чтобы развернуть и увидеть больше деталей:
Для завершения исследований и просмотра рекомендаций, предлагаемых Snyk, вам необходимо проверить вывод работы snyk-container-security-check из основного рабочего процесса:
Примечание: Snyk container test предоставляет возможность экспорта результатов в формат SARIF, но не знает, как загружать отчеты в портал Snyk Cloud. С другой стороны, snyk container monitor предоставляет возможность загрузки результатов в портал облачных ресурсов Snyk, но не может экспортировать SARIF. Поэтому в этом руководстве используется snyk container test с функцией экспорта SARIF. К сожалению, некоторые рекомендации недоступны в выводе SARIF. Поэтому вам также необходимо смотреть рекомендации в выводе консоли работы.
Результаты работы задания snyk-container-security-check показывают, что Snyk рекомендует обновить версию базового образа с node:16-slim на node:18.6.0-slim. Это изменение устраняет проблему(ы) высокого риска и также снижает количество других обнаруженных уязвимостей с 70 до 44 - это значительное сокращение почти на 50% !!!
ENV NODE_ENV=development
RUN npm run build

FROM node:18.6.0-slim
RUN npm install http-server -g
RUN mkdir /public
WORKDIR /public
COPY --from=builder /usr/src/app/dist/ ./
EXPOSE 8080
USER 1000
CMD ["http-server"]

Теперь откройте файл Dockerfile приложения game-2048 из вашего форка и измените директивы FROM так, чтобы они указывали на новую версию (node:18.6.0-slim на момент написания этого сообщения):

#

# Режим сборки может быть установлен с помощью переменной среды NODE_ENV (development или production)

# См. package.json проекта и webpack.config.js

#

Наконец, зафиксируйте изменения в вашем репозитории GitHub и снова запустите рабочий процесс (оставив значения по умолчанию). В этот раз задание snyk-container-security-check должно пройти:

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

Как вы будете обеспечивать сокращение уязвимостей базового образа в будущем?

  1. Лучший подход – использовать базовый образ с минимальным объемом – чем меньше двоичные файлы или зависимости в базовом образе, тем лучше. Еще одна хорошая практика – непрерывно мониторить ваши проекты, как объясняется в разделе Мониторинг ваших проектов на регулярной основе этого руководства.
  2. Вы заметите, что конвейер по-прежнему не проходит, но на этот раз на этапе snyk-iac-security-check. Это ожидаемо, потому что существуют проблемы безопасности с манифестами Kubernetes, используемыми для развертывания приложения. В следующем разделе вы узнаете, как исследовать эту ситуацию и применить рекомендации по безопасности Snyk для исправления сообщенных проблем.

Исследование и устранение уязвимостей манифестов Kubernetes

- name: Check for Kubernetes manifests vulnerabilities
  run: |
    snyk iac test \
      --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
      --target-name=${{ env.PROJECT_NAME }} \
      --target-reference=${{ env.ENVIRONMENT }} \
      --sarif --sarif-file-output=snyk-iac-scan.sarif \
      --report
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  working-directory: ${{ env.PROJECT_DIR }}

- name: Upload Snyk IAC SARIF file
  if: ${{ always() }}
  uses: github/codeql-action/upload-sarif@v2
  with:
    sarif_file: ${{ env.PROJECT_DIR }}/snyk-iac-scan.sarif
    category: snyk-iac-scan

Конвейер по-прежнему не проходит и останавливается на задании snyk-iac-security-check. Это ожидаемо, потому что значение уровня серьезности по умолчанию, используемое во входных данных рабочего процесса, которое составляет средний, не соответствует требованиям безопасности для проекта.

  1. Задание snyk-iac-security-check проверяет уязвимости (или неправильные конфигурации) манифестов Kubernetes и выполняет следующие шаги:
  2. Проверки безопасности Snyk для манифестов Kubernetes из каталога проекта game-2048-example. Этот шаг реализуется с помощью команды snyk iac test. Результаты сканирования экспортируются в формате GitHub SARIF. Порог уровня безопасности контролируется с помощью аргумента –severity-threshold – он устанавливается либо в значение параметра ввода snyk_fail_threshold, если рабочий процесс запускается вручную, либо в переменную окружения SNYK_FAIL_THRESHOLD, если рабочий процесс запускается автоматически. Наконец, также используется аргумент –report для отправки результатов сканирования в портал Snyk Cloud.

Результаты сканирования (формат SARIF) публикуются на вкладке безопасности репозитория вашего приложения. Этот шаг реализуется с использованием действия GitHub codeql.

Ниже приведен фрагмент кода, показывающий фактическую реализацию каждого шага из задания snyk-iac-security-check:

–severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \

–target-name=${{ env.PROJECT_NAME }} \

–target-reference=${{ env.ENVIRONMENT }} \

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: game-2048
spec:
  replicas: 1
  selector:
    matchLabels:
      app: game-2048
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: game-2048
    spec:
      containers:
        - name: backend
          --sarif --sarif-file-output=snyk-iac-scan.sarif \
          image: registry.digitalocean.com/sample-apps/2048-game:latest
          ports:
            - name: http
              containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 50Mi
            limits:
              cpu: 200m
              memory: 100Mi
          securityContext:
            readOnlyRootFilesystem: true
            runAsNonRoot: true
            allowPrivilegeEscalation: false
            capabilities:
              drop:
                - all

Для устранения обнаруженных проблем у вас есть два варианта:

  • Используйте портал Snyk Cloud и получите доступ к проекту game-2048, чтобы узнать подробности:
  • Используйте вкладку безопасности вашего репозитория приложения 2048-игры, чтобы проверить подробности:
  • В любом случае, вы получите рекомендации о том, как исправить сообщенные проблемы.
  • Для этого руководства вы будете использовать облачный портал Snyk для изучения сообщенных проблем безопасности. Сначала щелкните запись пример 2048-игры в списке проектов, затем выберите файл kustomize/resources/deployment.yaml:

Затем установите флажок Среднее в меню Серьезность слева, чтобы отобразить только проблемы уровня средней сложности:

Затем вы можете проверить каждую карточку с сообщенной проблемой и проверить детали. Продолжайте и щелкните кнопку Показать больше деталей на карточке Контейнер работает без контроля над пользователем root – вы получите больше информации о текущей проблеме и важные подсказки о том, как ее исправить:

A few final checks can be performed as well on the Kubernetes side to verify if the reported issues were fixed:

  1. После сбора всей информации из каждой карточки вы можете продолжить и отредактировать файл deployment.yaml из вашего репозитория (находится в подпапке game-2048-example/kustomize/resources). Исправления уже внесены, вам просто нужно раскомментировать последние строки в файле. Окончательный файл deployment.yaml должен выглядеть следующим образом:
  2. readOnlyRootFilesystem – запускает образ контейнера только для чтения (нельзя изменять файлы с помощью kubectl exec в контейнере).

allowPrivilegeEscalation – установка allowPrivilegeEscalation в false гарантирует, что дочерний процесс контейнера не может получить больше привилегий, чем его родитель.

capabilities.drop – Для обеспечения большей безопасности контейнеров следует предоставить им минимально необходимые привилегии для выполнения. На практике вы отказываете во всем по умолчанию, затем добавляете требуемые привилегии пошагово. Вы можете узнать больше о привилегиях контейнера здесь.

Наконец, зафиксируйте изменения для файла deployment.yaml и отправьте в основную ветку. После ручного запуска рабочего процесса он должен успешно завершиться на этот раз:

Вы также должны получить зеленое уведомление в Slack о выполнении задания сканирования snyk. Перейдите по ссылке портала Snyk и проверьте, исчезли ли проблемы, которые вы недавно исправили – не должно быть проблем среднего уровня.

Проверьте, имеет ли развертывание игры 2048 файловую систему только для чтения (неизменяемую), записав в файл index.html, используемый приложением игры 2048:

kubectl exec -it deployment/game-2048 -n game-2048 -- /bin/bash -c "echo > /public/index.html"

Вывод выглядит примерно следующим образом:

Вывод
/bin/bash: /public/index.html: Файловая система только для чтения file
команда завершена с кодом выхода 1

Проверьте, имеет ли развертывание игры 2048 файловую систему только для чтения (неизменяемую), записав в файл index.html, используемый приложением игры 2048:

Вывод выглядит примерно следующим образом:

snyk-container-security-check:
    runs-on: ubuntu-latest
    needs: build-and-test-application

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      ...

      - name: Check application container vulnerabilities
        run: |
          snyk container test "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
            --file=${{ env.PROJECT_DIR }}/Dockerfile \
            --severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
            --target-name=${{ env.PROJECT_NAME }} \
            --target-reference=${{ env.ENVIRONMENT }} \
            --sarif-file-output=snyk-container-scan.sarif
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

      - name: Monitor the application container using Snyk
        run: |
          snyk container monitor "${{ secrets.DOCKER_REGISTRY }}/${{ env.PROJECT_NAME }}:${{ github.sha }}" \
            --file=${{ env.PROJECT_DIR }}/Dockerfile
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
      
      ...

Проверьте, работает ли контейнер от имени не root-пользователя (должно вывести целое число, отличное от нуля – например, 1000):

kubectl exec -it deployment/game-2048 -n game-2048 -- id -u

Проверьте, работает ли контейнер от имени не root-пользователя (должно вывести целое число, отличное от нуля – например, 1000):

Если все проверки пройдены, значит, вы успешно применили необходимые рекомендации по безопасности.

build-and-test-application:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: npm install, build, and test
        run: |
          npm install
          npm run build --if-present
          npm test
        working-directory: ${{ env.PROJECT_DIR }}

      - name: Snyk code test and monitoring
        run: |
          snyk test ${{ env.PROJECT_DIR }}
          snyk monitor ${{ env.PROJECT_DIR }}
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

Регулярно отслеживайте ваши проекты

Автоматизация сканирования уязвимостей, которую вы реализовали до сих пор, является хорошей отправной точкой, но не идеальной. Почему?

Одна из проблем текущего подхода заключается в том, что вы никогда не знаете, когда будут сообщены новые проблемы для ресурсов, которые вы уже развернули в своих средах. Другими словами, вы оценили риски безопасности и приняли меры по устранению проблем в определенный момент времени – при выполнении вашей автоматизации CI/CD.

Но что, если в это время будут сообщены новые проблемы, и ваше приложение снова будет уязвимым? Snyk помогает вам преодолеть эту ситуацию с помощью функции мониторинга. Функция мониторинга Snyk помогает вам решать новые уязвимости, которые постоянно раскрываются. Когда она сочетается с интеграцией Snyk Slack (объясняется в Шаг 6 – Включение уведомлений в Slack), вы можете немедленно принимать меры по устранению вновь раскрытых проблем, которые могут повлиять на ваше приложение в производственной среде.

Чтобы воспользоваться этой функцией, вам просто нужно использовать команду snyk monitor перед любыми шагами развертывания в вашем конвейере CI/CD. Синтаксис очень похож на команды snyk test (одна из крутых вещей о snyk CLI заключается в том, что он был разработан с учетом единообразия). Команда snyk monitor отправит снимок на портал Snyk cloud, и оттуда вы будете получать уведомления о вновь раскрытых уязвимостях для вашего проекта.

A more efficient approach is where you integrate vulnerability scan tools directly in your favorite IDE (or Integrated Development Environment). This way, you can detect and fix security issues ahead of time in the software development cycle.

Что касается автоматизации рабочего процесса GitHub, вы можете выполнить мониторинг вашего приложения контейнера с помощью работы проверка безопасности контейнера snyk, после тестирования на уязвимости. Ниже приведен фрагмент кода для практической реализации конвейера, использованного в этом руководстве (некоторые шаги были опущены для ясности):

  1. –file=${{ env.PROJECT_DIR }}/Dockerfile \
  2. –severity-threshold=${{ github.event.inputs.snyk_fail_threshold || env.SNYK_FAIL_THRESHOLD }} \
  3. –target-name=${{ env.PROJECT_NAME }} \
  4. –target-reference=${{ env.ENVIRONMENT }} \

–sarif-file-output=snyk-container-scan.sarif

–file=${{ env.PROJECT_DIR }}/Dockerfile

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

После выполнения команды мониторинга Snyk вы можете войти в веб-интерфейс Snyk, чтобы увидеть последний снимок и историю вашего проекта:

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

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

Далее вы будете получать уведомления в Slack на регулярной основе о вновь обнаруженных уязвимостях для вашего проекта.

Обработка исключений

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

Вы можете узнать больше о этой функции здесь.

Snyk для сред разработки

Snyk поддерживает различные среды разработки, такие как:

плагин Eclipse.

плагин JetBrains.

  • расширение Visual Studio.
  • расширение Visual Studio Code.
  • Вышеперечисленные плагины помогут вам обнаружить и исправить проблемы на ранних этапах разработки, тем самым устраняя разочарование, издержки и уязвимости в производственных системах. Кроме того, это помогает сократить количество итераций и усилий человека в долгосрочной перспективе. В качестве примера, для каждой сообщенной проблемы безопасности вашей автоматизации CI/CD вам нужно вернуться и исправить проблему в вашем коде, сделать коммит изменений, дождаться снова автоматизации CI/CD, а затем повторить в случае сбоя.
  • Из официальной документации вы можете узнать больше о этих функциях на странице Snyk для сред разработки.
  • Шаг 5 – Автоматическое запускание рабочего процесса CI/CD Snyk
  • Вы можете настроить рабочий процесс для автоматического запуска при каждом коммите или запросе на включение (PR) в основную ветку, раскомментировав следующие строки в верхней части файла game-2048-snyk.yaml:
  • После внесения изменений в файл, зафиксируйте их в основной ветке, и вы будете готовы к работе.
  • Шаг 6 – Включение уведомлений в Slack
  • Вы можете настроить Snyk для отправки уведомлений в Slack о новых уязвимостях, обнаруженных в ваших проектах, а также о новых обновлениях или исправлениях, которые стали доступными.
  • Для настройки этого вам потребуется создать вебхук в Slack. Вы можете сделать это либо через Входящие вебхуки, либо создав собственное приложение в Slack. После создания вашего URL-адреса вебхука Slack перейдите в настройки “Управление организацией”, введите URL-адрес и нажмите кнопку Подключить:

Source:
https://www.digitalocean.com/community/developer-center/using-the-snyk-vulnerability-scanning-tool