Безопасный SDLC, инструменты SAST и DAST

Безопасный жизненный цикл разработки программного обеспечения (SSDLC) включает мероприятия по обеспечению Security на каждом этапе разработки программного обеспечения — от формирования требований до проектирования, написания кода, тестирования, развёртывания и сопровождения. Традиционный SDLC рассматривает Security как контрольный барьер на последнем этапе, что дорого и неэффективно. Философия безопасного SDLC заключается в поиске и устранении уязвимостей как можно раньше, поскольку исправление дефектов, обнаруженных на этапе проектирования, обходится значительно дешевле, чем исправление дефектов, найденных в рабочей среде.

Сдвиг влево означает перенос Security на более ранние этапы (влево на временной шкале разработки), а не добавление Security в самом конце. На практике это означает включение требований Security в пользовательские истории, проведение моделирования угроз на этапе проектирования, выполнение проверки кода и SAST во время разработки, а также запуск DAST перед выпуском. Team, использующие сдвиг влево, обнаруживают уязвимости тогда, когда их дешевле всего исправить, — во время разработки, а не в рабочей среде.

Моделирование угроз систематически выявляет и документирует угрозы Security на этапе проектирования. Модель STRIDE распределяет угрозы по следующим категориям: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service и Elevation of Privilege. PASTA (Process for Attack Simulation and Threat Analysis) — методология, ориентированная на риски и моделирующая цели Attacker. Модели угроз позволяют определить приоритетные меры защиты ещё до написания первой строки кода.

SAST (тестирование методом белого ящика) анализирует исходный код, байт-код или двоичные файлы без запуска приложения и ищет шаблоны кода, связанные с известными уязвимостями. Инструменты SAST могут быстро просканировать всю кодовую базу и сообщить о таких проблемах, как зашитые в код учётные данные, точки внедрения SQL и небезопасная десериализация. Они запускаются внутри IDE или конвейера CI и указывают обнаруженные проблемы с номерами файлов и строк, что упрощает их устранение.

Ключевое ограничение SAST — склонность выдавать ложные срабатывания, то есть помечать безопасный код как уязвимый. Такая усталость от оповещений приводит к тому, что разработчики отклоняют результаты без проверки. Инструменты SAST также не могут обнаруживать проблемы конфигурации во время выполнения, недостатки Authentication, зависящие от поведения во время выполнения, или уязвимости в вызовах сторонних API. SAST наиболее эффективен в сочетании с обучением разработчиков, чтобы результаты правильно сортировались по приоритету.

DAST (тестирование методом чёрного ящика) проверяет работающее приложение, отправляя атакующие полезные нагрузки на его HTTP-конечные точки и анализируя ответы на наличие признаков уязвимостей. DAST не требует доступа к исходному коду — он проверяет приложение так, как это делал бы Attacker. Этот метод особенно хорошо выявляет проблемы во время выполнения, такие как обход Authentication, XSS, отражённый в ответах, и неправильную Configuration Server. К инструментам DAST относятся OWASP ZAP, Burp Suite и Netsparker.

SAST и DAST дополняют друг друга, а не конкурируют. SAST рано обнаруживает проблемы на уровне кода и интегрируется с IDE, но не видит поведение во время выполнения. DAST выявляет уязвимости во время выполнения и не требует исходного кода, но не может просканировать участки кода, которые не вызываются его автоматизированными проверками. Совместное использование обоих подходов — SAST в конвейере CI и DAST в тестовой среде — позволяет максимально охватить уязвимости во всём SDLC.

IAST объединяет особенности SAST и DAST, внедряя средства наблюдения в приложение во время выполнения. Агент IAST работает внутри приложения (на Server) и отслеживает выполнение кода по мере прохождения через него тестового трафика. Он может проследить путь загрязнённых пользовательских данных через участки кода до чувствительных точек назначения, выявляя уязвимости с меньшим числом ложных срабатываний, чем обычный SAST. IAST особенно эффективен в приложениях на Java и .NET и естественным образом интегрируется в запуски функциональных тестов.

Анализ состава программного обеспечения (SCA) выявляет библиотеки с открытым исходным кодом и сторонние зависимости в приложении и сверяет их с базами данных уязвимостей (NVD, OSV). Современные приложения могут подключать сотни зависимостей, в том числе транзитивных, поэтому инструменты SCA, такие как OWASP Dependency-Check, Snyk и Renovate, необходимы для обнаружения известных CVEs до того, как Attacker воспользуются ими в Вашей цепочке поставок.

Интеграция инструментов Security в конвейеры CI/CD гарантирует, что в рабочую среду не попадёт код, не прошедший контроль Security. Типичный конвейер DevSecOps выполняет следующие действия: SAST при каждом коммите, SCA при изменении зависимостей, сканирование образов Container перед отправкой в реестр, сканирование IaC для Terraform/CloudFormation и DAST в тестовом развёртывании. Непройденные проверки Security блокируют сборку, формируя культуру Security по умолчанию.

Автоматизированные инструменты не могут заменить проводимую людьми проверку кода, сосредоточенную на логике Security. Проверка коллегами должна подтверждать, что проверки Authentication и авторизации находятся в правильных местах, обработка ошибок не раскрывает конфиденциальную Information, криптографические функции используют одобренные алгоритмы и параметры, а бизнес-логику нельзя обойти. Ответственные за Security внутри команд разработки — разработчики, прошедшие обучение по Security, — связывают Team Security и инженеров.

Проверьте своё понимание концепций CompTIA Security+ (SY0-701) из этого урока.

В этом уроке Вы узнали, что безопасный SDLC включает Security на всех этапах разработки, а не добавляет её в самом конце, SAST анализирует код без выполнения, а DAST проверяет работающие приложения, а SCA выявляет уязвимые зависимости с открытым исходным кодом, а контроль Security в CI/CD автоматически обеспечивает соблюдение требований. Далее мы рассмотрим службы каталогов с LDAP и Active Directory.