# Место SAST в Secure SDLC: 3 причины внедрения в DevSecOps\-пайплайн

Репутационные и денежные риски, связанные с уязвимостями, огромны\. На фоне этого понятен повышенный интерес к безопасности и стремление выстроить цикл безопасной разработки \(SSDLC\)\. Сегодня мы поговорим об одном из подходов, используемых в SSDLC, — SAST\.

![0937_SAST_In_SSDLC_ru/image1.png](https://import.viva64.com/docx/blog/0937_SAST_In_SSDLC_ru/image1.png)

SAST \(static application security testing\) — подход к поиску дефектов безопасности, при котором анализируется исходный код приложения\. Использование SAST позволяет обнаруживать множество потенциальных уязвимостей, которые входят в [OWASP Top 10](https://owasp.org/Top10/), [CWE Top 25](https://cwe.mitre.org/top25/archive/2021/2021_cwe_top25.html) и не только\. Это возможные SQL\-инъекции, XSS, SSRF, проблемы шифрования данных и т\. п\. 

Прежде чем перейти к вопросам внедрения SAST в DevSecOps\-пайплайн, давайте остановимся на паре фактов\.

## Количество уязвимостей растёт\. Стоимость их исправления — тоже

### Факт \#1: с каждым годом уязвимостей становится больше

Чтобы оценить, сколько уязвимостей обнаруживается каждый год, достаточно посмотреть количество записей CVE \(Common Vulnerabilities and Exposures\)\. На графике ниже показано количество уязвимостей в период с 2017 по 2021 год\. Статистика [получена](https://nvd.nist.gov/vuln/search/statistics?form_type=Basic&results_type=statistics&search_type=all&isCpeNameSearch=false) с сайта NVD \(National Vulnerability Database\)\.

![0937_SAST_In_SSDLC_ru/image2.png](https://import.viva64.com/docx/blog/0937_SAST_In_SSDLC_ru/image2.png)

Наблюдается устойчивая тенденция к росту: ежегодно количество фиксируемых уязвимостей растёт\. А 2024 год побил рекорды\.

Помните, что уязвимости могут существовать годами до того, как станут публично известными\. Взять хотя бы нашумевшую [Log4Shell \(CVE\-2021\-44228\)](https://en.wikipedia.org/wiki/Log4Shell), которая была раскрыта через 8 лет после появления\. Всё то время, пока уязвимость не обнаружена, она может успешно эксплуатироваться, принося убытки для бизнеса\.

**Что нужно предпринять?** Использовать в комплексе подходы и инструменты, которые позволят обнаруживать как можно больше дефектов безопасности\.

### Факт \#2: чем позже найдена уязвимость, тем дороже её исправление

По [данным](https://www.researchgate.net/publication/255965523_Integrating_Software_Assurance_into_the_Software_Development_Life_Cycle_SDLC) IBM System Science Institute, относительная стоимость исправления уязвимости изменяется следующим образом:

![0937_SAST_In_SSDLC_ru/image3.png](https://import.viva64.com/docx/blog/0937_SAST_In_SSDLC_ru/image3.png)

После релиза исправление уязвимости обходится в 15 раз дороже, чем во время разработки, и в 100 раз дороже, чем на этапе проектирования\.

В разных источниках этот график может немного отличаться\. Однако общая динамика остаётся такой же: чем позже был исправлен дефект, тем дороже он обошёлся\.

Что же касается абсолютных цифр, они сильно зависят от многих факторов: критичности уязвимости, сложности обновления уязвимых компонентов и пр\. Уязвимости, как и ошибки, могут стоить тысячи, сотни тысяч или даже миллионы долларов\. Вспомните катастрофу с запуском Ariane 5, где потери варьируются от $360 000 000 до $500 000 000\. Или историю с уязвимостью в Polygon Plasma Bridge, где на кону было около $850 000 000\.

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

## 3 причины внедрения SAST в SSDLC

### 1\. Shift\-left principle

Принцип shift\-left заключается в проведении тестирования как можно раньше в жизненном цикле ПО\. То есть тесты на временном отрезке существования проекта должны сдвигаться влево — ближе к его началу\.

![0937_SAST_In_SSDLC_ru/image4.png](https://import.viva64.com/docx/blog/0937_SAST_In_SSDLC_ru/image4.png)

Одно из преимуществ статического анализа — раннее обнаружение дефектов\. Это значит, что внедрение SAST в DevSecOps\-пайплайн позволит следовать принципу shift\-left и обнаруживать дефекты безопасности раньше, когда исправить их дешевле и проще\. 

Рассмотрим пример\. Для оценки потерь воспользуемся приведённым ранее графиком роста стоимости исправления дефекта безопасности\. За условную единицу возьмём $100\.

Итак, ваша команда разрабатывает приложение, которое в том числе работает с XML\-файлами\. XML\-обработчик спроектирован так:

* используемый XML\-парсер обрабатывает внешние сущности без ограничений;
* на вход этому парсеру передаются данные от пользователя \(taint\-данные\)\.

Спроектированная таким образом система может быть подвержена XXE\-атаке\. Если знать о проблеме и исправить её на этом же этапе, потери уже будут составлять как минимум $100\.

![0937_SAST_In_SSDLC_ru/image5.png](https://import.viva64.com/docx/blog/0937_SAST_In_SSDLC_ru/image5.png)

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

Худший сценарий — уязвимость и эксплойт для неё обнаруживает хакер\. Начинается эксплуатация уязвимости, что влечёт за собой потери\. Однако ни вы, ни ваши клиенты какое\-то время об этом не подозреваете\.

Рано или поздно вы узнаёте об уязвимости\. Какие репутационные и денежные потери понесли вы и клиенты к данному моменту — вопрос открытый\. К этому добавляется необходимость закрыть уязвимость и обновить клиентское ПО\. Согласно графику, потери составили $10 000\. На самом деле, звучит как оптимистичная оценка\.

![0937_SAST_In_SSDLC_ru/image6.png](https://import.viva64.com/docx/blog/0937_SAST_In_SSDLC_ru/image6.png)

Предположим, что в компании используется SAST\-решение, которое может обнаружить эту XXE\. Если SAST регулярно запускается в CI/CD, найти дефект безопасности можно раньше\. В таком случае продукт с уязвимостью не попадёт к клиентам, а сам дефект безопасности не будет эксплуатироваться\. Итог — _в разы_ снизили возможные потери\. Дефект безопасности обошёлся примерно в $1 600\.

![0937_SAST_In_SSDLC_ru/image7.png](https://import.viva64.com/docx/blog/0937_SAST_In_SSDLC_ru/image7.png)

Однако процесс может быть выстроен ещё лучше\. В таком случае SAST\-решение используется не только в рамках CI/CD, но и локально — на машинах разработчиков\. Это даст возможность найти XXE прямо в IDE во время разработки\. Так как разработчик находится в контексте задачи, исправить проблему будет ещё проще, а следовательно — дешевле\. Дефект безопасности обошёлся в $650\.

![0937_SAST_In_SSDLC_ru/image8.png](https://import.viva64.com/docx/blog/0937_SAST_In_SSDLC_ru/image8.png)

Получается, что использование SAST в DevSecOps\-пайплайне помогло уменьшить расходы примерно в 15 раз: с $10 000 до $650\. Shift\-left principle в действии\.

![0937_SAST_In_SSDLC_ru/image9.png](https://import.viva64.com/docx/blog/0937_SAST_In_SSDLC_ru/image9.png)

### 2\. Дефекты безопасности в готовых решениях

Разработчики не только пишут код самостоятельно, но и используют готовые решения\. Речь идёт не только о библиотеках, но и о фрагментах кода\. Например, скопированных со Stack Overflow или из репозиториев на GitHub\. Однако насколько такой код безопасен? Увы, гарантий безопасности нет\.

Это подтверждается исследованием "[How Reliable is the Crowdsourced Knowledge of Security Implementation?](https://arxiv.org/pdf/1901.01327.pdf)"\. Авторы проанализировали ряд вопросов на Stack Overflow и то, насколько безопасны предложенные решения\. Выводы следующие:

* 644 из 1429 проанализированных ответов \(45%\) содержат небезопасные решения;
* в среднем посты с небезопасными решениями более популярны, набирают больше комментариев и просмотров;
* "принятые" ответы необязательно содержат безопасный код\.

Другое исследование, "[If you want, I can store the encrypted password](https://dl.acm.org/doi/pdf/10.1145/3290605.3300370)", затрагивает тему фриланса\. Из него следует, что фрилансеры реже предоставляют безопасные решения, если их явно об этом не попросить\. Как и все, они не брезгуют копированием готового кода, в том числе со Stack Overflow\.

Кстати, про копирование кода со Stack Overflow и последствия этого есть интересная история\. Речь про Razer Synapse и Docker for Windows\. 

Эти приложения разрабатываются разными компаниями и, казалось бы, не связаны друг с другом\. Однако, если было запущено одно из приложений, другое запустить было нельзя\. Почему? 

Оба приложения использовали код с ошибкой, взятый со Stack Overflow\.

Проблема была с получением глобального мьютекса\. Из\-за копирования ошибочного кода получалось, что оба _независимых_ приложения использовали _общий_ мьютекс\. Подробнее про эту историю можно почитать в [треде на Twitter](https://twitter.com/Foone/status/1229641258370355200)\.

Как может помочь SAST с небезопасным кодом, скопированном со Stack Overflow? За счёт анализа этого самого кода\. Причём не обособленного и вырванного из контекста, а интегрированного в приложение\.

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

![0937_SAST_In_SSDLC_ru/image10.png](https://import.viva64.com/docx/blog/0937_SAST_In_SSDLC_ru/image10.png)

Использование SAST позволит обнаружить подобные проблемы за счёт анализа кода приложения целиком\. При желании можно также анализировать код, написанный на заказ сторонними разработчиками, отдельно от остального\.

### 3\. Повышение security\-квалификации разработчиков

На самом деле, внедрение SAST в процессы разработки позволяет следовать принципу shift\-left ещё сильнее, чем мы рассмотрели выше\. Это достигается за счёт повышения квалификации разработчиков в сфере безопасности\.

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

Чтобы исправить дефект безопасности, разработчику нужно понять, в чём состоит проблема\. Можно ли исправить SSRF, если не понимать, что это? А path traversal? XEE?

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

Так как разработчик знает, из\-за каких условий может возникнуть уязвимость, он постарается их избежать\. 

Таким образом, по мере повышения экспертности команда будет стремиться предотвращать дефекты безопасности ещё _до этапа написания кода_\. Это снижает стоимость разработки ПО ещё больше\.

![0937_SAST_In_SSDLC_ru/image11.png](https://import.viva64.com/docx/blog/0937_SAST_In_SSDLC_ru/image11.png)

Стоит отметить, что разработчики SAST\-решений часто ведут [блоги](https://pvs-studio.ru/ru/blog/), в которых описывают best practices использования их инструментов, написания безопасного кода и не только\. Их чтение может стать для команды дополнительной точкой роста\. 

## Заключение

Подведём итог\. Использование SAST позволяет снижать денежные и репутационные риски\. Это достигается за счёт:

* принципа shift\-left\. Дефекты безопасности обнаруживаются на ранних этапах, когда их стоимость минимальна;
* анализа стороннего кода\. Код, скопированный со Stack Overflow, может быть небезопасным\. То же с кодом, написанным на заказ\. Следовательно, полезно проверять его на наличие потенциальных уязвимостей;
* обучения команды\. Чтобы исправить проблему, найденную SAST\-инструментом, нужно в ней разобраться\. Итог — прокачка скиллов в сфере безопасности и, как следствие, ещё больший shift\-left сдвиг\. Хорошая документация к обнаруживаемым дефектам ускорит этот процесс\.

Несмотря на перечисленные достоинства, нужно помнить один факт\. SAST не панацея\. Он не защитит вас от 100% уязвимостей, не избавит от всех проблем\. На одном лишь SAST не удастся выстроить SSDLC\.

И всё же SAST — ещё один шаг на пути к снижению репутационных и денежных рисков, пренебрегать которым не стоит\. Если вы строите SSDLC, использование [SAST\-инструментов](https://pvs-studio.ru/ru/pvs-studio/) должно быть обязательной частью DevSecOps\-пайплайна\.