Композиционный анализ C/C++ проектов

Всем привет!

Разрешить зависимости, сформировать SBoM, проанализировать его на наличие уязвимостей и обработать их в соответствии с процессами, принятыми в компании.

Казалось бы, всё просто! Но дьявол, как и всегда, кроется в деталях. Особенно для C/C++ проектов, где (как правило) нет удобного пакетного менеджера/перечня зависимостей, который может послужить отправной точкой для исследования.

Как быть в этом случае? Ответ можно найти в статье от CodeScoring!

Ребята рассматривают:
🍭 Как можно выяснить название и версию библиотеки, с какими нюансами можно столкнуться
🍭 Как определить те зависимости, которые попали в конечный артефакт/поставку
🍭 Почему для одного ПО может быть 2 разных SBoM
🍭 Где взять дополнительную информацию о библиотеке перед включением её в SBoM
🍭 Как связать найденные пакеты с уязвимостями, если PURL (не всегда) присутствует и не только

Каждый вопрос раскрывается достаточно подробно, с примерами и рекомендациями.

Помимо этого, рассматривается очень много различного рода нюансов, с которыми можно столкнуться при композиционном анализе C/C++ проектов.

Однозначно к прочтению!