CLI-приложение для подготовки перечня заимствованных программных компонентов под требования ФСТЭК России и ГОСТ Р 56939-2024: генерация SBOM, валидация, обогащение ссылками на исходный код и ГОСТ-свойствами, объединение и экспорт в CSV/ODT.
Формат — CycloneDX 1.6 (JSON) с расширениями ГОСТ (GOST:attack_surface, GOST:security_function, GOST:source_langs, GOST:provided_by).
efs scan запускает внешний сканер — cdxgen или trivy — с настройками из конфига, поэтому команда сборки перечня одинакова на всех машинах и в CI. Для cdxgen параметры записываются в .cdxgenrc, для trivy задаются подкоманда (fs, image, repo) и дополнительные аргументы. Сам efs код не сканирует.
efs postprocess превращает машинный вывод в перечень:
- убирает поля, которые сканер добавляет для себя, и оставляет то, что требует схема;
- проставляет ГОСТ-свойства — из конфига поштучно или значением по умолчанию;
- подставляет ссылки на исходный код по purl, с приоритетом точной записи с версией над записью без версии;
- выводит язык программирования из экосистемы purl и пишет каждый язык отдельным свойством
GOST:source_langs, как требует ФСТЭК; - исключает компоненты, которые в перечень не входят:
exclude: trueуносит и те зависимости, которых больше никто не держит,exclude: "direct"убирает только сам компонент,exclude: falseоставляет компонент принудительно; - удаляет компоненты-манифесты (
package-lock.json,uv.lock,pom.xml), перенося их связи на корневой компонент, чтобы каскад не принял реальные зависимости продукта за ненужные; - заполняет сведения о самом продукте — название, версию, изготовителя, назначение, ссылку на исходники или
GOST:provided_by; - дописывает в конфиг компоненты, которых там ещё нет, чтобы следующий прогон видел полный список.
efs check отвечает на два разных вопроса: корректен ли файл и годится ли он к сдаче.
- валидация по схеме CycloneDX 1.6 с обнаружением дубликатов ключей JSON;
- отдельная схема для контейнерной формы перечня: проверяется, что образ не заявляет поверхность атаки и функции безопасности ниже, чем у входящих в него компонентов;
- проверка доступности ссылок на репозитории (
--check-vcs) — git, svn, hg и fossil, многопоточно, с кешированием результатов между запусками; - проверка ссылок на дистрибутивы исходного кода (
--check-source-distribution); - проверка заполненности: ГОСТ-свойства, языки, назначение образа, сведения о продукте, наличие либо ссылки на исходники, либо указания на сертифицированное СЗИ.
Коды возврата различают ситуации: 0 — перечень готов, 1 — ошибки схемы или недоступные ссылки, 3 — схема в порядке, но перечень не заполнен. Команда пригодна для проверки в CI без разбора вывода.
efs update ищет репозитории по purl: сначала через ecosyste.ms, затем через резолверы конкретных экосистем — PyPI, npm, Maven Central, NuGet, RubyGems, Debian Sources, Fedora, CentOS Stream, Rocky Linux, ALT Linux. Найденный адрес не записывается на веру, а проверяется как настоящий репозиторий. Команда также переносит выверенные вручную данные из прошлой ревизии перечня (--update), чтобы работа не повторялась при каждой сборке.
efs config find-vcs делает то же самое для конфига и пропускает компоненты, по которым решение уже принято: с заполненной ссылкой, исключённые и поставляемые в составе СЗИ.
efs merge собирает перечень уровня продукта из перечней отдельных сервисов: каждый входной файл становится одним компонентом, ГОСТ-свойства агрегируются по правилу yes важнее indirect важнее no, языки объединяются. Отдельный режим — слияние сырых отчётов trivy с дедупликацией компонентов, зависимостей и уязвимостей.
efs export csv и efs export odt выгружают перечень в таблицу и в документ по отчётной форме, отдельно для обычного перечня и для контейнерной формы.
Единый файл .efs-config.json описывает продукт, значения по умолчанию, настройки сканера и каждый компонент: ссылку на исходники, ГОСТ-свойства, языки, изготовителя, pedigree для форков, правило исключения. efs config init создаёт его из готового SBOM и обновляет при последующих запусках, efs config migrate переносит старые файлы маппинга, efs config status показывает, что осталось заполнить. Для первого знакомства есть интерактивный мастер efs init.
- Python 3.12 или выше
- cdxgen или trivy — для генерации SBOM
- git, subversion, mercurial — опционально, для проверки ссылок на репозитории
uv tool install efs-sbom # или: pip install efs-sbomИз исходников:
git clone https://github.com/happykust/efs.git
cd efs
uv syncefs scan # сгенерировать SBOM (cdxgen или trivy)
efs config init bom.json # создать конфиг из SBOM
# отредактировать .efs-config.json
efs postprocess bom.json result.json \
--app-name "МойПродукт" --app-version "1.0.0" --manufacturer "ООО МояКомпания"
efs check result.json # проверить схему и заполненность
efs export odt result.json perechen.odt # выгрузить документИли пройти всё через интерактивный мастер:
efs initefs check возвращает 0, если перечень готов, 1 при ошибках схемы и 3, если перечень не заполнен, — команда годится для проверки в CI.
Пример заполненного перечня — examples/example-sbom.json; он проходит efs check и годится как образец.
uv sync # зависимости, включая dev-группу
uv run pytest # тесты
uv run ruff check . # линтер
uv run ruff format . # форматированиеКак оформлять изменения и выпускать релизы — в CONTRIBUTING.md. Об уязвимостях сообщайте по процедуре из SECURITY.md, не через публичный issue. Правила общения — в CODE_OF_CONDUCT.md.
Проект является производной работой от sbom-checker, разработанного в Институте системного программирования РАН (ИСП РАН) и распространяемого на условиях Apache License 2.0. Атрибуция приведена в файле NOTICE.