Этикетка состава, которой всегда не хватало программному обеспечению
9 декабря 2021 года исследователь безопасности обнаружил уязвимость в Java-библиотеке Log4j. В течение 72 часов под угрозой оказались сотни миллионов систем.
Проблема заключалась не только в самой уязвимости. Проблема заключалась в прозрачности. Большинство компаний не знали, используется ли Log4j в их собственном программном обеспечении.
Этот момент превратил Software Bill of Materials (SBOM) в приоритетную задачу для советов директоров компаний.
SBOM — это инвентаризация каждого компонента вашего программного обеспечения. Она работает как этикетка состава для кода. В ней перечислены библиотеки с открытым исходным кодом, сторонние пакеты и внутренние части. Она включает версии и лицензии.
Современное ПО сложно устроено. Одно приложение часто использует от 500 до 1500 сторонних компонентов. Отслеживать их вручную невозможно.
Сегодня существуют два основных стандарта:
• SPDX: ориентирован на соблюдение лицензионных требований. Подходит для юридических отделов. • CycloneDX: ориентирован на безопасность. Подходит для команд DevSecOps.
Скорость вашего реагирования зависит от наличия SBOM. Во время кризиса Log4j компании с SBOM выявляли свои риски за считанные часы. Компании без них тратили недели на ручной аудит.
Недавние атаки, такие как XZ Utils, доказывают, что этот пробел все еще существует. Злоумышленники прячут бэкдоры в распространенных библиотеках. Без автоматизации вы их не заметите.
Нормативные требования также меняются:
• Указ президента США 14028: федеральные поставщики обязаны предоставлять SBOM. • Руководство FDA: для медицинских устройств требуются SBOM. • Закон ЕС о киберустойчивости (Cyber Resilience Act): требует наличия SBOM для программного обеспечения в ЕС к 2027 году.
Как начать:
- Выберите стандарт. Используйте CycloneDX для безопасности или SPDX для лицензий.
- Автоматизируйте генерацию. Используйте такие инструменты, как Syft для образов или Snyk для конвейеров.
- Свяжитесь с базами данных. Подключите ваш список к NIST NVD или OSV.
- Установите график. Генерируйте SBOM при каждой сборке.
Не пытайтесь исправить весь свой портфель сразу. Начните с одного приложения.
Помните, что SBOM — это диагностический инструмент. Он говорит вам, что у вас есть. Он не решает проблему за вас. Если SBOM показывает 23 уязвимости, вам все равно нужен план по их устранению.
Лучшие компании не просто имеют инструменты. У них есть процесс. Они знают, кто отвечает за зависимость, еще до того, как наступит кризис.
Source: https://dev.to/spicykim/the-nutrition-label-that-software-always-lacked-213 Full details: lucas8.com/what-is-sbom-software-bill-of-materials
