SBOM и импортозамещение: аудит зависимостей с Syft и Grype на отечественных дистрибутивах

НКЦКИ на прошлой неделе выпустил рекомендации по формированию и анализу Software Bill of Materials для организаций из реестра КИИ. Документ не директивный - именно рекомендательный - но в нынешней обстановке рекомендации от НКЦКИ игнорировать не принято. Плюс логика там понятная: если не знаешь, что у тебя вообще стоит, - импортозамещать нечего.

Мы как раз несколько месяцев занимаемся похожим вопросом у нескольких клиентов с объектами КИИ. Расскажем, как это выглядит на практике с инструментами, которые реально работают.

Зачем вообще SBOM именно сейчас

С виду кажется, что инвентаризация зависимостей - это базовая гигиена, о которой все знают. На деле в большинстве организаций из реестра КИИ картина такая: есть несколько серверов, на них установлены пакеты из штатного репозитория дистрибутива плюс что-то поставленное руками «в 2019 году при внедрении», плюс несколько JAR-ников или Python-пакетов в каталоге приложения, происхождение которых уже никто точно не помнит.

Проблема с западными зависимостями в этом контексте двойная. Первая - санкционная: ряд проприетарных компонентов уже не обновляется, а некоторые вендоры отозвали лицензии. Вторая - поддержка: open-source пакеты, которые обновлялись западными мейнтейнерами, иногда остаются без актуальных CVE-патчей в отечественных репозиториях - не потому что кто-то специально запретил, а просто по инерции.

Именно второе нас интересует в первую очередь при аудите.

Syft: что это и почему оно подходит

Syft от Anchore - инструмент для генерации SBOM. Он умеет сканировать файловую систему, Docker-образы, OCI-артефакты и выдавать состав в форматах SPDX или CycloneDX. Важно, что он работает полностью локально - никакого cloud-бэкенда, никакой телеметрии. Для изолированных сред КИИ это принципиально.

На практике мы делаем так. Syft запускается непосредственно на сервере или на его образе:

syft dir:/ -o cyclonedx-json > sbom.json

Для контейнерных окружений - по OCI-архиву образа. Для Java-приложений Syft разбирает вложенные JAR и WAR - это важно, потому что именно там чаще всего живут забытые зависимости со времён Log4Shell.

На Astra Linux SE 1.7 и РЕД ОС 7.3 Syft работает без проблем - собирается из исходников или ставится бинарным релизом. Пакета в штатных репозиториях нет, но это не критично для разовых аудитов. Для регулярного сканирования лучше положить бинарник во внутренний репозиторий.

Grype: анализ уязвимостей по SBOM

Grype - тоже от Anchore, работает в паре с Syft. Берёт сгенерированный SBOM и сопоставляет его с базами CVE - NVD, GitHub Advisory, OSV и рядом других. База скачивается локально при первом запуске, дальше можно работать offline. Для воздушно-изолированных сред мы заранее качаем базу и кладём в общий доступ:

grype db update
grype sbom:sbom.json --output table

Что важно понимать про Grype в контексте импортозамещения: он не знает про отечественные патчи. Если Astra Linux закрыла уязвимость в своём пакете, но имя и версия пакета в SBOM совпадают с уязвимой версией upstream - Grype это всё равно отметит. Это не баг, это особенность: нужно вручную верифицировать находки по бюллетеням безопасности самих дистрибутивов. У Astra Linux они есть, у РЕД ОС - тоже, хотя полнота и своевременность разная.

Что мы ищем конкретно

Анализ SBOM в контексте импортозамещения - это не просто «найти CVE». Мы смотрим на три категории:

• Компоненты с истекающей или истёкшей upstream-поддержкой. Например, Python 3.6 уже EOL, ряд версий Node.js тоже. Если они стоят в production-окружении - вопрос не только в уязвимостях, но и в отсутствии новых патчей в принципе.

• Проприетарные западные компоненты. Разные Oracle JDK, продукты IBM, части экосистемы Microsoft - всё, где лицензионная доступность под вопросом. Syft их видит в составе системы, дальше - ручная работа по проверке лицензий.

• Зависимости приложений, которые не ставились через пакетный менеджер. Это самый неприятный класс: pip install в production, npm-модули рядом с приложением, ручные установки в /opt. Именно их системный администратор обычно не помнит, и именно они чаще всего содержат что-нибудь интересное.

Что получается на выходе

По результатам сканирования нескольких серверов под управлением отечественных дистрибутивов картина примерно следующая: основная часть системных пакетов - это upstream open-source с русскоязычной поддержкой в рамках дистрибутива, и там всё относительно управляемо. Неприятные сюрпризы приходят именно из прикладного слоя - Python-зависимости, Java-библиотеки в составе прикладных систем, иногда вообще забытые установленные вручную инструменты.

Несколько конкретных наблюдений, которые повторяются:

• В Java-приложениях регулярно встречается Log4j 2.x до 2.17 - не в системных пакетах, а в самих JAR. Организации латали Log4Shell в декабре 2021 в части серверов, но не везде.
• Node.js-приложения тянут сотни npm-зависимостей, из которых десятки имеют известные CVE разного уровня критичности. Большинство некритичные, но два-три по-настоящему неприятных находим стабильно.
• Отдельная история с PHP-приложениями: composer.lock есть не у всех, а без него Syft видит только то, что установлено в файловой системе, но не тянет транзитивные зависимости полностью.

Ограничения подхода

Честно: Syft + Grype - это хороший старт, но не полная картина. Статический анализ состава не заменяет динамический анализ поведения, не видит конфигурационные уязвимости, не проверяет права доступа. Это именно инвентаризация и первичная оценка по CVE - один из слоёв аудита защищённости, а не самостоятельный ответ на все вопросы.

Также надо понимать, что SBOM - это слепок в момент сканирования. Если завтра поставят новый пакет - картина изменится. Для КИИ с высокой категорией это означает, что сканирование должно быть регулярным, а не разовым.

Рекомендации НКЦКИ по SBOM пока достаточно общие - методологии и обязательных форматов не предписывают. Но сам факт того, что регулятор начал на это смотреть, говорит о направлении. Мы считаем, что инвентаризация зависимостей - это то, что стоит делать независимо от регуляторных требований, особенно если в инфраструктуре есть слой прикладных систем, который никто не трогал с 2020 года.