Лучшие практики построения процесса композиционного анализа

Введение

Сегодня большинство коммерческих и государственных программных продуктов строится с активным использованием компонентов с открытым исходным кодом. По оценкам отраслевых исследований, их доля в составе приложений достигает 70–90%. Использование сторонних библиотек ускоряет разработку и снижает затраты, но одновременно расширяет поверхность атаки и создает новые риски: уязвимости, ошибки конфигурации и потенциальные угрозы безопасности цепочки поставок.

Композиционный анализ ПО (Software Composition Analysis, SCA) позволяет системно выявлять уязвимости, управлять лицензиями и транзитивными зависимостями сторонних компонентов. В статье представлены лучшие практики внедрения SCA в цикл разработки безопасных приложений (РБПО).

Что такое композиционный анализ

Композиционный анализ ПО – это практика тестирования состава программного обеспечения, автоматизирующая поиск сторонних (open-source) компонентов, выявление в них уязвимостей, устаревших версий и лицензионных рисков. Композиционный анализ обеспечивает видимость цепочки поставок ПО, предотвращая использование небезопасного кода.

Эта практика применима к широкому спектру объектов сканирования:

• исходный код;
• репозиторий;
• образ контейнера;
• файловая система;
• образ виртуальной машины;
• оркестраторы контейнеров (Kubernetes).

В цикле РБПО практика SCA традиционно внедряется на этапах разработки (Code), сборки (Build) и мониторинга (Monitor).

Рис. 1. Этапы интеграции ИБ-практик в цикл РБПО

Лучшие практики: добавление практики OSA на этапе Code

Параллельно с SCA рекомендуется интегрировать практику анализа компонент с открытым исходным кодом (OSA – Open Source Analysis) на этапе загрузки компонент разработчиком (Code). Такой подход соответствует принципу «сдвига влево» (Shift Left) и позволяет исключать небезопасные компоненты до того, как они попадут в код. Обычно OSA рассматривается отдельно от композиционного анализа, но их совместное использование ускоряет разработку и экономит ресурсы команды. Для реализации этого подхода необходим общий репозиторий, работающий в формате файрвола, из которого разработчики смогут скачивать все необходимые компоненты.

Этапы проведения композиционного анализа

1. Предварительный этап – генерация SBOM и настройка инструмента сканирования

Генерация SBOM

Исходным артефактом для проведения SCA является SBOM (Software Bill of Materials) – инвентаризационный файл со списком всех компонентов, обнаруженных в объекте сканирования.

Часть инструментов SCA генерирует SBOM самостоятельно: он создается либо «под капотом», либо в явном виде, и, помимо применения в тестировании, может использоваться для других целей (например, для инвентаризации активов).

Если инструмент не создает SBOM, применяются сторонние генераторы, например, cdxgen, Trivy, Syft. В этом случае важно отслеживать, чтобы формат SBOM поддерживался выбранным инструментом композиционного анализа. Самые известные и широко используемые форматы SBOM – CycloneDX от OWASP и SPDX от Linux Foundation. Большинство решений SCA поддерживают формат CycloneDX.

Настройка инструмента сканирования

Некоторые инструменты (один из них – известный open-source сканер Dependency-Check) работают без тонкой настройки. Однако для большинства решений нужно предварительно задать базовые параметры:

• предоставить пользователю права и доступы (на создание приложения, его сканирование, обработку результатов и т.д.);
• указать инструменту доступы к базам данных с уязвимостями (подробнее об этом в пункте 3 «Опрос баз данных»);
• создать политики безопасности.

Лучшие практики: настройка политики безопасности

Политика безопасности в практике SCA – это расширенный набор правил, позволяющий отслеживать или блокировать компоненты не только по признаку наличия уязвимостей, но и по дополнительным критериям, например:

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

На рисунке 2 приведен пример блокирующей политики в open-source инструменте Dependency-Track по правилу License group is Permissive, при котором блокируются все компоненты, чья группа лицензии принадлежит типу Permissive – разрешающие лицензии (MIT, Apache 2.0, BSD).

Рис. 2. Пример блокирующей политики в open-source инструменте Dependency-Track по правилу License group is Permissive

2. Анализ SBOM файла

На втором этапе инструмент SCA анализирует SBOM-файл (сгенерированный внутри инструмента или за его пределами в требуемом формате), запрашивает информацию обо всех компонентах и идентифицирует их по стандартам PURL, CPE, названию компонентов и их версии.

PURL (Package URL) – это открытый стандарт, используемый для однозначной идентификации программных пакетов, библиотек и компонентов в различных экосистемах (npm, Maven, PyPI, Docker и др.). Он представляет собой единую строку (URL), которая кодирует тип менеджера пакетов, имя, версию и, при необходимости, дополнительные данные.

Пример PURL: pkg:npm/react@18.2.0

CPE (Common Platform Enumeration, общее перечисление платформ) – это структурированная схема именования информационных технологических систем, программного обеспечения и пакетов. Она основана на общем синтаксисе унифицированных идентификаторов ресурсов (URI) и включает в себя формальный формат имени, метод проверки имен на соответствие системе и тип описания для привязки текста и тестов к имени.

Пример CPE: cpe:2.3:a:agendaless:pyramid:0.2:*:*:*:*:python:*:*

Лучшие практики: анализ транзитивных зависимостей

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

3. Опрос баз данных

На этом шаге инструмент SCA собирает информацию о компонентах из объекта сканирования в базах данных. Они могут быть как публичными, так и проприетарными – в последнем случае доступ к ним платный. Распространенные публичные базы уязвимостей: NVD, GHSA, БДУ ФСТЭК России, OSV.

Лучшие практики: анализ достижимости

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

На сегодняшний день функция анализа достижимости реализована в ограниченном числе инструментов.

4. Результаты сканирования

На данном этапе формируется отчет, в котором отражается содержимое объекта сканирования и перечисляются обнаруженные известные уязвимости компонентов. В инструментах с настраиваемыми политиками отчет содержит информацию об их нарушении.

На рисунке 3 представлено описание уязвимости в Dependency-Track, включающее компонент, его версию, идентификатор уязвимости из публичного источника NVD, критичность уязвимости и ее описание.

Рис. 3. Описание уязвимости в Dependency-Track

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

Лучшие практики: непрерывное сканирование

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

Ограничения практики композиционного анализа

Композиционный анализ предназначен исключительно для тестирования компонентов с открытым исходным кодом. Эта практика не охватывает ваш исходный код или исходный код постороннего компонента (за исключением узкоспециализированного анализа достижимости ) и точно не направлена на проверку приложения во время его исполнения. Для этого применяются инструменты практик статического (SAST) и динамического (DAST) анализа.

Еще одно ограничение – эксплуатируемость найденных уязвимостей. Композиционный анализ выявляет наличие проблемного компонента, но не указывает, насколько вероятна эксплуатация этой уязвимости. Например, если уязвима конкретная функция из стороннего компонента, принимающая недоверенный пользовательский ввод, но ваш код ей не пользуется, уязвимость фактически неактуальна. Однако если функция используется (и зафиксирована анализом достижимости), но при этом вы  реализовали очистку пользовательского ввода, то анализ достижимости это не выявит, а SCA-проверка все равно продолжит отображать компонент как уязвимый. Поэтому необходим ручной анализ и полное понимание логики вашего исходного кода.

Также стоит учитывать наличие zero-day уязвимостей, т.е. проблем, о которых нет информации в базах данных, но злоумышленники уже сейчас могут их эксплуатировать. Так было, например, с уязвимостью Log4shell: она оставалась нераскрытой и могла использоваться хакерами с 2013 до 2021 года. Отсутствие данных может создать ложное ощущение безопасности компонентов.

Для минимизации рисков рекомендуется комплексно подходить к организации безопасности всей цифровой инфраструктуры компании в целом и программных продуктов в частности. Важно внедрять дополнительные инструменты для детектирования вторжения и реагировать на инциденты ИБ незамедлительно.

Благодаря непрерывному сканированию можно своевременно узнавать о новых опубликованных критических уязвимостях и оперативно принимать меры по их исправлению.

Заключение

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

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