Выбор инструмента для анализа безопасности кода Terraform

Если вы озадачены выбором инструмента для статического анализа кода Terraform, то мы поможем вам с этим. Мы изучили несколько решений по анализу безопасности и конфигурации для AWS и GCP. А мотивом для этого исследования послужило желание унифицировать различные подходы инженеров Revolgy и предоставлять нашим клиентам лучшие и безопасные сервисы.

Изучение инструментов анализа безопасности кода Terraform мы начали с чтения других постов по этой теме. Но большинство из них показались нам субъективными, неполными, не отвечающими на наши вопросы или не удовлетворяющими нашим требованиям. Поэтому мы провели свое сравнение. 

(Терра) мотивация

Основной целью данного исследования был поиск лучшего варианта для включения его в наш инфраструктурный пайплайн, что помогало бы нам выявлять проблемы безопасности в коде Terraform, описывающим инфраструктуру AWS и GCP. По этой причине мы не включили в это сравнение инструменты форматирования и линтеры, такие как tflint. Также мы оставили за рамками такие фреймворки как conftest, kitchen-terraform, terrafirma, terraform-compliance и terratest. И не акцентировали внимание на дополнительном тестировании Kubernetes, Ansible и других IaC-платформ. Это все интересные инструменты (и мы знаем, что, поработав с ними, мы могли бы их использовать для анализа безопасности), но есть другие решения, ориентированные на эту конкретную задачу, которые более просты в использовании.

В итоге мы решили сравнить следующие инструменты: checkov, snyk, terrascan и tfsec.

Сравниваемые характеристики

Мы сравнивали по следующим критериям (упорядочены по приоритету):

1. Возможность анализа кода Terraform, описывающего ресурсы AWS и GCP, на наличие проблем безопасности.

2. Качество обнаруженных проблем безопасности (положительные и ложноположительные результаты), а также ссылки на документацию AWS/GCP и Terraform.

3. Лицензия и цены.

4. Возможность ручного запуска по требованию.

5. Возможность запуска в пайплайне GitLab (прямая интеграция и / или вывод JUnitXML).

6. Возможность фильтровать правила / игнорировать определенные результаты (для уменьшения ложных срабатываний или принятия риска).

7. Возможность добавлять и разрабатывать собственные правила безопасности.

8. Возможность вывода результатов в машиночитаемый формат, такой как JSON, XML или CSV для возможных интеграций (с ELK-стеком, DefectDojo и т.п.).

Сравнение функциональности

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

Checkov

Checkov обеспечивает очень простое сканирование каталога репозитория с возможностью добавлениея ваших собственных проверок. Проверки написаны на python, поэтому (в отличие от tfsec) потребуются некоторые навыки программирования. Если у вас недостаточно таких навыков, то можно использовать интуитивно понятный конструктор политик в UI, предлагающий несколько бенчмарков и поддержку стандартов, таких как HIPAA, CIS, NIST. Результаты отображаются на дашборде.

Checkov поддерживает выполнение/игнорирование определенных тестов:

checkov -d . --check CKV_AWS_20,CK_AWS_52 
checkov -d . --skip-check CK_AWS_52,CK_AWS_52

В веб-интерфейсе Checkov есть очень хорошее описание порядка действий для исправления ошибок через интерфейс командной строки. Для отображения ссылок на документацию по исправлению ошибок используется API Bridgecrew. Чтобы пропустить этот вызов API, вы можете использовать флаг

--no-guide.

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

Terrascan

Аналогично другим тестируемым инструментам terrascan поддерживает около 500 политик. У него есть несколько интересных функций, таких как анализ Helm v3 и Kustomize v3. Очень многообещающе выглядит работа в качестве сервера API. Если вы поддерживаете DevSecOps-пайплайн, то этот инструмент для вас.

Terrascan также доступен как GitHub Action. Для подключения к GitLab или GitHub через ssh можно использовать файл known_hosts. Terrascan клонирует код из репозитория в контейнер и анализирует его. Идея API-сервера и контейнера может быть объединена при использовании AWS EKS (или GKE) или ECS.

Terrascan очень плохо справляется с определением задач и описанием исправлений. Плохо работает с кодом GCP. В результатах отсутствуют ссылки на дополнительную справку или примеры лучших практик. Есть Notifier, предоставляющий веб-хуки для результатов.

tfsec

tfsec дает неплохие рекомендации по исправлению проблем со ссылками на документацию AWS, GCP или Terraform. Как и в других инструментах из нашей выборки, в нем не учитывается серьезность проблемы. Очень хорошо помогают писать безопасный код приводимые примеры.

Стоит упомянуть функциональность PR-комментариев: добавление комментария к любой части кода, которая не проходит проверки tfsec. Важной дополнительной фичей является возможность создавать собственные проверки. Эти проверки описываются в JSON или YAML, поэтому вам не нужно писать дополнительный код Go.

Если вы используете докеризованный пайплайн, то можно запускать tfsec в докере, и не только tfsec. Благодаря поддержке образов контейнеров Lambda AWS, это становится очень интересным для нативного бессерверного сканирования DevSecOps.

Snyk

Snyk — это фантастический инструмент, когда вам нужно больше, чем анализ Terraform. Snyk анализирует состав программного обеспечения, конфигурацию Kubernetes и т. д. Что касается Terraform, то производительность здесь очень хорошая, но описание проблем расплывчато и отсутствуют ссылки на документацию AWS / GCP / Terraform. В итоговом отчете есть ссылки на конкретную строку, ресурс и атрибут в Terraform, что просто замечательно для быстрого ревью кода.

Импорт репозитория очень прост: предоставление доступа для чтения к репозиторию осуществляется через определение областей действия ключей GitLab API. Проблема возникает при добавлении новых файлов Terraform, так как требуется повторный импорт репозитория / проекта. Функция мониторинга в агенте Snyk хороша для SCA, но плохо работает с кодом Terraform.

Если у вас приватный репозиторий, то можно использовать брокер Snyk. Прокси брокера очень полезен, если нужно использовать публичный API и приватный код. Клиент брокера публикуется в виде образов Docker и обеспечивает безопасное подключение к локальной JIRA.

Если вы не хотите делать публичные отчеты, но в то же время получать их в красивом виде, то можете использовать snyk-to-html. Эта утилита принимает результат в формате JSON и генерирует HTML-отчет.

Ниже приведен пример использования генератора HTML-отчетов для snyk:

snyk iac test --json | snyk-to-html -o results.html

Сравнение качества анализа безопасности

Самое сложное — это корректно сравнить качество найденных проблем безопасности. Изначально для тестового набора данных мы пробовали использовать различные внутренние репозитории, но поскольку хотели, чтобы результаты были доступны сообществу и воспроизводимы, то решили использовать публичный репозиторий terragoat.

Terragoat — это репозиторий уязвимого кода terraform с ресурсами для AWS, GCP и Azure. Хотя использование наборов данных от одного из сравниваемых инструментов может показаться необъективным, но мы все же пошли этим путем и брали результаты checkov на тестах terragoat за базовый уровень, а другие показывали себя лучше, так же или хуже. Terragoat содержит наиболее часто используемые ресурсы IaC, такие как EC2, S3, IAM, RDS, EKS или их эквиваленты в GCP / Azure.

Мы написали очень простой скрипт, устанавливающий инструменты и запускающий их на коде AWS и GCP. Результаты мы сохранили в JSON, так как это был единственный общий формат вывода результатов (см. таблицу сравнения). Затем мы изменили форму результатов с помощью jq так, чтобы каждая найденная проблема содержала:

• название инструмента, который обнаружил проблему;

• место обнаружения (имя файла, ресурс, строка или диапазон строк, в которых найдена проблема);

• описание уязвимости (включая ID).

После этого мы объединили все результаты, отсортировали их по имени файла, ресурсу, инструменту и ID уязвимости. Затем началась утомительная ручная работа — сопоставление обнаруженных проблем между разными инструментами на основе местоположения и описания проблемы. Для сравнения мы выбрали очень простую метрику — количество уникальных найденных проблем:

Snyk исключительно хорошо справился с кодом AWS — обнаружил больше проблем, чем checkov. Среди проблем, которые обнаружил Snyk и не обнаружил checkov, были такие, как полностью открытый исходящий трафик, отсутствие описания групп безопасности AWS или балансировщик нагрузки, открытый в Интернет. Эти проблемы можно рассматривать скорее как предупреждения или напоминания о хорошей практике, чем реальные проблемы безопасности, но, честно говоря, во всех инструментах были подобные находки. Ни один из инструментов не смог обнаружить небезопасные протоколы или их незашифрованные версии.

Еще один интересный момент, на который следует обратить внимание: все четыре инструмента относительно одинаково работали с AWS, и было много проблем, обнаруженных тремя (7) или даже всеми четырьмя инструментами (6), в то время как для GCP было только четыре проблемы, обнаруженные тремя инструментами, и не было ни одной, которую обнаружили бы все четыре инструмента.

Еще один довольно странный момент заключается в том, что описания правил terrascan для GCP практически идентичны правилам, которые использует checkov. Совпадение?

Заключение

Все эти инструменты могут быть полезны в зависимости от конкретных требований. Также могут быть полезны и платные версии благодаря возможностям интеграции и отчетности. При поиске SAST-инструмента для IaC задайтесь вопросом: нужно ли также тестирование конфигурации kubernetes, open source-библиотек и образов docker? Подробнее об этом, возможно, будет в одном из наших будущих постов. Каков ваш выбор?

Иногда возникают ситуации, когда наши программы пытаются установиться из старых источников или делают это «бесконечно» долго, больше, чем разработчики хотят ждать. Для решения этой проблемы и других был придуман подход Immutable infrastructure, о котором мы и поговорим на двухдневном онлайн-интенсиве «Делаем immutable infrastructure с помощью Packer и Terraform». Обсудив проблему и подход, на демо мы соберем с помощью Packer образ для нашего облака и запустим наше приложение.

Перевод материала подготовлен в рамках курса «DevOps практики и инструменты».