SBOM для AI-кода: что это, когда нужна и как использовать перед релизом

Команда ускорилась с AI-ассистентами — но знает ли она, что именно едет в прод?

Введение: быстрый код — не обязательно безопасный код

Разработчики сегодня пишут код быстрее, чем когда-либо. По данным Google, примерно половина строк в enterprise-проектах уже создаётся с участием AI-ассистентов [1]. Это означает, что pull request стал шире, PR-дифы длиннее, а время на code review — короче.

Проблема не в самом AI. Проблема в том, что рабочий код — это ещё не безопасный код. Каждая новая функция, написанная с помощью Copilot, Claude или Cursor, может принести с собой пакет, который разработчик не выбирал, не проверял и даже не заметил. А перед релизом никто не смотрит в lock-файл.

Именно здесь появляется SBOM — инструмент, который даёт команде ответ на простой вопрос: что именно мы выпускаем в прод?

Что такое SBOM и почему это не просто список пакетов

SBOM расшифровывается как Software Bill of Materials — буквально «список ингредиентов» программного продукта. По определению CISA, это вложенный машиночитаемый инвентарь всех компонентов, библиотек, модулей и их зависимостей, которые входят в состав конкретного артефакта [2].

Аналогия простая: как этикетка на упаковке продукта в магазине показывает состав, SBOM показывает состав вашего релизного билда. Только в отличие от этикетки, SBOM создаётся автоматически и обновляется с каждой сборкой.

Важно понять, чем SBOM отличается от смежных инструментов:

• SCA (Software Composition Analysis) — активный процесс сканирования кода на уязвимости в open-source компонентах во время разработки.
• SBOM — это статический машиночитаемый инвентарь всех компонентов конкретного билда, который сопровождает артефакт.
• VEX (Vulnerability Exploitability eXchange) — документ-аттестация, указывающий, затронут ли продукт конкретной CVE [2].

SBOM без SCA — это список без оценки. SCA без SBOM — это оценка без фиксированного снимка. Вместе они дают полную картину: что именно вошло в билд и что из этого несёт риск.

Два доминирующих формата:

1. CycloneDX — разработан OWASP, ориентирован на задачи кибербезопасности, поддерживает данные об уязвимостях, более лёгкий, лучше подходит для DevSecOps-сценариев [17].
2. SPDX — стандарт ISO (ISO/IEC 5962:2021), разработан Linux Foundation, более полный с точки зрения лицензионной аналитики, предпочтителен для юридических команд и compliance-офицеров [13].

Большинство современных команд выбирают CycloneDX как рабочий формат и дополнительно генерируют SPDX там, где это требует регулятор.

Почему AI-код меняет уравнение supply chain

До массового распространения AI-ассистентов supply chain атаки уже были проблемой. Атака SolarWinds в 2020 году затронула 18 000 организаций, включая федеральные агентства США [2]. Уязвимость Log4Shell в 2021 году поразила сотни миллионов устройств по всему миру [2]. В обоих случаях проблема была в компонентах, которые использовались, но не контролировались.

С приходом AI-кодинга картина изменилась принципиально: появился новый класс риска.

Package hallucinations: зависимости, которых не существует

В марте 2025 года исследователи опубликовали работу, охватывающую 576 000 сгенерированных LLM-моделями фрагментов кода на Python и JavaScript. Результат: примерно в 20% случаев рекомендованные пакеты не существовали ни в PyPI, ни в npm [21].

Это явление получило название slopsquatting — производное от typosquatting. Механизм атаки прямой: злоумышленник регистрирует пакет с именем, которое LLM часто галлюцинирует, и кладёт внутрь вредоносный код. Когда разработчик копирует AI-генерированный код и запускает pip install или npm install — он устанавливает малварь [22].

Исследователи Socket подчёркивают, что галлюцинации не случайны: 58% из них повторяются при одних и тех же промптах более одного раза [23]. Это делает атаку предсказуемой и легко масштабируемой для злоумышленников.

Коммерческие модели галлюцинируют реже открытых — у ChatGPT-4 этот показатель около 5% против десятков процентов у CodeLlama или WizardCoder [21]. Но 5% на большом объёме генерации — это не маленький риск.

Транзитивные зависимости: невидимый хвост

Помимо галлюцинаций, AI-код добавляет реальные пакеты — но в них есть свои транзитивные зависимости, которые разработчик не выбирал и не видел. Исторически именно в них находились критические уязвимости: Log4Shell был зарыт на несколько уровней вглубь dependency tree [31].

Без SBOM команда не видит этот хвост. С SBOM — видит всё дерево целиком, вплоть до рекурсивных зависимостей.

OWASP признаёт проблему официально

В ноябре 2025 года OWASP опубликовал обновлённый Top 10 для веб-приложений — первый с 2021 года. Самое значимое изменение: Software Supply Chain Failures дебютировал на третьем месте как самостоятельная категория [41].

До этого supply chain риски были растворены в категории «Vulnerable and Outdated Components». Отдельная позиция сигнализирует о принципиальном сдвиге: сообщество признало, что атака на цепочку поставок — это системный, а не точечный риск [46, 47].

В разделе «следующие шаги» того же документа появилась категория «Inappropriate Trust in AI Generated Code» — признание того, что разработчики выпускают AI-генерированный код без достаточной проверки [39]. Она не вошла в топ-10, но вектор очевиден.

Регуляторный контекст: SBOM из best practice превращается в обязанность

EU Cyber Resilience Act

EU Cyber Resilience Act (Регламент ЕС 2024/2847) вступил в силу в декабре 2024 года. Основные обязательства начинают применяться с декабря 2027 года [30].

Ключевое требование для производителей цифровых продуктов, выходящих на рынок ЕС: создавать и поддерживать машиночитаемую SBOM, охватывающую как минимум зависимости верхнего уровня [29].

SBOM не обязательно публиковать — но она должна быть готова к предоставлению регуляторам по запросу. Санкции за несоответствие — до €15 млн или 2,5% глобального оборота [32].

Де-факто стандартом технических требований в ЕС стал BSI TR-03183-2 — немецкое руководство, которое детализирует, как именно должна быть устроена CRA-совместимая SBOM: форматы CycloneDX 1.6+ или SPDX 3.0.1+, хэши, лицензии, структура ссылок [35].

US Executive Order 14028 и CISA

В США обязательства для поставщиков федерального правительства возникли ещё из Executive Order 14028 (2021). В 2024 году CISA опубликовала документ «Framing Software Component Transparency», уточнив минимальные атрибуты SBOM. В 2025 году идёт публичное обсуждение обновлённых минимальных требований [7].

NIST в специальном документе SP 800-204D прямо указывает: SBOM должна генерироваться при первом коммите с новой зависимостью и обновляться в CI/CD-пайплайне [11].

Для команд, работающих с российским рынком, прямых аналогичных требований по SBOM пока нет. Однако если продукт выходит на рынок ЕС или обрабатывает данные клиентов из ЕС — CRA применим к производителю вне зависимости от географии разработки.

Как SBOM встраивается в процесс: где генерировать и что делать дальше

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

Где генерировать

Практика DevSecOps однозначна: SBOM должна генерироваться после того, как артефакт собран, и до того, как он уходит в деплой [14].

Логика простая: на этапе сборки все зависимости уже разрешены — SBOM будет точной. Если генерировать до сборки, можно не поймать транзитивные зависимости. Если генерировать после деплоя — информация придёт слишком поздно для gate-решения.

Практическая схема встраивания в пайплайн:

1. Код попадает в PR — быстрые проверки: секреты, базовая статика, линтинг.
2. PR смержен в main — начинается сборка артефакта.
3. После сборки: генерация SBOM (Syft, cdxgen, Trivy), сканирование SBOM по базам уязвимостей (Grype, OSV, NVD), проверка политик (лицензии, критические CVE).
4. Если политики нарушены — билд блокируется, команда получает конкретный сигнал: что именно и почему.
5. Если политики соблюдены — SBOM подписывается, хранится вместе с артефактом в registry, артефакт уходит в деплой [15, 20].

Что хранить и как

SBOM — это не временный файл. Это документ с жизненным циклом.

Правила хранения:

• Отдельная SBOM на каждую версию продукта — новая версия компонента означает новую SBOM [35].
• SBOM подписывается цифровой подписью, чтобы можно было верифицировать целостность.
• Хранится в artifact registry рядом с образом контейнера или дистрибутивом.
• При выходе новой CVE, затрагивающей компонент из SBOM, система автоматически уведомляет команду — даже если билд уже в продакшене [20].

Матрица зрелости

Зрелость работы с SBOM удобно описывать тремя уровнями:

Начальный уровень: SBOM генерируется для релизных артефактов, хранится в registry, прикреплена к версии.

Средний уровень: Политики блокируют деплой при наличии критических CVE или недопустимых лицензий; SBOM интегрирована в incident runbook.

Продвинутый уровень: Реальтайм-мэппинг SBOM с телеметрией из прода, аттестации с записью в supply chain ledger, автоматическое назначение ответственных при появлении новой уязвимости [20].

Для небольших команд в режиме быстрого прототипирования имеет смысл начать с периодических SBOM-свипов, а не с жёсткого gate. Главное — начать собирать данные.

Инструменты: что использовать на практике

Экосистема инструментов для работы с SBOM зрелая и в большинстве своём open source.

Инструменты генерации SBOM:

1. Syft (Anchore) — генерирует SBOM из контейнерных образов, файловых систем, репозиториев; поддерживает CycloneDX и SPDX; хорошо интегрируется с GitHub Actions.
2. cdxgen — специализированный генератор CycloneDX, поддерживает более 20 языков и экосистем, включая Python, Java, Go, Node.js.
3. Trivy (Aqua Security) — сканер уязвимостей, умеющий генерировать SBOM как побочный продукт сканирования; удобен, если SCA и SBOM нужны в одном инструменте [18].

Хранение и трекинг:

1. Dependency-Track (OWASP) — open-source платформа для хранения SBOM, мониторинга компонентов и непрерывного обновления данных об уязвимостях; принимает SBOM через API, имеет UI [17].

Анализ политик:

1. Grype (Anchore) — сканирует SBOM по базам OSV, NVD, GitHub Advisory Database; можно встроить прямо в pipeline.
2. ORAS CLI — публикует SBOM как OCI-артефакт в container registry рядом с образом [18].

Специфика AI-моделей:

1. AIsbom (Lab700xOrg) — инструмент для глубокого бинарного анализа AI-моделей (.pt, .pkl, .safetensors, .gguf); генерирует CycloneDX 1.6-совместимый sbom.json с хэшами и лицензионными данными; умеет детектировать риски внутри сериализованных весов [10].

SBOM для AI-моделей: отдельная история

Если в продукте используются не просто библиотеки, а ML-модели — SBOM обычного вида недостаточна. Появилась концепция AI-BOM (или AIBOM): расширенный инвентарь, учитывающий специфику AI-артефактов.

AI-BOM охватывает [8]:

1. Метаданные модели: архитектура, версия, происхождение.
2. Информация о датасете: источники, лицензии, шаги предобработки.
3. Детали обучающего пайплайна: параметры валидации и мониторинга.
4. Runtime-артефакты: окружение, хранилище, конфигурация инференса.

В отличие от статических версий библиотек, AI-системы динамичны — они дообучаются и fine-tuneятся. Поэтому AI-BOM функционирует как живой документ, который обновляется при каждом цикле переобучения [8].

OWASP в рамках Gen AI Security Project в 2025 году представил open-source инструмент для генерации AI SBOM — первый в индустрии такого класса [4]. Это сигнал: стандартизация AI-BOM только начинается, но движется быстро.

Практический вывод для команд, работающих с LLM-инфраструктурой: обычная SBOM нужна для зависимостей вашего приложения, AI-BOM — для самой модели. Обе должны генерироваться и храниться как часть релизного процесса.

Типичные ошибки и как их избежать

Ошибка 1: Генерировать SBOM вручную или раз в спринт.

Почему это не работает: зависимости меняются с каждым коммитом. Ручная SBOM устаревает за часы. Автоматизация — обязательное условие [3].

Ошибка 2: Хранить SBOM отдельно от артефакта.

Почему это не работает: при инциденте нужно быстро сопоставить версию продукта в проде с его составом. Если SBOM лежит отдельно в Confluence, эта связь теряется.

Ошибка 3: Использовать SBOM только для compliance, а не для принятия решений.

Почему это не работает: SBOM в виде статического документа — это бюрократия без ценности. Ценность появляется, когда SBOM интегрирована с vulnerability feeds и блокирует деплой при наличии критических рисков [9].

Ошибка 4: Считать, что SCA покрывает всё.

Почему это не работает: SCA сканирует во время разработки. Но в CI/CD могут появляться новые зависимости, которые SCA не захватил. SBOM — это снимок финального билда, а не состояния в момент написания кода [2].

Ошибка 5: Игнорировать транзитивные зависимости.

Почему это не работает: уязвимость Log4Shell была транзитивной — она входила в состав компонентов, которые никто не добавлял напрямую. CRA требует покрытия как минимум зависимостей верхнего уровня, но лучшая практика — рекурсивное покрытие [31].

Ошибка 6: Не проверять AI-генерированные зависимости перед install.

Почему это не работает: как показало исследование, галлюцинированные пакеты — предсказуемы и повторяемы [23]. Это значит, что их можно заранее заблокировать на уровне политик в пайплайне.

Как это выглядит на практике: сценарий перед релизом

Представим типичную ситуацию: команда готовит релиз, разработчик использовал AI-ассистент для написания нового модуля обработки данных. В PR — 400 строк, из которых 300 написаны с помощью Claude или Copilot.

Без SBOM: PR заходит, ревьюер смотрит на логику, не на зависимости. В продакшен уходит новый пакет — никто не знает, есть ли в нём открытые CVE и под какой лицензией он распространяется.

С SBOM в пайплайне: после мержа и сборки артефакта автоматически запускается генерация SBOM. Система сравнивает новый инвентарь с предыдущим — находит три новых компонента. Один из них имеет критическую CVE с CVSS 9.1. Gate срабатывает, деплой блокируется, команда получает конкретный сигнал: какой компонент, какая CVE, какой фикс доступен. Выпуск занимает на 20 минут больше — но команда знает, что именно она выпускает.

Именно такой подход — короткий понятный сигнал вместо длинного отчёта, конкретный следующий шаг вместо общего предупреждения — описывает то, как должен работать security-контроль перед релизом. Похожую логику реализует HighVibe: анализ конкретного изменения и связанных зависимостей прямо в контексте PR и релиза, с объяснением риска и предложением следующего шага.

Что делать дальше: практический чек-лист

Для команд, которые только начинают:

1. Выбрать формат SBOM. Для большинства команд — CycloneDX. Если есть требования по лицензионному compliance — дополнительно SPDX.
2. Добавить генерацию SBOM в CI/CD. Точка вставки: после сборки артефакта, до деплоя.
3. Хранить SBOM рядом с артефактом. В container registry, artifact store или как OCI-артефакт.
4. Настроить сканирование по базам уязвимостей. Grype + OSV как минимум.
5. Определить политики. Что является hard block (критические CVE), что — предупреждением (средние CVE, запрещённые лицензии).
6. Проверять AI-генерированные зависимости. Добавить шаг верификации: существует ли пакет в реестре до запуска install.

Для команд на среднем уровне зрелости:

1. Подключить Dependency-Track для непрерывного мониторинга уже задеплоенных версий.
2. Настроить алертинг при появлении новых CVE для компонентов из исторических SBOM.
3. Добавить SBOM в incident response playbook: при инциденте первый шаг — поднять SBOM текущей версии.

Для команд, работающих с AI-моделями:

1. Отдельно генерировать AI-BOM для используемых моделей.
2. Верифицировать модели перед pull: SafeTensors compliance, хэши, лицензии.
3. Хранить историю версий моделей так же, как версии кода.

Выводы

SBOM — это не новая бюрократическая процедура и не замена существующего AppSec-стека. Это инструмент, который отвечает на вопрос «что именно мы выпускаем?» — вопрос, который стал острее с приходом AI-кодинга.

AI-ассистенты ускорили разработку. Но они также ускорили поступление новых зависимостей в продакшен — зависимостей, которые никто не выбирал осознанно. Slopsquatting превратил галлюцинированные пакеты в потенциальный вектор атаки. OWASP поднял supply chain failures на третье место. EU CRA сделал SBOM юридически обязательной к 2027 году.

Хорошая новость: начать несложно. Syft или cdxgen в GitHub Actions, CycloneDX-формат, Dependency-Track для хранения. Это час работы — и команда получает базовую видимость.

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

Источники

[1] Google on AI-assisted development — https://research.google

[2] CISA — Software Bill of Materials — https://www.cisa.gov/sbom

[3] IBM — What is an SBOM — https://www.ibm.com/think/topics/sbom

[4] OWASP Gen AI Security Project — AI SBOM Initiative — https://genai.owasp.org/ai-sbom-initiative/

[5] Mia-Platform — What Does An SBOM Mean For AI — https://mia-platform.eu/blog/what-does-an-sbom-mean-for-ai/

[6] JFrog — What is an AI-BOM — https://jfrog.com/learn/ai-security/ai-bom/

[7] CISA — 2025 Minimum Elements for a Software Bill of Materials — https://www.cisa.gov/resources-tools/resources/2025-minimum-elements-software-bill-materials-sbom

[8] CMS Information Security — New CISA SBOM Guidance — https://security.cms.gov/posts/new-cybersecurity-guidance-cisa-software-bill-materials-sbom

[9] GitHub — Lab700xOrg/aisbom — AI SBOM Tool — https://github.com/Lab700xOrg/aisbom

[10] NIST SP 800-204D — Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines — https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-204D.pdf

[11] CI/CD SBOM Integration Guide — https://sbomgenerator.com/guides/ci-cd

[12] DevSec Blog — A Practical Approach to SBOM in CI/CD — https://devsec-blog.com/2024/03/a-practical-approach-to-sbom-in-ci-cd-part-iii-tracking-sboms-with-dependency-track/

[13] DevSecOps Pipeline Guide — https://cloudaware.com/blog/devsecops-pipeline/

[14] OWASP Top 10:2025 (Orca Security overview) — https://orca.security/resources/blog/owasp-top-10-2025-key-changes/

[15] Rescana — AI-Hallucinated Dependencies: Slopsquatting — https://www.rescana.com/post/ai-hallucinated-dependencies-in-pypi-and-npm-the-2025-slopsquatting-supply-chain-risk-explained

[16] BleepingComputer — AI-hallucinated code dependencies become new supply chain risk — https://www.bleepingcomputer.com/news/security/ai-hallucinated-code-dependencies-become-new-supply-chain-risk/

[17] arxiv.org — We Have a Package for You: Package Hallucination Study — https://arxiv.org/html/2406.10279v3

[18] OpenSSF — SBOMs in the Era of the CRA — https://openssf.org/blog/2025/10/22/sboms-in-the-era-of-the-cra-toward-a-unified-and-actionable-framework/

[19] Anchore — EU CRA SBOM Requirements — https://anchore.com/sbom/eu-cra/

[20] European Commission — Cyber Resilience Act — https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act

[21] FOSSA — SBOM Requirements in the EU's CRA — https://fossa.com/blog/sbom-requirements-cra-cyber-resilience-act/

[22] SafeDep — SBOM and the EU Cyber Resilience Act — https://safedep.io/sbom-and-eu-cra-cyber-resilience-act/

[23] BSI — Cyber Resilience Act — BSI TR-03183 — https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Cyber_Resilience_Act/cyber_resilience_act.html

[24] OWASP Top 10:2025 — Introduction — https://owasp.org/Top10/2025/0x00_2025-Introduction/

[25] SC Media — Software supply chain threats are finally on the OWASP Top 10 — https://www.scworld.com/perspective/software-supply-chain-threats-are-finally-on-the-owasp-top-10

[26] Endor Labs — OWASP Top 10 Adds A03:2025: Software Supply Chain Failures — https://www.endorlabs.com/learn/owasp-top-10-adds-a03-2025-software-supply-chain-failures

[27] Sonatype — OWASP LLM Top 10: Securing AI and Software Supply Chain — https://www.sonatype.com/blog/the-owasp-llm-top-10-and-sonatype-supply-chain-security

[28] DevSecOps School — What is SBOM 2026 Guide — https://devsecopsschool.com/blog/sbom/