Авто и ручное тестирование кода в DevSecOps

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

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

DevSecOps и тестирование кода

Основная цель безопасности — снизить риск для конкретной организации. Каждая компания сталкивается с уникальными рисками, но есть определенные подходы, которые большинству организаций следует по крайней мере рассмотреть.

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

На этом фоне также забавно и то, что более 60% разработчиков в опросе GitLab в 2020 году, заявили, что они не проводят никакого статического тестирования безопасности приложений (SAST).

Одна из основных причин состоит в том, что реализовать SAST непросто. Требуются месяцы усилий, чтобы собрать всех на одной странице, выполнить тесты, настроить параметры на основе результатов этих тестов и т.д.… пока это не станет действительно полезным решением, а не чем-то, что мешает разработчикам.

В конечном счете, мы хотим, чтобы SAST помогал нам:

1. Внедрить ранние проверки безопасности
2. Сократить человеческие ошибки
3. Устранять проблемы разработки за меньшее время
4. Отслеживать ценные показатели

Если он не достигает всех этих целей, тогда проблема в реализации.

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

Если вы используете что-то вроде Terraform, Ansible, CloudFormation, Kubernetes и т.д., вы можете извлечь из этого пользу. Если вы используете контейнеры, вы также можете воспользоваться сканированием образов контейнеров.

Версии исходного кода

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

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

Именно поэтому такие приложения, как Spacelift, напрямую интегрируются с GitHub. Так вы можете контролировать и получать представление о своих стеках, модулях, политиках и общих ресурсах из одного центра управления.

После этого приходит время внедрить стандарты и проверки кода.

Внедрение стандартов и проверка кода

В идеале на этапе планирования конвейера DevSecOps организация должна составить документы технического проектирования.

Отличный способ обеспечить безопасность с самого начала — стандартизировать встраивание контрольных вопросов непосредственно в эти документы.

Примеры таких контрольных вопросов:

• Принимает ли эта служба какие-либо данные от конечных пользователей? Если да, то что вы используете для защиты от распространенных атак с помощью инъекций, таких как XSS, SQL-инъекции и т.д.?
• Обрабатывает ли эта служба/хранит ли какую-либо конфиденциальную информацию о пользователях или клиентах? Если да, то он зашифрован?
• Какие алгоритмы используются, если требуется шифрование/дешифрование/хеширование?
• Требует ли служба использования каких-либо секретов (для соединения с базой данных), и если да, то исходит ли секрет от решения по управлению секретами?
• Как будет проходить мониторинг и оповещение для этой службы?

Это, конечно, всего лишь несколько примеров вопросов, которые мы должны задавать и на которые должны отвечать до начала работы.

Но эти вопросы универсальны:

1. Они помогают инженерам вспоминать о безопасности, пока они уже думают о техническом дизайне.
2. Они помогают службе безопасности собирать информацию на самых ранних этапах процесса.
3. Они дают службе безопасности возможность выделить проблемные области или дать рекомендации до того, как будет написана хоть одна строка кода.
4. Они производят информацию, которая может быть использованы в моделировании угроз организации.

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

Говоря о код-ревью…

Типичный процесс проверки кода заключается в том, чтобы группа разработчиков провела проверку кода для pull request (PR) до того, как они объединят свой код. Вместо того, чтобы качество кода полностью зависело от человека, было бы неплохо разработать контрольный список.

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

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

Чтобы улучшить проверку кода, вы можете:

1. Стандартизируйте встраивание контрольных вопросов в техническую и проектную документацию.
2. Создавайте контрольные списки проверки кода на основе этих контрольных вопросов и конкретных языков.
3. Обучайте своих разработчиков основам моделирования угроз, проверки кода и оценки рисков

И помните:

1. Результаты сканирования SAST не должны блокировать продвижение кода. Они должны только информировать.
2. SAST следует развертывать поэтапно, начиная с одного или двух репозиториев, и/или запускать его выборочно вручную.
3. Настройки SAST должны быть основаны на данных, чтобы свести к минимуму ложноположительные и ложноотрицательные результаты, что представляет собой тонкий баланс, для уточнения которого требуется время.
4. Только после того, как результаты SAST станут постоянно полезными, их следует вводить в каждый PR.

Линтинг

В дополнение к проверкам кода нам поможет и решение для линтинга. Это «двоюродные братья» инструментов SAST, потому что линтинг — статический анализ кода для выявления стилистических и программных ошибок.

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

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

Линтеры могут быть напрямую интегрированы как плагины в вашу любимую IDE (интегрированную среду разработки), например Visual Studio (вот пример для Python linting и JavaScript linting), и они могут предупреждать вас о проблемах еще до того, как вы запустите или зафиксируете свой код.

Кроме того, линтеры можно настроить для работы с git-хуками, а это значит, что вы даже можете анализировать сообщения коммитов.

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

Резюме

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