В докладе на NeoQUEST-2025 (https://www.tgoop.com/tech_b0lt_Genona/5705), я затрону тему, а какие есть вообще идеи и подходы как выстроить процесс так, что бы полученным SBOM'ам можно было бы доверять.

Напомню, что SBOM очень важен, если вы хотите понимать, что "приехало" в приложение и окружение. Именно на SBOM опирается понимание того, что поставляется и какие уязвимости в продукте есть.

Класический SBOM с этим плохо справляется (см. 1 и 2 скрины)

Одним из фреймворков, который призван решить проблему целостности и прозрачности всей цепочки разработки является in-toto (https://in-toto.io/). Во главу угла в нём поставлена идея аттестации каждого из шагов, который происходит во время разработки.

> in-toto models the software supply chain as a series of “steps”. Supply chain owners, i.e. project owners or maintainers, define the set of actors authorized to perform each step and rules that govern the artifacts used and produced by the step. They can also include other arbitrary checks called “inspections” to be performed during the verification workflow. These policies are recorded in a piece of metadata called a supply chain “Layout”, which is cryptographically signed by the supply chain owners. As each step is performed, one or more attestations are generated recording various aspects of the process, and during verification, in-toto applies the policies in the layout against the set of attestations produced during the execution of the supply chain

https://slsa.dev/blog/2023/05/in-toto-and-slsa

Можно попробовать поиграться самому на примере
https://in-toto.io/docs/demo/

Имплементации
https://github.com/in-toto/in-toto-java
https://github.com/in-toto/in-toto-golang

Репа с доработками и предложениями
https://github.com/in-toto/ITE/

На 4 скрине пример, link-файла, который является одним из этапов общей цепочки аттестации. В нём видно команду и файлы, которые участвуют в одном из шагов

Дальнейшим развитием этого подхода является включение аттестации in-toto в pipeline с дополнительной проверочной информацией - SBOMit (https://sbomit.dev/ + 3 скрин)

> Once an SBOMit document is produced, clients can perform extensive verification of the document in order to get a high degree of assurance about the software’s integrity. For example, a client could verify that the steps described in the document indeed took place; ensure the identity of who performed a particular step by inspecting link metadata; or ensure that all the steps indeed led to the final SBOM described by the SBOMit document.

https://openssf.org/blog/2024/06/26/a-deep-dive-into-sbomit-and-attestations/

Попробовать можно тут
- Recursively collects all system calls made during the compilation of your project.
- Parses the packages your project utilized during compilation.
- Generates an in-toto attestation for your project, detailing the materials used and the output products.
https://github.com/SBOMit/SBOMit-strace-prototype

В целом этот подход хорошо рассказан в докладе (откуда и взяты первые три скрина)
Your SBOM Is Lying To You – Let’s Make It Honest
https://www.youtube.com/watch?v=4ZsdNUJyZXU

Российские решения с которыми сам работал и/или пересекался и тоже относятся, по моему мнению, к тематике поста

- Buildography (ИСП РАН, https://www.ispras.ru/technologies/buildography/) - отслеживает системные вызовы в процессе сборки и собирает данные о файлах/каталогах, аргументы, вызываемые программы и т.д. и сохраняет всю собранную информацию для дальнейших проверок.

- sbom-checker (open source, https://gitlab.community.ispras.ru/sdl-tools/sbom-checker) - набор утилит, который позволяет обновить и проверить SBOM'ы согласно требованиям ФСТЭК. Главное в скриптах, по тематике поста, это то, что можно получить и провалидировать информацию по репозиториям зависимостей.

- CodeScoring (https://codescoring.ru/) - платформа в целом посвящённая SCA: построение SBOM'ов, построение цепочки зависимостей, защита от supply chain атак и т.д.

Если кто-то ещё что-то хочет добавить или поправить пишите в комменты или в личку.