ГОСТ ==== 1 апреля 2024 года был введён в действие ГОСТ Р 71206-2024 «Защита информации. Разработка безопасного программного обеспечения. Безопасный компилятор языков С/С++. Общие требования». SAFEC выполняет требования, предъявляемые этим стандартом к безопасному компилятору третьего, второго и первого классов. База данных компиляции по ГОСТ: опция --dump-sbom ================================================= ГОСТ Р 71206-2024 требует, чтобы для безопасного компилятора была реализована функция по журналированию процесса трансляции. Результат журналирования — база данных компиляции. В ней должны фиксироваться имена файлов—единиц трансляции и подключаемых файлов, их хэш-коды по ГОСТ 34.11-2018, команды компиляции. Также должна быть включена информация, позволяющая идентифицировать программы, задействованные в трансляции исходных текстов в исполняемый код, их настройки и конфигурационные файлы. Для создания подробной базы данных компиляции в виде JSON файлов безопасный компилятор предоставляет опцию --dump-sbom <DIR>. https://safecompiler.pages.ispras.ru/changelog/gcc/#introduce-sbom Подробное описание опции с примером работы можно найти в руководстве пользователя (README) безопасного компилятора в разделе «Журналирование процесса трансляции: --dump-sbom». Скрипт comp_db_parser из поставки SAFEC позволяет проанализировать «состав» ПО на уровне отдельных файлов. Он обходит полученную с помощью --dump-sbom базу данных компиляции от заданного результирующего файла и выводит множество «листовых» файлов, участвовавших в качестве входных при компиляции, и их хэши. Эта реализация журналирования выполнена на уровне драйвера (программа gcc) и компилятора (вспомогательные программы cc1/cc1plus). При этом она имеет ограничения — случаи, которые не поддержаны или принципиально не могут быть учтены в таком подходе. Например: - Если утилиты (ассемблер/компоновщик) вызываются напрямую, а не через gcc, эти команды не будут учтены. - Для генерируемых исходных файлов с точки зрения получаемой базы данных компиляции исходными будут считаться результаты генерации. - Если при компоновке используется linker script, меняющий имя выходного файла, оно будет учтено неправильно. - В режиме создания precompiled header'ов (.pch/.gch файлов) выходные файлы не учитываются правильно. (Пока не поддерживается.) - Набор конфигурационных файлов утилит в некоторой степени «угадывается» т.е. строится на основе наших знаний о тулчейне. Если потребуется его расширить, нужно будет внести изменения в компилятор. Sbom-trace — отдельная утилита, не зависящая от компилятора =========================================================== Перечисленные выше ограничения побудили нас создать инструмент, решающий задачу в общем виде. Рабочее название этого инструмента — sbom-trace. Он учитывает требования ГОСТ Р 71206-2024 в части журналирования процесса трансляции. Этот инструмент не зависит от компилятора и используемых языков программирования. Принцип его работы основан на перехвате системных вызовов с помощью ptrace. Его использование выглядит таким образом: sbom-tracer -p sbom-postprocessor.py <build...> где <build...> — команда сборки, sbom-postprocessor.py — скрипт, входящий в состав инструмента. Этот инструмент имеет свои ограничения: работает только под Linux, и его не получится применить, если в процессе сборки уже используется ptrace. Артемий Гранат представит этот инструмент в докладе «Идентификация реквизитов сборки через отслеживание системных вызовов» 21 июня на конференции OS DAY 2024. Аннотация и тезиcы: https://osday.ru/granat.html