Англоязычное название и сокращение — Software Composition Analysis (SCA).
Цели 16-го процесса ГОСТ Р 56939-2024:
Создание условий для снижения рисков наследования уязвимостей и недекларированных возможностей при использовании заимствованного кода в коде ПО разработчика.
И этот, и следующий 17-ый процесс касаются темы уязвимостей, связанных с цепочками поставок. Разница в том, что, говоря про композиционный анализ (SCA), имеется в виду выявление ставших уже известными непреднамеренных (и иногда преднамеренных) уязвимостей в используемых библиотеках. Некую ошибку, оказалось, можно эксплуатировать, и она стала новой уязвимостью. Про неё узнали, и теперь задача SCA — уведомить разработчиков об этом. Задача разработчиков, соответственно, обновить старую уязвимую версию библиотеки на новую, где уязвимость устранена.
Процесс 17 — проверка кода на предмет внедрения вредоносного программного обеспечения через цепочки поставок. Это предупредительная мера как от случайных ошибок, а так и злонамеренных закладок, которые иногда могут маскироваться под ошибки. Когда такие уязвимости будут обнаружены, композиционный анализ также поможет их устранить в различных проектах. Но это будет потом. Задача 17-го процесса — подстраховать от этого (снизить риски). Более того, если речь идёт о внешних, но не открытых компонентах, то ждать помощи со стороны SCA не приходится. Впрочем, про этот процесс мы поговорим позже.
Важно то, что к цепочкам поставок нужно относиться очень внимательно. Количество атак через них всё увеличивается, и этот тренд, видимо, ещё долго будет сохраняться. Свежий пример: В ходе атаки GhostAction скомпрометировано 817 репозиториев на GitHub.
Недавний круглый стол на рассматриваемую тему: Цепочка поставок как угроза: как контролировать риски стороннего ПО.
Иногда неприятности могут прийти оттуда, откуда и не ждёшь. Например, масла в огонь могут подливать AI-агенты, заимствующие несуществующие пакеты, которые можно заранее подготовить и подсунуть. Смотри интересный доклад Алексея Смирнова "О влиянии применения ассистентов программиста на процессы безопасной разработки".
Подборка SCA-инструментов. При этом, выбирая себе инструмент следует учитывать, что скоро появится ГОСТ — Композиционный анализ программного обеспечения. Уже есть проект этого стандарта. На мой взгляд, стоит обратить внимание на Codescoring.
P.S. В стандарте не упоминается SBOM (Software Bill of Materials), но это важная сущность в задаче контроля цепочек поставок. Это перечень компонентов, библиотек и зависимостей, которые входят в состав программного приложения, а также информация о лицензиях, версиях и других метаданных, связанных с этими компонентами. SBOM улучшает прозрачность (обеспечивает понимание того, из чего состоит программный продукт), ускоряет реагирование на инциденты, помогает управлять безопасностью.
Ссылки:
1. Wikipedia. Software composition analysis.
2. SCA на языке безопасника.
3. Алексей Смирнов — Проверка open source: защита цепочки поставок и эффективный композиционный анализ.
4. Инструкция по SCA: генерация SBOM, инструменты, отличия.
5. Построить SBoM, вырастить SDL-политики, воспитать культуру безопасной разработки / Алексей Смирнов.
6. Алексей Смирнов: Не проверив Open Source “под капотом” продукта, нельзя утверждать, что он безопасен.
7. Practical Guide to NTIA Compliant SBOM.
8. Методическая рекомендация № 2025-09-012. Алгоритм представления перечня заимствованных. программных компонентов с открытым исходным кодом (далее - SBOM).