По мнению экспертов, сам по себе SBOM-документ не является эффективным инструментом для оценки рисков.
Национальный институт стандартов и технологий (National Institute of Standards and Technology, NIST) и другие ведомства США активно продвигают так называемую спецификацию программного обеспечения (SBOM) как способ снижения рисков кибербезопасности цепочки поставок для потребителей.
SBOM представляет собой подробный список компонентов, модулей и библиотек, использованных при создании программного продукта. Однако по мнению специалистов из Google Open Source Security Team, сам по себе SBOM-документ не является эффективным инструментом для оценки рисков, и использовать его нужно только с привязкой к базам известных уязвимостей.
«Объединив эти два источника информации, потребители будут знать не только о том, из чего состоит их ПО, но также о связанных с ним рисках и о том, требуются ли какие-либо меры для их устранения», - считают эксперты.
Аналитики Google рассказали, как им удалось объединить SBOM-документ Kubernetes с Открытой базой уязвимостей (OSV). OSV обеспечивает как стандартизированный формат для сопоставления по нескольким базам данных, в том числе Github Advisory Database (GHSA) и Global Security Database (GSD), так и агрегированные данные из множества экосистем, начиная от Python и Golang и заканчивая Rust.
Для того чтобы командам безопасности было проще оценивать всю картину рисков, специалисты Google рекомендуют создателям SBOM, используя соглашение об именах наподобие Purl URL, включать в документацию ссылки для всех пакетов в цепочке поставок ПО. Такая схема идентификации позволит определяет экосистему и упростит идентификацию пакетов, считают эксперты.
Наш канал — питательная среда для вашего интеллекта