Пиков / КАПО
Как читать авторский курс и нормативные материалы

Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.

AI model dependencies

Почему это важно для SCA/OSA

AI-система — это не только код. Кроме обычного дерева пакетов у неё есть веса модели, базовая модель, от которой она дообучена, обучающие датасеты и нативный рантайм инференса. Классический SBOM по package-lock.json или ELF этих сущностей не видит, а риски у них собственные: происхождение и лицензия весов, lineage дистилляции, совместимость лицензии датасета. Для C/C++-инженера здесь есть и прямой стык: рантаймы инференса (llama.cpp, onnxruntime, ggml) — это нативные C/C++-зависимости со своими .so и уязвимостями, которые попадают в обычный composition analysis, тогда как сама модель требует отдельного описания (ML-BOM).

Как это проявляется

Модель приезжает как бинарный файл весов, рядом — нативный рантайм, который её исполняет. Первый требует ML-BOM-записи, второй ловится обычным анализом ELF.

# артефакты модели — это не пакеты, а веса в специфичных форматах
file model.safetensors model.gguf model.onnx
#   model.gguf: data        <-- веса; версия/происхождение не вычитываются из файла

# рантайм инференса — обычная C/C++ зависимость
ldd ./llama-server
#   libggml.so => ...        <-- нативный .so, идёт в обычный SCA
#   libgomp.so.1 => ...

# в CycloneDX модель описывается отдельным типом компонента
jq '.components[] | select(.type=="machine-learning-model")' ml-bom.json

G7 «SBOM for AI: Minimum Elements» формализует это как семь кластеров (модель, веса, датасеты, происхождение, и т.д.), дополняющих обычный SBOM, а не заменяющих его. В CycloneDX модель — это компонент type: machine-learning-model со ссылками на базовую модель и датасеты.

Слепая зона или приём

Веса не имеют DT_NEEDED Файл .gguf/.safetensors/.onnx не объявляет своих «зависимостей» так, как ELF объявляет .so. Базовая модель, метод квантизации и датасет не вычитываются из бинаря весов — их нужно декларировать вручную в ML-BOM. Сканер ELF честно опишет рантайм и промолчит про саму модель.

Приём: разделить два слоя описания — нативный рантайм идёт в обычный SBOM через анализ .so, а модель и её lineage — в ML-BOM по кластерам G7, связанные ссылками.

Что делать на проекте

  1. Инвентаризировать нативный рантайм инференса как обычные C/C++-компоненты: ldd/readelf -d по llama.cpp/onnxruntime/ggml, версии и уязвимости в общий SBOM.
  2. Завести для модели отдельный компонент type: machine-learning-model в CycloneDX и заполнить семь кластеров G7.
  3. Зафиксировать lineage: базовая модель, метод дообучения/квантизации, происхождение весов — это не выводится из файла, требуется декларация поставщика.
  4. Связать модель с датасетами и базовой моделью ссылками (dependencies/properties), а не оставлять их разрозненными.
  5. Проверить лицензию весов и датасета отдельно от лицензии кода (см. dataset license) — они не совпадают.
  6. Включить ML-BOM в quality gate наравне с обычным SBOM: непокрытые кластеры G7 — это пробел в поставке.

Связь