Многие приложения содержат уязвимости, которые могут стать возможностью для проведения атак со стороны злоумышленников. Чтобы минимизировать такие риски, команды разработки должны уделять внимание контролю безопасности ПО уже с первых этапов создания своих продуктов. Один из методов — композиционный анализ, направленный на поиск и исследование Open Source-компонентов. Рассказываем подробнее, что это за тестирование, как оно проводится.
Композиционный анализ кода: что это и зачем его проводить
Композиционный анализ (Composition Analysis) — совокупность методов для отслеживания в кодовой базе ПО заимствованных компонентов Open Source и проверки их безопасности.
Цели такого анализа:
- Обнаружить в ПО все компоненты с открытым исходным кодом, отследить их зависимости.
- Проверить безопасность Open Source-компонентов.
- Установить вызовы из кода уязвимых компонентов.
- Оценить лицензионные риски, связанные с применением открытых компонентов.
Композиционный анализ проводится с помощью специальных анализаторов, позволяющих максимально автоматизировать процессы проверки кода. Такие решения могут использоваться программистами или ИБ-инженерами.
Преимущества композиционного анализа кода
Сильные стороны такого метода проверки ПО:
- Своевременное обнаружение уязвимостей в заимствованном ПО, что дает возможность устранить слабые места приложений до релиза продукта.
- Обеспечение прозрачности в цепочке поставок ПО, прогнозирование возможных рисков, связанных с тем или иным звеном в цепочке.
- Повышение качества и уровня защищенности готовых приложений.
- Соблюдение требований отраслевых регуляторов к безопасности приложений (общедоступных сервисов и корпоративного ПО).
Композиционный анализ, как и другие методы тестирования ПО, позволяет выявлять большинство уязвимостей по факту их появления и прогнозировать возможные проблемы в будущем.
Методы композиционного анализа
Существует два метода, позволяющих обнаружить в ПО потенциально опасные и заимствованные компоненты:
- Software Composition Analysis (SCA) — анализ заимствованных компонентов и сторонних библиотек на уязвимости, оценка лицензионных рисков. Этот метод позволяет поддерживать высокий уровень безопасности программ с открытым исходным кодом.
- Supply Chain Security (SCS) — анализ цепочки поставок (Supply Chain), под которой подразумевают весь путь ПО с момента начала разработки до доставки потребителю. Звенья цепочки — причастные к созданию приложений лица, используемые технологии и компоненты, в том числе заимствованные. На любое из этих звеньев хакеры могут совершить атаку, поэтому нужно оценить Supply Chain-риски, в чем и поможет SCS-анализ.
Эти методы композиционного анализа Open Source в анализаторе Solar appScreener объединены в общий модуль — Open Source Analysis (OSA). Его внедрение в цикл разработки позволяет прийти к безопасному использованию открытых компонентов в программных продуктах.
Как внедрить композиционный анализ с помощью Solar appScreener
Solar appScreener — удобная платформа, позволяющая интегрировать композиционный анализ кода в процесс создания ПО. Как в отечественном анализаторе работает модуль OSA:
- Необходимо загрузить в анализатор SBOM-файл с данными. Также есть возможность загрузить на вход SCA-анализатора архив или ссылку на репозиторий с исходным кодом проекта. Система попробует автоматически собрать SBOM-файл, после чего начнет композиционный анализ. Для сборки SBOM из архива необходимо, чтобы архив содержал как исходный код, так и соответствующие манифесты.
- С помощью модуля OSA полученные файлы проверяются с использованием общедоступных баз сторонних компонентов и собственных баз ГК «Солар».
Дальнейший сценарий зависит от целей тестирования. Если проводится SCS-анализ цепочки поставок, при проверке ПО учитываются следующие критерии:
- Распространенность компонентов.
- Состав авторов.
- Активность сообщества.
- Степень заинтересованности в безопасности.
- Дата создания библиотеки.
- Подозрительно высокая первая версия.
- Количество проектов разработчика.
- Процент пул реквестов, которые не выполняют требование рецензии от двух человек.
На основании анализа критериев Solar appScreener выставляет комплексную оценку безопасности заимствованных компонентов. Также анализатор отдельно оценивает риски для каждого звена цепочки поставок.
В рамках SCA-анализа выполняется инвентаризация всех компонентов и библиотек в программном обеспечении. Затем анализатор генерирует дерево зависимостей, которое представляет как прямые зависимости (явные в проекте), так и транзитивные (косвенно приведенные через другие зависимости). Также происходит композиционный анализ всех компонентов на наличие дефектов или нюансов с лицензированием. Если есть проблема, то генерируется контекстная информация (описание, затронутые компоненты и т. д.).
В Solar appScreener возможен комплексный подход к анализу благодаря корреляции результатов анализа Open Source (OSA) с данными, получаемыми Static Application Security Testing (SAST). Этот модуль используется для проведения статического анализа кода на начальных этапах разработки. Его основная задача — выявление уязвимостей и недекларированных возможностей в программном обеспечении.
Такая корреляция между результатами OSA и SAST позволяет разработчикам получить более полную картину безопасности проекта. Анализ компонентов открытого кода помогает выявить потенциальные риски, связанные с использованием сторонних библиотек, а SAST дополняет эту информацию данными о возможных уязвимостях в самом коде приложения.
Всесторонний подход к контролю безопасности программных продуктов
В цикл безопасной разработки ПО помимо композиционного анализа кода внедряются и другие методы тестирований, например, Static Application Security (SAST) и Dynamic Application Security Testing (DAST). Их краткое описание:
SAST — статический анализ кода с целью поиска уязвимостей, ошибочных фрагментов, недекларированных возможностей ПО. Такое тестирование легко внедряется в цикл разработки, поскольку для его проведения не нужна тестовая рабочая среда. Еще одна сильная сторона SAST — максимальное покрытие кода, за счет чего обнаруживается большинство существующих проблем. Есть и минус — ложноположительные срабатывания (False Positive) анализаторов, используемых для проверки ПО. В Solar appScreener эта проблема решается с помощью технологии Fuzzy Logic Engine.
DAST — динамическое тестирование, призванное проверить степень уязвимости приложения к атакам и корректность работы функциональностей. Для его проведения необходимо разворачивать тестовую среду, приближенную к реальной. В рамках DAST анализатор использует различные сканеры, имитирует действия пользователей и хакеров. Главное преимущество динамического тестирования в том, что его можно проводить без доступа к исходному коду и знания структуры программы. Минус — есть риски пропустить часть уязвимостей, поскольку DAST не подсвечивает проблемы отдельных компонентов ПО.
Чтобы усилить преимущества и нивелировать недостатки этих методов, SAST и DAST следует комбинировать. Статический анализ можно проводить с первых этапов разработки, динамический — когда ПО будет хотя бы частично готово к эксплуатации.
Как и композиционный анализ, SAST и DAST легко интегрировать в цикл разработки с помощью анализатора Solar appScreener. Результаты тестирований могут коррелироваться и представать в виде подробных отчетов с рекомендациями по устранению обнаруженных проблем.
Выводы
Композиционный анализ кода пока не так распространен среди российских разработчиков, как статический и динамический, но в связи с растущим количеством уязвимостей в Open Source-библиотеках он набирает популярность. Впрочем, для всестороннего контроля безопасности ПО лучше комбинировать все виды тестирований. Инструменты для их реализации можно найти в одной платформе — Solar appScreener.
Источник: ГК «Солар»
