SAST, DAST, SCA, SCS: как обеспечить безопасность разработки на всех этапах

SAST, DAST, SCA, SCS: как обеспечить безопасность разработки на всех этапах

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

 

 

 

 

 

 

  1. Введение
  2. Необходимость анализа кода приложений
  3. Актуальные требования к безопасной разработке кода
  4. Технологии анализа безопасности приложений
    1. 4.1. Статический анализ кода (SAST)
    2. 4.2. Динамический анализ кода (DAST)
    3. 4.3. Анализ состава программного обеспечения (SCA)
    4. 4.4. Анализ безопасности цепочки поставок ПО (SCS)
  5. Комплексный подход к безопасной разработке
    1. 5.1. Комплексный анализ безопасности на примере Solar appScreener
    2. 5.2. Основные функциональные возможности Solar appScreener
  6. Выводы

Введение

По статистике государственной базы данных США по уязвимостям (NVD) можно проследить, как из года в год увеличивается число зарегистрированных брешей. Так, например, за 2021 год было зарегистрировано 20157 уязвимостей, за 2022-й — 25050, а за 2023-й — уже 28834. Эксплуатация уязвимостей и недекларированных возможностей (НДВ), присутствующих в программном обеспечении (ПО), может привести к нарушению целостности, конфиденциальности и доступности информации.

Зачастую разработчики ПО используют заимствованный код (библиотеки), где тоже могут содержаться уязвимости и НДВ, выявить и устранить которые ещё труднее, чем изъяны в собственном программном коде. Злоумышленники могут намеренно создавать и размещать в репозиториях поддельные библиотеки со вредоносным кодом, давая им почти такие же названия, как у оригинальных. Если такая библиотека содержит необходимую функциональность и работает стабильно, то заметить подмену без специальных инструментов практически невозможно.

Также недобросовестные разработчики могут внедрять в пакеты бэкдоры. Например, в марте 2024 года была опубликована информация о критической уязвимости CVE-2024-3094, связанной со внедрением бэкдора в пакет XZ Utils. Используя методы социальной инженерии, злоумышленник втёрся в доверие к разработчику, сопровождающему пакет XZ Utils, и внедрил туда вредоносный код, который затем попал в дистрибутивы Linux. Ранее, в декабре 2021 года, не меньший резонанс вызвало выявление уязвимости CVE-2021-44228 в библиотеке Log4j, используемой в тысячах крупных приложений, таких как VMware, Steam и др. Эта уязвимость вызвала огромное количество атак на веб-серверы.

Для решения таких проблем проводится тестирование безопасности приложений (Application Security Testing, AST), которое позволяет выявить недостатки в программном обеспечении. AST может помочь обнаружить и устранить уязвимости во время разработки (до развёртывания в рабочей среде), а также в процессе эксплуатации. Соответственно, тестирование может проводиться как разработчиками, так и компаниями-заказчиками.

Наиболее распространёнными методами анализа приложений являются статический (Static Application Security Testing, SAST) и динамический (Dynamic Application Security Testing, DAST). Популярна также проверка состава программного обеспечения (Software Composition Analysis, SCA). В настоящее время набирает популярность новый метод — анализ безопасности цепочек поставок (Supply Chain Security, SCS).

Необходимость анализа кода приложений

Анализ кода приложений на всех этапах жизненного цикла становится всё более актуальным по ряду причин: развитие удалённых сервисов, ускорение процессов разработки, использование унаследованного ПО и важность выявления тех уязвимостей и НДВ, которые могут эксплуатироваться злоумышленником. Рассмотрим каждую причину более подробно.

В связи с активным развитием удалённых сервисов и повышением квалификации нарушителей, от наличия уязвимостей и «закладок» в коде приложения зависят работоспособность последнего, конфиденциальность данных, сохранность денег и репутации организации. Так, например, НДВ в банковских приложениях могут привести к утечке персональных данных клиентов, потере денег, а как следствие — и доверия к банку.

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

Разработка нового ПО — финансово затратный процесс для организаций, поэтому зачастую используются унаследованные (legacy) приложения, которые давно устарели. Такие системы не имеют актуальной документации, проследить происходящие в них изменения за всё время жизни невозможно. Из-за риска нарушить бизнес-процессы отказаться от них нельзя, но и устранить уязвимости в них тоже вряд ли удастся. Также тестирование унаследованных систем может быть осложнено отсутствием исходного кода.

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

Актуальные требования к безопасной разработке кода

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

  • Положение о системе сертификации средств защиты информации, утверждённое приказом ФСТЭК России от 03.04.2018 № 55.
  • ГОСТ 56939-2016 «Защита информации. Разработка безопасного программного обеспечения. Общие требования».
  • ГОСТ 58412-2019 «Защита информации. Разработка безопасного программного обеспечения. Угрозы безопасности информации при разработке программного обеспечения».
  • Положения Банка России от 04.06.2020 № 719-П, от 20.04.2021 № 757-П, от 17.04.2019 № 683-П.
  • Требования по обеспечению безопасности, утверждённые приказами ФСТЭК России от 11.02.2013 № 17, от 18.02.2013 № 21, от 25.12.2017 № 239 и т. д.

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

Так, в соответствии с ГОСТ Р 56939-2016 необходимо контролировать отсутствие НДВ в ПО («функциональных возможностей средств вычислительной техники, не описанных или не соответствующих описанным в документации, при использовании которых возможно нарушение конфиденциальности, доступности или целостности обрабатываемой информации») и обнаруживать недостатки в защищённости.

В соответствии с требованиями, которые утверждены приказами ФСТЭК России № 17, 21 и 239, необходимо анализировать возможные уязвимости используемых информационных систем, в том числе применяемых средств защиты информации, применять меры по устранению брешей и подтверждать, что в информационной системе отсутствуют уязвимости, содержащиеся в банке данных угроз безопасности информации ФСТЭК России, а также в иных источниках, или что их использование (эксплуатация) нарушителем невозможно.

Согласно стандарту Банка России в области информационной безопасности (СТО БР ИББС), следует определить, выполнять, регистрировать и контролировать процедуры анализа того, как функционирует система обеспечения ИБ, используя в том числе данные об уязвимостях.

Технологии анализа безопасности приложений

Анализ безопасности приложений (AST) — обобщающее понятие для методологий, которые помогают находить и устранять уязвимости и «закладки» в ПО.

Проведение AST невозможно без использования специализированных инструментов. Рассмотрим решения, которые позволяют протестировать ПО, начиная от этапа разработки и заканчивая началом эксплуатации, и разберёмся в их отличиях и областях применения.

Статический анализ кода (SAST)

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

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

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

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

Динамический анализ кода (DAST)

DAST — это методология тестирования ПО, при которой приложение анализируется во время выполнения.

Инструменты DAST работают без доступа к исходному коду приложения, поэтому динамический анализ также известен как тестирование по принципу «чёрного ящика». Для обнаружения уязвимостей в ПО механизмы DAST моделируют атаки на запущенное приложение. Такие решения могут обнаруживать межсайтовый скриптинг (XSS), подделку межсайтовых запросов (CSRF), SQL-инъекции и небезопасные конфигурации.

Одним из главных плюсов этого подхода является возможность обнаружения уязвимостей, которые не были заметны в процессе разработки, но могут проявить себя при эксплуатации приложения. Кроме того, в отличие от SAST динамический анализ кода обычно имеет меньше ложных срабатываний, поскольку он тестирует приложение в рабочем состоянии, обеспечивая более реалистичное представление о потенциальных уязвимостях.

Традиционные инструменты DAST тестируют только внешнее поведение приложения, например его пользовательский интерфейс и веб-службы, и не оценивают его внутреннюю работу. Это ограничивает их способность выявлять определённые типы уязвимостей, например те, которые возникают во внутренних компонентах приложения.

Анализ состава программного обеспечения (SCA)

SCA — это процесс идентификации компонентов, из которых состоит программное обеспечение. Он предназначен для проверки кодовой базы и для документирования использованных компонентов с открытым исходным кодом, включая их уязвимости и лицензии.

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

Анализ состава программного обеспечения реализовывается следующим образом: код в произвольном формате (Docker-образ, бинарный файл, репозиторий и т. д.) сканируется на наличие зависимостей от всех возможных компонентов с открытым кодом, после чего по списку таких компонентов проверяется совместимость продукта с заявленной лицензией, а также производится анализ уязвимостей. Одним из ключевых аспектов технологии SCA является создание спецификации ПО (SBOM), которая представляет собой полный список всех компонентов программного обеспечения.

Многие экосистемы менеджеров пакетов, IDE и системы контроля версий содержат инструменты SCA, однако зачастую они не являются точными и сложны в эксплуатации, поэтому удобнее применять отдельные приложения. Ранее мы публиковали обзор рынка инструментов SCA (Software Composition Analysis).

Анализ безопасности цепочки поставок ПО (SCS)

SCS — это набор мер для обеспечения безопасности и целостности процесса разработки и распространения ПО. В рамках цепочки поставок рассматриваются все этапы — от проектирования приложения до его развёртывания и эксплуатации.

Цепочка поставок включает в себя людей (разработчики, тестировщики, администраторы, поставщики, дистрибьюторы и т. д.), процессы, инструменты, платформы и технологии, которые участвуют в каждом из этапов разработки.

Самыми распространёнными рисками в цепочке поставок ПО являются небезопасный код, взаимодействие с ненадёжными поставщиками или партнёрами, незащищённые каналы распространения, позволяющие перехватить и подделать ПО, ошибки при развёртывании и неправильные конфигурации инструментов разработки. Ранее мы публиковали более подробную статью «Атаки на цепочки поставок: какие существуют риски и как от них защититься».

В настоящее время, несмотря на большое количество угроз для цепочек поставок, SCS является не очень широко распространённым методом, реализованным в продуктах немногих вендоров.

В отличие от SCA, который тоже работает с зависимостями, но предназначен для поиска известных брешей, SCS ориентирован на анализ зависимостей по различным метрикам и поиск проблем до их попадания в общеизвестные базы.

Комплексный подход к безопасной разработке

Лучшая практика анализа кода приложений — удостовериться, что во время разработки приняты все меры безопасности, а затем регулярно проверять запущенное приложение с учётом особенностей его работы и инфраструктуры.

Безопасный цикл разработки ПО предполагает следующие действия: обучение сотрудников основам кибербезопасности, формирование требований к безопасности ПО, моделирование угроз и рисков, поиск уязвимостей, фаззинг и динамическое тестирование кода, финальная проверка соответствия требованиям по безопасности, реагирование на инциденты согласно ранее сформированному плану. Для реализации всех перечисленных действий на каждом этапе разработки необходимо применять много различных анализаторов, что может стать проблемой.

Многочисленность и разрозненность инструментов, используемых во время разработки и эксплуатации ПО, приводят к необходимости обучать сотрудников работе с ними, а также ко значительным временным затратам на внедрение. Поэтому оптимально использовать такие решения, которые охватывали бы потребности в анализе на всех этапах жизненного цикла разработки.

Комплексный анализ безопасности на примере Solar appScreener

Рассмотрим комплексный подход к безопасной разработке ПО на примере решения Solar appScreener, разработанного ГК «Солар». Оно позволяет в одном интерфейсе без внедрения дополнительных инструментов выполнять статический и динамический анализ, а также проверять состав ПО и безопасность цепочки поставок. В марте 2024 года мы выпускали обзор его возможностей.

Решение Solar appScreener позволяет встраивать инструменты анализа кода в цикл безопасной разработки на разных его этапах.

 

Рисунок 1. Встраивание инструментов безопасности на различных этапах разработки

Встраивание инструментов безопасности на различных этапах разработки

 

Solar appScreener предоставляет возможность выявлять уязвимости и НДВ с помощью различных методов анализа программного кода и может интегрироваться с другими продуктами (системами отслеживания ошибок, средствами программирования, сервисами CI / CD).

 

Рисунок 2. Общая схема работы Solar appScreener

Общая схема работы Solar appScreener

 

Solar appScreener может быть полезен для:

  • повышения защищённости онлайн-сервисов, которые будут доступны внешним пользователям (интернет-банк, личный кабинет пользователя, онлайн-продажа товаров и услуг, сервисы мобильной коммерции и т. д.);
  • проверки безопасности ПО на наличие уязвимостей и НДВ, оставленных разработчиками, при отсутствии доступа к исходным кодам;
  • выполнения требований стандартов СТО БР ИББС, документов ФСТЭК России, PCI DSS и ГОСТ Р 56939‑2016 в части анализа кода приложения;
  • настройки системы защиты и мониторинга онлайн-сервисов.

Решение Solar appScreener может быть использовано локально или из облака (SaaS).

Основные функциональные возможности Solar appScreener

В рамках модуля SAST решение позволяет проводить анализ не только исходного кода, но и исполняемых файлов (бинарного кода). Solar appScreener поддерживает много языков программирования для проведения статического анализа: ABAP, Apex, ASP.NET, COBOL, С#, C / C++, Objective-C, Dart, Delphi, Go, Groovy, HTML5, Java, Java for Android, JavaScript, JSP, LotusScript, Kotlin, Pascal, Perl, PHP, PL/SQL, T/SQL, Python, Ruby, Rust, Scala, Solidity, Swift, TypeScript, VBA, VB.NET, VBScript, Visual Basic 6.0, Vyper, 1C. Для анализа мобильных приложений достаточно ссылки на ПО в Google Play или Apple App Store.

Модуль SAST может быть использован на этапах разработки и тестирования в цикле SSDLC для своевременного выявления уязвимостей и НДВ.

 

Рисунок 3. Модуль статического анализа в Solar appScreener

Модуль статического анализа в Solar appScreener

 

Модуль DAST позволяет анализировать веб-приложения на наличие уязвимостей, имитируя внешние атаки и используя распространённые уязвимости. Кроме того, Solar appScreener обладает возможностью связывать данные SAST и DAST. Это позволяет подтвердить динамическим анализом те недостатки, которые выявило статическое исследование, и снизить риск ложных срабатываний. Анализ осуществляется по URL веб-приложения.

Модуль DAST может быть использован на финальных стадиях разработки и на этапе тестирования ПО, когда приложение уже пригодно для запуска.

 

Рисунок 4. Модуль динамического анализа в Solar appScreener

Модуль динамического анализа в Solar appScreener

 

Модуль SCA позволяет проверять заимствованный код на наличие уязвимостей, а также предоставляет рекомендации по устранению выявленных недостатков. Solar appScreener поддерживает архивы с исходным кодом (7Z, ZIP, EAR / AAR, RAR, TAR.BZ2, TAR.GZ, TAR, CPIO), ссылки на репозитории (GitLab, GitHub, Bitbucket), SBOM-файлы. Технология SCA совместно с анализом бинарного кода позволяет проверять на уязвимости и НДВ унаследованные приложения и заказные разработки, в том числе использующие сторонние компоненты.

 

Рисунок 5. Модуль анализа состава ПО в Solar appScreener

Модуль анализа состава ПО в Solar appScreener

 

Модуль SCS позволяет анализировать цепочки поставок и лицензионные риски для проверки уровня доверия к используемым внешним компонентам. В качестве источников данных выступают SBOM-файлы.

Модули SCA и SCS могут быть задействованы для решения таких задач, как выявление уязвимых сторонних компонентов, оценка рисков от их использования и принятие решений об их применении, на этапах дизайна и разработки.

Solar appScreener представляет возможность сравнить все результаты анализа в графическом виде и отследить тем самым динамику появления и устранения уязвимостей и НДВ. Кроме того, решение позволяет автоматически сформировать и выгрузить отчёты по уязвимостям и НДВ по результатам всех видов анализа кода, а также подготовить рекомендации по их устранению для разработчиков и администраторов информационной безопасности.

Выводы

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

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

Полезные ссылки: 
Anti-Malware Яндекс ДзенПодписывайтесь на канал "Anti-Malware" в Telegram, чтобы первыми узнавать о новостях и наших эксклюзивных материалах по информационной безопасности.

RSS: Новые статьи на Anti-Malware.ru