Мы используем куки, чтобы пользоваться сайтом
было удобно.
Мы ответим вам на
Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.
Репутационные и денежные риски, связанные с уязвимостями, огромны. На фоне этого понятен повышенный интерес к безопасности и стремление выстроить цикл безопасной разработки (SSDLC). Сегодня мы поговорим об одном из подходов, используемых в SSDLC, – SAST.
SAST (static application security testing) – подход к поиску дефектов безопасности, при котором анализируется исходный код приложения. Использование SAST позволяет обнаруживать множество потенциальных уязвимостей, которые входят в OWASP Top 10, CWE Top 25 и не только. Это возможные SQL-инъекции, XSS, SSRF, проблемы шифрования данных и т. п.
Прежде чем перейти к вопросам внедрения SAST в DevSecOps-пайплайн, давайте остановимся на паре фактов.
Чтобы оценить, сколько уязвимостей обнаруживается каждый год, достаточно посмотреть количество записей CVE (Common Vulnerabilities and Exposures). На графике ниже показано количество уязвимостей в период с 2017 по 2021 год. Статистика получена с сайта NVD (National Vulnerability Database).
Наблюдается устойчивая тенденция к росту: за 5 лет количество ежегодно фиксируемых уязвимостей выросло больше, чем на 30%. Кстати, на момент написания статьи в 2022 году уже зафиксировано свыше 5 тысяч уязвимостей.
Помните, что уязвимости могут существовать годами до того, как станут публично известными. Взять хотя бы нашумевшую Log4Shell (CVE-2021-44228), которая была раскрыта через 8 лет после появления. Всё то время, пока уязвимость не обнаружена, она может успешно эксплуатироваться, принося убытки для бизнеса.
Что нужно предпринять? Использовать в комплексе подходы и инструменты, которые позволят обнаруживать как можно больше дефектов безопасности.
По данным IBM System Science Institute, относительная стоимость исправления уязвимости изменяется следующим образом:
После релиза исправление уязвимости обходится в 15 раз дороже, чем во время разработки, и в 100 раз дороже, чем на этапе проектирования.
В разных источниках этот график может немного отличаться. Однако общая динамика остаётся такой же: чем позже был исправлен дефект, тем дороже он обошёлся.
Что же касается абсолютных цифр, они сильно зависят от многих факторов: критичности уязвимости, сложности обновления уязвимых компонентов и пр. Уязвимости, как и ошибки, могут стоить тысячи, сотни тысяч или даже миллионы долларов. Вспомните катастрофу с запуском Ariane 5, где потери варьируются от $360 000 000 до $500 000 000. Или историю с уязвимостью в Polygon Plasma Bridge, где на кону было около $850 000 000.
Что нужно делать? Использовать инструменты и подходы, которые позволяют обнаруживать дефекты безопасности как можно раньше. Повышать квалификацию команды.
Принцип shift-left заключается в проведении тестирования как можно раньше в жизненном цикле ПО. То есть тесты на временном отрезке существования проекта должны сдвигаться влево – ближе к его началу.
Одно из преимуществ статического анализа – раннее обнаружение дефектов. Это значит, что внедрение SAST в DevSecOps-пайплайн позволит следовать принципу shift-left и обнаруживать дефекты безопасности раньше, когда исправить их дешевле и проще.
Рассмотрим пример. Для оценки потерь воспользуемся приведённым ранее графиком роста стоимости исправления дефекта безопасности. За условную единицу возьмём $100.
Итак, ваша команда разрабатывает приложение, которое в том числе работает с XML-файлами. XML-обработчик спроектирован так:
Спроектированная таким образом система может быть подвержена XXE-атаке. Если знать о проблеме и исправить её на этом же этапе, потери уже будут составлять как минимум $100.
Проанализируем сценарий, когда дефект безопасности не был обнаружен и попал в релиз.
Худший сценарий – уязвимость и эксплойт для неё обнаруживает хакер. Начинается эксплуатация уязвимости, что влечёт за собой потери. Однако ни вы, ни ваши клиенты какое-то время об этом не подозреваете.
Рано или поздно вы узнаёте об уязвимости. Какие репутационные и денежные потери понесли вы и клиенты к данному моменту – вопрос открытый. К этому добавляется необходимость закрыть уязвимость и обновить клиентское ПО. Согласно графику, потери составили $10 000. На самом деле, звучит как оптимистичная оценка.
Предположим, что в компании используется SAST-решение, которое может обнаружить эту XXE. Если SAST регулярно запускается в CI/CD, найти дефект безопасности можно раньше. В таком случае продукт с уязвимостью не попадёт к клиентам, а сам дефект безопасности не будет эксплуатироваться. Итог – в разы снизили возможные потери. Дефект безопасности обошёлся примерно в $1 600.
Однако процесс может быть выстроен ещё лучше. В таком случае SAST-решение используется не только в рамках CI/CD, но и локально – на машинах разработчиков. Это даст возможность найти XXE прямо в IDE во время разработки. Так как разработчик находится в контексте задачи, исправить проблему будет ещё проще, а следовательно – дешевле. Дефект безопасности обошёлся в $650.
Получается, что использование SAST в DevSecOps-пайплайне помогло уменьшить расходы примерно в 15 раз: с $10 000 до $650. Shift-left principle в действии.
Разработчики не только пишут код самостоятельно, но и используют готовые решения. Речь идёт не только о библиотеках, но и о фрагментах кода. Например, скопированных со Stack Overflow или из репозиториев на GitHub. Однако насколько такой код безопасен? Увы, гарантий безопасности нет.
Это подтверждается исследованием "How Reliable is the Crowdsourced Knowledge of Security Implementation?". Авторы проанализировали ряд вопросов на Stack Overflow и то, насколько безопасны предложенные решения. Выводы следующие:
Другое исследование, "If you want, I can store the encrypted password", затрагивает тему фриланса. Из него следует, что фрилансеры реже предоставляют безопасные решения, если их явно об этом не попросить. Как и все, они не брезгуют копированием готового кода, в том числе со Stack Overflow.
Кстати, про копирование кода со Stack Overflow и последствия этого есть интересная история. Речь про Razer Synapse и Docker for Windows.
Эти приложения разрабатываются разными компаниями и, казалось бы, не связаны друг с другом. Однако, если было запущено одно из приложений, другое запустить было нельзя. Почему?
Оба приложения использовали код с ошибкой, взятый со Stack Overflow.
Проблема была с получением глобального мьютекса. Из-за копирования ошибочного кода получалось, что оба независимых приложения использовали общий мьютекс. Подробнее про эту историю можно почитать в треде на Twitter.
Как может помочь SAST с небезопасным кодом, скопированном со Stack Overflow? За счёт анализа этого самого кода. Причём не обособленного и вырванного из контекста, а интегрированного в приложение.
Это особенно актуально, если вспомнить, что дефекты безопасности могут возникать на стыке компонентов. Скопированный код может не представлять опасности сам по себе, но после добавления в приложение может получиться дефект безопасности.
Использование SAST позволит обнаружить подобные проблемы за счёт анализа кода приложения целиком. При желании можно также анализировать код, написанный на заказ сторонними разработчиками, отдельно от остального.
На самом деле, внедрение SAST в процессы разработки позволяет следовать принципу shift-left ещё сильнее, чем мы рассмотрели выше. Это достигается за счёт повышения квалификации разработчиков в сфере безопасности.
Ранее мы разбирали, что использование SAST сдвигает ответственность за безопасность приложения в сторону разработки. Это происходит из-за того, что с предупреждениями SAST-решений в первую очередь работают разработчики.
Чтобы исправить дефект безопасности, разработчику нужно понять, в чём состоит проблема. Можно ли исправить SSRF, если не понимать, что это? А path traversal? XEE?
Разработчик получает предупреждение от SAST-решения, изучает суть дефекта безопасности. В этом помогает документация, сопровождающая инструмент. Экспертиза разработчика в области компьютерной безопасности возрастает. Дефект исправлен, и вероятность допустить подобную потенциальную уязвимость в будущем снижается.
Так как разработчик знает, из-за каких условий может возникнуть уязвимость, он постарается их избежать.
Таким образом, по мере повышения экспертности команда будет стремиться предотвращать дефекты безопасности ещё до этапа написания кода. Это снижает стоимость разработки ПО ещё больше.
Стоит отметить, что разработчики SAST-решений часто ведут блоги, в которых описывают best practices использования их инструментов, написания безопасного кода и не только. Их чтение может стать для команды дополнительной точкой роста.
Подведём итог. Использование SAST позволяет снижать денежные и репутационные риски. Это достигается за счёт:
Несмотря на перечисленные достоинства, нужно помнить один факт. SAST не панацея. Он не защитит вас от 100% уязвимостей, не избавит от всех проблем. На одном лишь SAST не удастся выстроить SSDLC.
И всё же SAST – ещё один шаг на пути к снижению репутационных и денежных рисков, пренебрегать которым не стоит. Если вы строите SSDLC, использование SAST-инструментов должно быть обязательной частью DevSecOps-пайплайна.
По доброй традиции приглашаю подписываться на мой Twitter, чтобы не пропускать новых публикаций.
0
0
0
0