Для получения триального ключа
заполните форму ниже
Team license
Enterprise license
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Бесплатная лицензия PVS-Studio для специалистов Microsoft MVP
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

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

Мне интересно попробовать плагин на:
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

>
>
Место SAST в Secure SDLC: 3 причины вне…

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

19 Апр 2022

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

0937_SAST_In_SSDLC_ru/image1.png

SAST (static application security testing) – подход к поиску дефектов безопасности, при котором анализируется исходный код приложения. Использование SAST позволяет обнаруживать множество потенциальных уязвимостей, которые входят в OWASP Top 10, CWE Top 25 и не только. Это возможные SQL-инъекции, XSS, SSRF, проблемы шифрования данных и т. п.

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

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

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

Чтобы оценить, сколько уязвимостей обнаруживается каждый год, достаточно посмотреть количество записей CVE (Common Vulnerabilities and Exposures). На графике ниже показано количество уязвимостей в период с 2017 по 2021 год. Статистика получена с сайта NVD (National Vulnerability Database).

0937_SAST_In_SSDLC_ru/image2.png

Наблюдается устойчивая тенденция к росту: за 5 лет количество ежегодно фиксируемых уязвимостей выросло больше, чем на 30%. Кстати, на момент написания статьи в 2022 году уже зафиксировано свыше 5 тысяч уязвимостей.

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

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

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

По данным IBM System Science Institute, относительная стоимость исправления уязвимости изменяется следующим образом:

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

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

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

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

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

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

0937_SAST_In_SSDLC_ru/image5.png

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

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

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

0937_SAST_In_SSDLC_ru/image6.png

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

0937_SAST_In_SSDLC_ru/image7.png

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

0937_SAST_In_SSDLC_ru/image8.png

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

0937_SAST_In_SSDLC_ru/image9.png

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

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

Это подтверждается исследованием "How Reliable is the Crowdsourced Knowledge of Security Implementation?". Авторы проанализировали ряд вопросов на Stack Overflow и то, насколько безопасны предложенные решения. Выводы следующие:

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

Другое исследование, "If you want, I can store the encrypted password", затрагивает тему фриланса. Из него следует, что фрилансеры реже предоставляют безопасные решения, если их явно об этом не попросить. Как и все, они не брезгуют копированием готового кода, в том числе со Stack Overflow.

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

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

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

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

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

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

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

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

Заключение

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

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

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

И всё же SAST – ещё один шаг на пути к снижению репутационных и денежных рисков, пренебрегать которым не стоит. Если вы строите SSDLC, использование SAST-инструментов должно быть обязательной частью DevSecOps-пайплайна.

По доброй традиции приглашаю подписываться на мой Twitter, чтобы не пропускать новых публикаций.

Популярные статьи по теме
Чем опасны уязвимые зависимости в проекте и как с этим помогает SCA?

Дата: 06 Сен 2022

Автор: Никита Липилин

Современные приложения почти всегда используют сторонние библиотеки. Если библиотека содержит уязвимость, то уязвимым может оказаться и использующее её приложение. Но как определить наличие таких про…
Анализ потока данных PVS-Studio распутывает всё больше связанных переменных

Дата: 08 Авг 2022

Автор: Артём Ровенский

Это вторая статья про связанные переменные и их поддержку в PVS-Studio. В этот раз мы расскажем об улучшении созданного механизма, разберём примеры из реальных проектов и увидим, какие проблемы польз…
Хочу использовать в своей команде PVS-Studio. Начальник против. Как его убедить?

Дата: 02 Авг 2022

Автор: Сергей Васильев

Вы решили внедрить PVS-Studio в свой проект. Но внезапно оказывается, что начальник против, потому что... Кстати, а почему он может быть против? Давайте попробуем разобраться и понять, как можно рабо…
Хочу использовать в своей команде PVS-Studio. Начальник против. Как его убедить?

Дата: 02 Авг 2022

Автор: Сергей Васильев

Вы решили внедрить PVS-Studio в свой проект. Но внезапно оказывается, что начальник против, потому что... Кстати, а почему он может быть против? Давайте попробуем разобраться и понять, как можно рабо…
Виды Application Security Testing. Как не запутаться среди SAST, DAST и IAST

Дата: 25 Июл 2022

Автор: Алексей Саркисов

Какие плюсы есть у SAST? Чем он отличается от DAST? Что такое IAST? Что значат все эти слова?! Об этом (и не только) расскажем в статье-разборе основных видов Application Security Testing (далее AST)…

Комментарии (0)

Следующие комментарии
Unicorn with delicious cookie
Мы используем куки, чтобы пользоваться сайтом было удобно. Хотите узнать подробнее?
Принять