Поскольку списки компонентов программного обеспечения (SBOM) становятся все более необходимыми, а в некоторых случаях и обязательными для частных компаний и правительств по всему миру, они призваны обеспечить прозрачность и помочь организациям понять, что входит в состав их программного обеспечения. Но если SBOM настолько полезны, почему никто не знает, что с ними делать?
Понимание того, с чем работать
Современные приложения используют тысячи сторонних компонентов, в основном, но не полностью, с открытым исходным кодом (OSS, Open Source Software), и очень важно отслеживать их. Вот почему, в теории, SBOM очень полезны. Требование SBOM казалось настолько удачным, что как государственные учреждения, так и заказчики начали настаивать на том, чтобы каждый имел их у себя. Вам SBOM, и вам SBOM, всем SBOM!
Однако, как только все начали получать SBOM, возникла новая проблема: что с ними делать? Хотя SBOM важны, простой список всех компонентов в коде является неполной информацией, которая не позволяет действовать.
Чтобы сделать SBOM действительно полезными, специалистам по безопасности требовалось что-то другое. Что-то, что контекстуализировало бы массу находок в SBOM, чтобы помочь им понять, что действительно вызывает беспокойство, а что является просто ложной тревогой. Как однажды сказал Фрэнк Костанза: «Должен быть другой путь!» (с англ. „There had to be another way!“).
Оптимизация управления рисками
К счастью, есть еще один способ – VEX (Vulnerability Exploitability eXchange, обмен уязвимостями). VEX – это платформа для обмена информацией о возможности использования известных уязвимостей в контексте того, где и как они используются.
Разработчик VEX определяет уязвимости как:
- Эксплуатируемая – это означает, что уязвимость может быть использована злоумышленниками в текущей реализации и требует скорейшего исправления. Это то, на чем нужно сосредоточить внимание.
- Не эксплуатируемая – хотя уязвимость существует теоретически, такие факторы, как конфигурация приложения, означают, что злоумышленники не могут получить к ней доступ, что делает ее безвредной.
- Исправлена – уязвимость существовала, но для нее уже было применено исправление или патч.
- Исследуется – эта отметка означает, что требуется дальнейший анализ, чтобы определить, насколько эта уязвимость может быть использована. После рассмотрения потенциально эксплуатируемых уязвимостей, стоит обратить внимание на следующие.
С VEX, вместо того, чтобы просто иметь данные SBOM о зависимостях программного обеспечения, пользователь также получает информацию о конкретных уязвимостях в коде, который он использует, и о том, нужно ли их исправлять. Это экономит его время и часы разработки, которые были бы потрачены на отслеживание ложных срабатываний и определение приоритетности самых больших рисков, что в целом обеспечивает гораздо большую ценность для SBOM.
Примечания относительно выполненных или запланированных действий также могут быть включены в VEX.
Кроме того, документы в формате VEX являются машиночитаемыми (CycloneDX или SPDX), что позволяет интегрировать их в инструменты управления активами. Это обеспечивает большую автоматизацию управления рисками, что опять же экономит время и, в конечном итоге, деньги.
VEX также содержит прикладные данные о том, насколько серьезной является уязвимость, существуют ли способы ее устранения и нужны ли исправления. Информация, предоставленная VEX, позволяет командам безопасности определить, насколько безопасным является программное обеспечение поставщика, чего невозможно узнать только из SBOM.
Трансформация SBOM с помощью VEX
Наличие метода для системного описания и обмена данными об уязвимостях между организациями решает некоторые из самых больших проблем для инженеров безопасности. Если данные VEX указывают на то, что уязвимость не может быть использована, поскольку конечные пользователи не имеют доступа к соответствующей функции, это экономит время на поиск этой информации и устранение того, что не требует немедленного решения.
Скажем, кто-то сканирует свои системы и обнаруживает 40 уязвимостей в цепочке поставок программного обеспечения. Без VEX можно было бы потратить дни на устранение всех этих уязвимостей. Однако, имея данные VEX, видно, что 10 уязвимостей нельзя использовать, 20 из них имеют низкий уровень опасности и могут быть исправлены позже, а 10 являются критическими и могут быть использованы. Теперь можно определить приоритетность самых серьезных уязвимостей, запланировать исправление уязвимостей с меньшим риском на более поздний срок и проигнорировать те, которые нельзя использовать. Таким образом, благодаря VEX экономится много времени и оптимизируются рабочие процессы.
Внедрение SBOM является важным шагом на пути к современной безопасности программного обеспечения, но без правильного контекста они остаются неполноценными. VEX – это ключ к превращению SBOM в действенные, глубокие инструменты. Предоставляя важные данные о возможности эксплуатации, VEX позволяет организациям эффективно распределять ресурсы, уменьшить количество ложных срабатываний и сосредоточиться на устранении реальных угроз, экономя время, деньги и гарантируя более быстрое и безопасное развертывание программного обеспечения.
У Mend.io есть экспорт SBOM, обогащенный данными VEX, что позволяет клиентам превратить свои SBOM в эффективные инструменты управления рисками.
