SBOM и SCA в России 2026: как внедрить анализ состава ПО для DevSecOps и КИИ

Log4Shell в 2021 году показал, что компании не знают, что именно работает в их продакшене. SBOM (Software Bill of Materials) — машиночитаемый манифест всех компонентов ПО — стал ответом на этот вопрос. В России тема набирает обороты: ФСТЭК включил SBOM в методические рекомендации для систем КИИ, а SCA-сканеры (Software Composition Analysis) уже входят в стандартный DevSecOps-пайплайн зрелых команд.

SBOM и SCA: в чём разница

SBOM (Software Bill of Materials) — документ с перечнем всех компонентов ПО: библиотеки, зависимости, их версии, лицензии, поставщики. Аналог «состава продукта» на упаковке еды. Форматы: CycloneDX (рекомендован ФСТЭК), SPDX (стандарт Linux Foundation).

SCA (Software Composition Analysis) — инструмент автоматического анализа зависимостей на уязвимости и лицензионные риски. SCA-сканер генерирует SBOM и сравнивает компоненты с базами уязвимостей (NVD, OSV, российские БДУ ФСТЭК).

Простое правило: SBOM — артефакт (документ), SCA — процесс (инструмент, который его создаёт и проверяет).

Регуляторный контекст для российских компаний

Для субъектов КИИ SBOM перестаёт быть опцией. Ключевые документы:

• Приказ ФСТЭК №239 — требования к безопасной разработке ПО для КИИ включают анализ используемых компонентов и отслеживание уязвимостей в них
• Методические рекомендации ФСТЭК по безопасной разработке 2025 — явно упоминают SBOM в формате CycloneDX как рекомендованный инструмент документирования состава ПО
• Реестр отечественного ПО — при подаче заявки требуется описание состава программных компонентов, что де-факто является требованием к SBOM-подобной документации

Для компаний вне КИИ регуляторного требования нет, но SBOM всё чаще становится требованием корпоративных заказчиков и государственных тендеров («документация состава ПО»).

Инструменты SCA в российском контексте

Три категории:

Open source SCA-инструменты:

• Syft (Anchore) — генерация SBOM из контейнеров, файловых систем, npm/pip/go-модулей. Поддерживает CycloneDX и SPDX. Бесплатный, активно развивается.
• Grype (Anchore) — сканирование SBOM на уязвимости по базе NVD/OSV. Работает в паре с Syft.
• OWASP Dependency-Track — full-featured платформа управления SBOM: хранение, анализ уязвимостей, нотификации. Self-hosted, подходит для команд с требованиями к размещению данных.

Российские и совместимые коммерческие решения:

• Solar appScreener (Ростелеком) — SAST + SCA, включён в реестр отечественного ПО, поддерживает экспорт в форматах, совместимых с требованиями ФСТЭК
• Positive Technologies PT Application Inspector — SAST + SCA с поддержкой российских баз уязвимостей (БДУ ФСТЭК)
• InfoWatch ARMA — в части анализа компонентов для промышленных систем КИИ

Интеграция в CI/CD-пайплайн

Минимальная схема интеграции SCA в GitLab CI (применимо к Gitverse, Forgejo и другим self-hosted вариантам):

sbom-scan:
  stage: security
  image: anchore/syft:latest
  script:
    - syft . -o cyclonedx-json > sbom.json
    - grype sbom:sbom.json --fail-on high
  artifacts:
    paths:
      - sbom.json
    expire_in: 90 days

Что происходит: Syft сканирует зависимости → генерирует SBOM в формате CycloneDX → Grype проверяет по базам уязвимостей → если найдена HIGH или CRITICAL уязвимость → сборка падает. SBOM сохраняется как артефакт для аудита.

Важный нюанс для российских команд: NVD (National Vulnerability Database) иногда недоступен из российских IP. Решение — использовать зеркало OSV или настроить прокси, либо переключиться на Grype с локальной базой данных.

Работа с ложными срабатываниями

Главная боль SCA — false positives: уязвимость есть в библиотеке, но в вашем коде соответствующая функция не вызывается. Без управления exceptions пайплайн быстро превращается в «красный, которого все игнорируют».

Подход к управлению: завести файл .grype.yaml или аналогичный ignore-файл с обоснованием каждого исключения — CVE, причина игнора, срок ревью. Ревью exceptions раз в квартал обязателен.