Ограничения готовых бинарников

О чём

Предмет проверки — граница binary analysis: что система видит, когда ей подают уже собранный артефакт без сборочного контекста. ТЗ (п. 3.5) требует анализ артефактов сборки, включая архивы (.jar, .rar, .tar, .tar.bz2, .tbz2, .tar.gz, .tgz, .tar.xz, .txz, .war, .zip, .aar, .egg, .hpi, .nupkg, .whl) с рекурсивным анализом заданной глубины. Здесь важно отделить архивы и контейнеры (это работает) от нативных stripped/статически слинкованных исполняемых файлов и .a/.so (это не гарантировано). Случай, когда сборочный контекст есть, но код всё равно не опознаётся, — отдельная тема Статическая линковка и форки.

Что подтверждено

• CLI-сканер поддерживает анализ архивов и package-артефактов: перечисленные в ТЗ форматы архивов покрываются, заявлен рекурсивный разбор.
• Подтверждён анализ Docker/OCI образов и контейнерных registry.
• Для упакованных экосистемных артефактов (whl, nupkg, jar, war, egg, aar, hpi) идентификация компонентов работает как разбор пакета, а не как реверс бинарного кода.

Где проходит граница Архив или образ — это контейнер с метаданными и упакованными пакетами; их система разбирает по структуре. Нативный исполняемый файл, особенно stripped и статически слинкованный, — это непрозрачный вход без манифеста и без сборочного контекста.

Что не подтверждено или ограничено

• По материалам поставщика полноценный анализ уже собранных бинарников — особенно stripped и статически слинкованных — надёжно не решается.
• Идентификация нативных .a / .so / исполняемых файлов без сборочного контекста — зона риска: компонент и его версия могут не определяться.
• ТЗ использует один термин «binary analysis» и для архивов, и для нативных бинарников. Это смешение режимов: подтверждённая часть (архивы/контейнеры) шире декларируется, чем реально подтверждённая часть про native stripped executables.

Риск несоответствия Если в объёме ТЗ под «binary analysis» подразумевается надёжная идентификация компонентов в готовых нативных бинарниках (.a/.so/exe, в т.ч. stripped/статика), это не подтверждено и поставщиком обозначено как нерешённое. Закрывать только сборочным сканом (C C++ build scan make cmake qmake) либо переформулировать термин в ТЗ.

Что проверить на пилоте

Вопросы и приёмочные проверки - Какова точная граница binary analysis: какие форматы дают идентификацию компонента+версии, а какие — только факт наличия файла? - Подать на вход stripped statically-linked ELF и зафиксировать, что система опознаёт, а что нет. - Подать .a и .so без исходников/сборки и проверить распознавание компонентов. - Проверить рекурсивный разбор архивов на заданную глубину (вложенные .jar/.war/.tar.gz) — соответствует ли требованию ТЗ. - Согласовать в ТЗ разделение: «архивы/package artifacts/контейнеры» и «нативные бинарники» — как разные требования с разным статусом.

Связь

• Матрица соответствия требованиям OSA SCA — разрыв № 4 (готовые бинарники) и строка SCA про binary analysis архивов.
• Статическая линковка и форки — смежный, но иной случай: сборочный контекст есть, а компонент всё равно не опознан.
• C C++ build scan make cmake qmake — рекомендуемый обходной путь: инвентаризация на этапе сборки, а не по бинарнику.
• Приемочные сценарии пилота · Вопросы для пилота CodeScoring
• Документация: https://docs.codescoring.ru/user-guide/sca/