Композиционный анализ — третий кит безопасной разработки. О важности и способах проверки Open Source на безопасность и качество

Композиционный анализ — третий кит безопасной разработки. О важности и способах проверки Open Source на безопасность и качество

ПРЕДПОСЫЛКИ ПРОБЛЕМАТИКИ

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

Сегодня в разработке открытого кода хоть раз поучаствовало уже более 100 млн человек, а регулярно в написании кода участвует около 10 млн разработчиков. Это очень разные люди с разной квалификацией и когнитивными способностями. А в последние годы плодовитыми соавторами открытых проектов стали ещё и роботы, они же ИИ-ассистенты.

В мире уже сейчас опубликовано более 300 млн проектов под флагом Open Source. Любой из этих проектов может стать частью вашего программного продукта, и вопрос привносимого качества и безопасности сегодня игнорировать нельзя.

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

Проблемы могут быть идентифицированы не сразу, и «тысяча глаз» открытого сообщества не всегда оказывается эффективной. Ярким примером является громкая ACE-уязвимость Log4Shell, обнаруженная в 2021 году в библиотеке Log4j, которая оказала эффект на 8% всей Java-экосистемы. Дефект в коде был выявлен спустя более 10 лет после того, как он был создан. Уязвимость позволяет производить удалённое выполнение кода путём нехитрого веб-вызова, чем в первые дни начали пользоваться злоумышленники, автоматически распространяющие шифровальщики и криптомайнеры. Тем не менее, несмотря на серьёзность проблемы и широкое медийное обсуждение, в 2025 году выходит больше библиотек, которые используют именно опасную версию вместо безопасной. Именно от этой уязвимости можно защититься наложенным средством (WAF), но станет ли ваше приложение от этого безопасным?

Недостаточный контроль за сторонними библиотеками влияет не только на вопросы безопасности. В гонке за повышением скорости выпуска продуктов разработчики не всегда успевают актуализировать версии используемых компонентов, что неизбежно приводит к возрастанию объёма технического долга: замораживаются старые версии библиотек и технологии. Их обновление влечёт решение задачи обратной совместимости, которое сопровождать становится всё дороже. Если не уделить внимание этой проблеме, то продукт может закончить свою жизнь раньше ожидаемого срока. В качестве примера здесь можно привести python-проекты, которые застряли на версии 2.7, а средств и времени для перехода на свежую ветку интерпретатора нет.

Отсутствие культуры работы со сторонними компонентами может привести не только к наличию уязвимостей в выпускаемом программном обеспечении, но и к риску потерь чувствительных данных, если просто всегда использовать последние версии библиотек. Примером подобной угрозы является червь Shai-Hulud, который завёлся в пакетной экосистеме NPM (пользуются JavaScript-разработчики). Червь успел заразить более 500 открытых библиотек, в том числе «миллионники». Как это работает: при установке пакета с червём запускается поиск конфиденциальной информации (паролей, токенов, ключей и иных) в коде разработчика, после чего они отправляются в сторону злоумышленника. Если у разработчика были собственные библиотеки в NPM, то червь себя туда копировал через выпуск новой версии, чем обеспечивал себе распространение.

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

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

ТЕХНОЛОГИЯ КОМПОЗИЦИОННОГО АНАЛИЗА

Композиционный анализ основан на инвентаризации сторонних компонентов ПО, определении особенностей их использования, составлении перечня известных уязвимостей и/или иных недостатков компонентов.

Композиционный анализ как технология включает в себя:

• выявление заимствований и идентификацию компонентов в составе ПО;
• построение перечня программных компонентов (ППК), также известного как Software Bill of Materials (SBOM);
• обогащение ППК и его актуализацию;
• оповещение о выявленных в ПО уязвимостях и нежелательных особенностях использования компонентов.

Схематичное отображение композиционного анализа ПО приведено [1] на рис. 1.

ППК — ЕДИНЫЙ СТАНДАРТ ОПИСАНИЯ КОМПОНЕНТОВ

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

В контексте конкретного программного продукта все библиотеки можно разделить на две группы: директивные и транзитивные зависимости. Директивные вызываются напрямую из кода проекта, а транзитивные уже вызываются директивными. При этом разработчики, как правило, не указывают и не контролируют устанавливаемые версии транзитивных библиотек сами. Эта часть работы лежит на пакетном менеджере, который фиксирует версии в так называемых .lock-файлах. Если лок-файл не создан или не добавлен в репозиторий кода проекта, это приводит к тому, что при сборках в разное время, в состав продукта могут входить разные версии транзитивных зависимостей. Тем не менее в конечный продукт входят все такие зависимости. Для устранения такой неоднозначности разработчикам рекомендуется использовать условные .lock-файлы в паре с манифестами, в которых разрешаются версии библиотек, что позволяет точнее контролировать состав собираемого продукта.

К сожалению, описанный выше механизм контроля продуктовых зависимостей сильно зависит от используемого технологического стека, одного или многих. Такая разнородность вариаций описания привела к появлению понятия Software Bill of Materials (SBOM), или Перечня программных компонентов (ППК). Это единый машиночитаемый документ, содержащий в себе структурированную информацию о компонентах программного обеспечения и отношениях между ними. Информация о компонентах может быть разного характера: от названия и версии компонента и информации о его авторах, до информации о лицензии компонента и, конечно, известных уязвимостях.

Первым общепризнанным стандартом описания SBoM стал SPDX (https://spdx.dev), разработка которого ведётся с 2010 года и поддерживается Linux Foundation. Изначально он был ориентирован на работу с лицензиями, а после был расширен возможностью описания уязвимостей. Выведен в международный стандарт ISO/IEC 5962:2021 с версии 2.2.1.

Другим популярным и «модным» сегодня стандартом является CycloneDX (https://cyclonedx.org), разрабатывающийся под эгидой OWASP с 2017 года. Стандарт сразу был акцентирован на контроле безопасности, но не исключает возможности хранения дополнительных сведений о компонентах, включая данные о лицензиях. В 2024 году версия CycloneDX 1.6 опубликована в виде стандарта ECMA-424 [2].

Существующие открытые инструменты для работы со SBOM-файлами поддерживают оба формата описания, но перевес больше в сторону CycloneDX.

В рамках ТК362 ФСТЭК России ведётся работа по разработке проекта ГОСТ Р «Защита информации. Композиционный анализ программного обеспечения. Общие требования». В октябре 2025 года завершилось публичное обсуждение проекта, и сегодня авторами ведётся доработка по полученным замечаниям.

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

Современные тенденции повсеместного внедрения практики машинного обучения в программные продукты отражаются и в развитии стандартов, приведённых выше, в формате MLBOM (реже — AIBOM). Появляются требования к детальному описанию (и фиксации!) наборов данных, библиотек и железу, которое участвует в формировании ML-моделей. В конечном счёте это тоже программное обеспечение.

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

ПРАКТИКА ПРИМЕНЕНИЯ КОМПОЗИЦИОННОГО АНАЛИЗА И ИНСТРУМЕНТАРИЙ

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

Известно, что чем раньше проблема обнаружена, тем дешевле её исправить. Работа с известными уязвимостями предполагает, что информация о дефекте описана публично, а  зачастую сопровождается proof of concept (PoC) и публичными эксплойтами, которые позволяют наглядно понять, как работает обнаруженная уязвимость. Эта информация является полезной при погружении разработчика в вопросы безопасной разработки. И этими знаниями ИБ должно делиться с ИТ.

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

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

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

Примерами таких агентов являются открытые инструменты: Trivy, Syft и cdxgen. Они поддерживают сканирование популярных языков программирования и Docker-образов.

Агенты могут выполнять задачу только инвентаризации компонентов либо обеспечивать также решение задачи обогащения данными об уязвимостях. Например, Trivy производит поиск известных уязвимостей по агрегированным базам, тогда как cdxgen формирует строго «инвентарь», который может быть обогащён при помощи других инструментов, например Dependency Track или dep-scan.

К сожалению, приведённые инструменты не поддерживают работу с БДУ ФСТЭК. Исключением является Trivy в отношении анализа системных пакетов. Он умеет обрабатывать данные в формате OVAL, которые формируют производители отечественных операционных систем (например, семейство ОС «Альт»).

Нельзя обойти вниманием и другие примеры агентов:

• OSV Scanner — работает с агрегированной базой уязвимостей от Google (https://osv.dev);
• OWASP dep-scan — реализует анализ возможности эксплуатации обнаруженной уязвимости для Java, JavaScript и PHP. Как правило, показывает результат для директивных зависимостей;
• OWASP-плагины для отдельных языков — следует внимательно отнестись к их настройке.

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

При контроле сторонних компонентов всегда важно помнить, что уязвимости в уже выпущенных вами продуктах сами по себе не появляются, а обнаруживаются со временем. Поэтому после выпуска сборки полезно не только сохранить ППК, но и проводить его регулярное обогащение на предмет новых уязвимостей в компонентах. Верхнеуровневый контроль и регулярность анализа возможно обеспечить с применением открытого инструмента Dependency Track от OWASP. Инструмент предоставляет пользователю веб-интерфейс для работы с результатами композиционного анализа и поддерживает обогащение данными из баз NVD и OSV.

КАЧЕСТВО И ЭФФЕКТИВНОСТЬ КОМПОЗИЦИОННОГО АНАЛИЗА

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

На объём возможных ложных срабатываний ключевым образом влияют следующие факторы.

1. Качество инвентаризации компонентов: нужно уметь обнаруживать не только директивные, но и транзитивные зависимости, разбирать слои образов и детектировать компоненты (или их части),включённые в программный продукт.
2. Полнота используемых источников информации об уязвимостях: чем больше источников — тем лучше, но они должны быть релевантны вашим технологиям. Важно следить за тем, чтобы ваши «фиды» данных были от тех компонентов, которые вы используете. Например: системные пакеты, которые в разных дистрибутивах существуют в разных версиях, и не все уязвимости в одном дистрибутиве применимы в другом. Отсутствие таких знаний при анализе существенно испортит его качество.
3. Возможность проверки достижимости уязвимости — не все обнаруживаемые уязвимости могут быть достижимы из собственного кода приложения. Автоматическая проверка трассы вызовов позволяет сократить время на приоритизацию рассматриваемых находок. К сожалению, не всегда можно точно сказать, что уязвимый метод недостижим. Но можно выделить уязвимости, которые точно достижимы. Эта та область, где композиционный и статический анализ сближаются, дополняя друг друга. Примером открытого инструмента, реализующего такую функцию, является dep-scan.
4. Качество и актуальность данных, используемых при анализе, также влияют на конечный результат. Например, случаются ситуации, когда источник данных об уязвимости содержит ошибочную ссылку на версию компонента, что приводит к ложному срабатыванию.

На эффективность работы с результатами композиционного анализа также влияют:

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

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

ПОЛЬЗА КОМПОЗИЦИОННОГО АНАЛИЗА ДЛЯ ОТРАСЛИ

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

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

Для разработчика композиционный анализ является средством разработки и тестирования программ, которое позволяет:

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

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

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

[1] Приводится цитата из проекта ГОСТ Р «Защита информации. Композиционный анализ программного обеспечения. Общие требования».

[2] https://ecma-international.org/publications-and-standards/standards/ecma-424/