- 28,765
- 46
- 8 Ноя 2022
CISA и агентства 17 стран обновили минимальные требования к перечню программных компонентов SBOM.
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1200/675;margin-bottom:2rem;overflow:hidden">
<div itemprop="articleBody">Обычный список компонентов программы превращается в полноценный паспорт её происхождения. Агентство по кибербезопасности и защите инфраструктуры США ( CISA ) вместе с ведомствами ещё 17 стран обновило минимальные требования к перечню программных компонентов, известному как SBOM .
Такой перечень показывает, из каких библиотек, модулей и зависимостей состоит программа. Разработчики и заказчики могут быстро проверить, присутствует ли в продукте уязвимый компонент, кто его создал и какая версия установлена. Новое руководство заменяет документ 2021 года, который перестал учитывать возможности современных средств анализа программ.
Главное изменение касается полноты данных. Теперь SBOM должен охватывать все компоненты продукта, включая вложенные зависимости. Ограничения по глубине больше нет. Если одна библиотека использует другую, а та подключает третью, в перечне должна прослеживаться вся цепочка. Такой подход позволит компаниям увереннее исключать риск после того, как опубликуют новую уязвимость, а не тратить время на то, чтобы вручную проверять каждый продукт.
Авторы документа добавили десять новых полей. Среди них цифровая подпись создателя SBOM, название и версия формата, условия, при которых формировали перечень, название и версия применённого инструмента, версия самого документа, контрольная сумма компонента, алгоритм её расчёта и сведения о лицензии. Подпись поможет подтвердить происхождение файла и обнаружить изменения, а контрольная сумма позволит проверить целостность программного компонента.
Отдельные требования касаются неизвестных или скрытых сведений. Создатель SBOM должен прямо указать, каких данных у него нет, а какие сведения он намеренно не раскрывает. Организации смогут считать перечень неполным, если поставщик скрывает критически важную информацию о составе продукта. Для компонентов с неясным происхождением также потребуется явная пометка.
Новая версия распространяет базовые требования на программы с открытым исходным кодом, облачные службы и системы искусственного интеллекта. Для облачных продуктов и ИИ могут понадобиться дополнительные данные, однако авторы пока не включили их в общий минимум. Частые изменения облачных служб остаются отдельной проблемой, поскольку новый SBOM рекомендуется выпускать для каждой версии или сборки программы.
Документ также закрепляет автоматическую обработку как обязательный принцип. Организациям советуют принимать распространённые открытые форматы SPDX и CycloneDX и отказаться от устаревших версий. Машинная обработка позволит сопоставлять состав программ с базами уязвимостей и предупреждениями безопасности за минуты, а не проверять их вручную.
Обновлённые правила не вводят юридических обязанностей, но задают общий ориентир для разработчиков, покупателей и операторов программ. Авторы рассчитывают, что единые требования упростят обмен данными и ускорят реакцию на уязвимости в цепочках поставок.
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1200/675;margin-bottom:2rem;overflow:hidden">
<div itemprop="articleBody">Обычный список компонентов программы превращается в полноценный паспорт её происхождения. Агентство по кибербезопасности и защите инфраструктуры США ( CISA ) вместе с ведомствами ещё 17 стран обновило минимальные требования к перечню программных компонентов, известному как SBOM .
Такой перечень показывает, из каких библиотек, модулей и зависимостей состоит программа. Разработчики и заказчики могут быстро проверить, присутствует ли в продукте уязвимый компонент, кто его создал и какая версия установлена. Новое руководство заменяет документ 2021 года, который перестал учитывать возможности современных средств анализа программ.
Главное изменение касается полноты данных. Теперь SBOM должен охватывать все компоненты продукта, включая вложенные зависимости. Ограничения по глубине больше нет. Если одна библиотека использует другую, а та подключает третью, в перечне должна прослеживаться вся цепочка. Такой подход позволит компаниям увереннее исключать риск после того, как опубликуют новую уязвимость, а не тратить время на то, чтобы вручную проверять каждый продукт.
Авторы документа добавили десять новых полей. Среди них цифровая подпись создателя SBOM, название и версия формата, условия, при которых формировали перечень, название и версия применённого инструмента, версия самого документа, контрольная сумма компонента, алгоритм её расчёта и сведения о лицензии. Подпись поможет подтвердить происхождение файла и обнаружить изменения, а контрольная сумма позволит проверить целостность программного компонента.
Отдельные требования касаются неизвестных или скрытых сведений. Создатель SBOM должен прямо указать, каких данных у него нет, а какие сведения он намеренно не раскрывает. Организации смогут считать перечень неполным, если поставщик скрывает критически важную информацию о составе продукта. Для компонентов с неясным происхождением также потребуется явная пометка.
Новая версия распространяет базовые требования на программы с открытым исходным кодом, облачные службы и системы искусственного интеллекта. Для облачных продуктов и ИИ могут понадобиться дополнительные данные, однако авторы пока не включили их в общий минимум. Частые изменения облачных служб остаются отдельной проблемой, поскольку новый SBOM рекомендуется выпускать для каждой версии или сборки программы.
Документ также закрепляет автоматическую обработку как обязательный принцип. Организациям советуют принимать распространённые открытые форматы SPDX и CycloneDX и отказаться от устаревших версий. Машинная обработка позволит сопоставлять состав программ с базами уязвимостей и предупреждениями безопасности за минуты, а не проверять их вручную.
Обновлённые правила не вводят юридических обязанностей, но задают общий ориентир для разработчиков, покупателей и операторов программ. Авторы рассчитывают, что единые требования упростят обмен данными и ускорят реакцию на уязвимости в цепочках поставок.
- Источник новости
- www.securitylab.ru
