Тестирование кода — одна из первых линий защиты от внедрения уязвимостей, утечки секретов в рабочую среду или общедоступные источники, а также общих ошибок. Проблема с тестированием состоит в том, что оно может не просто замедлить работу команды, но и стать пустой тратой времени, если не реализовано правильно.
В этой статье мы собираемся объяснить, что такое тестирование кода, почему вам не следует откладывать его внедрение, а также какие подходы вы можете использовать.
DevSecOps и тестирование кода
Основная цель безопасности — снизить риск для конкретной организации. Каждая компания сталкивается с уникальными рисками, но есть определенные подходы, которые большинству организаций следует по крайней мере рассмотреть.
Взглянем на шпаргалку по жизненному циклу DevSecOps. После того, как мы прошли этап планирования, разработчики начинают писать код, а нашим инженерам по инфраструктуре нужно приступить к настройке облачных ресурсов (например) для поддержки этих приложений. Вам придется расставить приоритеты и составить дорожную карту, с которой остальная часть организации должна согласиться.
На этом фоне также забавно и то, что более 60% разработчиков в опросе GitLab в 2020 году, заявили, что они не проводят никакого статического тестирования безопасности приложений (SAST).
Одна из основных причин состоит в том, что реализовать SAST непросто. Требуются месяцы усилий, чтобы собрать всех на одной странице, выполнить тесты, настроить параметры на основе результатов этих тестов и т.д.… пока это не станет действительно полезным решением, а не чем-то, что мешает разработчикам.
В конечном счете, мы хотим, чтобы SAST помогал нам:
Если он не достигает всех этих целей, тогда проблема в реализации.
Хотя многие решения SAST подразумевают сканирование секретов, существуют также и отдельные аналогичные инструменты. Сканирование IaC просматривает файлы конфигурации инфраструктуры на наличие известных уязвимостей.
Если вы используете что-то вроде Terraform, Ansible, CloudFormation, Kubernetes и т.д., вы можете извлечь из этого пользу. Если вы используете контейнеры, вы также можете воспользоваться сканированием образов контейнеров.
Версии исходного кода
Предположим, что ваша организация еще не использует систему контроля версий, такую как Git. В таком случае это одно из самых важных технологических изменений, которые вы могли бы внедрить.
После того, как вы реализовали управление версиями исходного кода, вы можете предоставить разработчикам сведения о безопасности непосредственно там, где они работают (в системе контроля версий), вместо того, чтобы заставлять их работать на еще одной платформе.
Именно поэтому такие приложения, как Spacelift, напрямую интегрируются с GitHub. Так вы можете контролировать и получать представление о своих стеках, модулях, политиках и общих ресурсах из одного центра управления.
После этого приходит время внедрить стандарты и проверки кода.
Внедрение стандартов и проверка кода
В идеале на этапе планирования конвейера DevSecOps организация должна составить документы технического проектирования.
Отличный способ обеспечить безопасность с самого начала — стандартизировать встраивание контрольных вопросов непосредственно в эти документы.
Примеры таких контрольных вопросов:
Это, конечно, всего лишь несколько примеров вопросов, которые мы должны задавать и на которые должны отвечать до начала работы.
Но эти вопросы универсальны:
Дополнительным преимуществом является то, что их можно использовать во время проверки кода и/или для настройки автоматических тестов, поскольку мы можем следить за тем, чтобы конкретные узлы работали так, как надо.
Говоря о код-ревью…
Типичный процесс проверки кода заключается в том, чтобы группа разработчиков провела проверку кода для pull request (PR) до того, как они объединят свой код. Вместо того, чтобы качество кода полностью зависело от человека, было бы неплохо разработать контрольный список.
Этот контрольный список будет частично сформирован теми самыми вопросами, на которые даны ответы в документе с техническими характеристиками. Кроме того, вы можете создать контрольный список на основе используемых языков, поскольку каждый язык уникален.
Примеры контрольных списков и более подробную информацию о том, как реализовать проверку безопасности кода, можно найти на ресурсе OWASP.
Чтобы улучшить проверку кода, вы можете:
И помните:
Линтинг
В дополнение к проверкам кода нам поможет и решение для линтинга. Это «двоюродные братья» инструментов SAST, потому что линтинг — статический анализ кода для выявления стилистических и программных ошибок.
Это делает инструмент lint базовым статическим анализатором кода, и хотя его можно использовать автономно, его также часто можно интегрировать непосредственно в инструменты SAST.
Линтинг — важный шаг, потому что он улучшает общее состояние вашей кодовой базы. Соответственно, он проходит еще до проверки кода и тестирования, что помогает облегчить нагрузку на рецензентов и снижает вероятность того, что во время тестирования будут косяки.
Линтеры могут быть напрямую интегрированы как плагины в вашу любимую IDE (интегрированную среду разработки), например Visual Studio (вот пример для Python linting и JavaScript linting), и они могут предупреждать вас о проблемах еще до того, как вы запустите или зафиксируете свой код.
Кроме того, линтеры можно настроить для работы с git-хуками, а это значит, что вы даже можете анализировать сообщения коммитов.
Это отличная отправная точка, которая обеспечит ранние преимущества и создаст основу для более тщательного решения.
Резюме
После того, как у вас есть версии исходного кода, стандарты и проверки кода, инвестиции в SAST на пути к безопасности станут отличным вложением. Это займет время и потребует терпения, но ваша цель должна заключаться в том, чтобы внедрить эти сканеры в конвейер CI/CD, чтобы вы могли настроить постоянную обратную связь для разработчиков и использовать это.