״Поставщики программного обеспечения должны нести ответственность когда они не выполняют свой долг по заботе о потребителях, предприятиях или поставщиках критически важной инфраструктуры ״ (Белый дом).
Сегодня ожидается, что любой поставщик программного обеспечения возьмет на себя большую ответственность за обеспечение целостности и безопасности программного обеспечения посредством договорных соглашений, выпусков и обновлений программного обеспечения, уведомлений и устранения уязвимостей. Недавно межотраслевая рабочая группа ESF (Enduring Security Framework) выпустила руководство, включающее рекомендуемые передовые методы и стандарты, призванные помочь клиентам во внедрении мер безопасности в цепочке поставок программного обеспечения. В этой статье я более подробно остановлюсь на практических рекомендациях по использованию оценки рисков на основе SBOM в качестве эффективного механизма сортировки и определения приоритетов.
Сохраняются распространенные методы компрометации цепочек поставок программного обеспечения, в том числе использование недостатков конструкции программного обеспечения, включение уязвимых сторонних компонентов в программный продукт, проникновение вредоносного кода в сеть поставщика перед окончательной доставкой программного продукта и внедрение вредоносного программного обеспечения в развернутое программное обеспечение. в среде клиента.
Спецификация программного обеспечения (СБОМ) стал важнейшим элементом в обеспечении безопасности программного обеспечения и управлении рисками в цепочке поставок программного обеспечения. SBOM служит вложенным реестром, предоставляющим список ингредиентов, составляющих компоненты программного обеспечения.
Масштабное внедрение SBOM требует автоматизации и стандартизации инструментов при развертывании систем, разработке продуктов и обмене данными между поставщиками программного обеспечения и потребителями.
Есть несколько важных машиночитаемых Стандартные форматы СБОМ поддерживается промышленностью. CycloneDX и SPDX определяют способ создания, анализа и совместного использования SBOM. VEX — это дополнительная форма рекомендаций по безопасности, которая указывает, подвержен ли продукт или продукты известной уязвимости или уязвимостям. Таким образом, это дает возможность показать, что продукт не подвержен конкретной уязвимости, даже если эта уязвимость существует в его SBOM.
Сопоставление содержимого SBOM с программными продуктами, развернутыми на предприятии, может предоставить ценную информацию группам по безопасности приложений, реагированию на инциденты и криминалистическим группам, управлению рисками и закупкам. Ожидается, что организации будут генерировать и управлять большим объемом данных SBOM для внутренних продуктов, а также потреблять внешние данные, которыми необходимо эффективно управлять. Поэтому необходимо поддерживать процесс автоматизация СБОМ-ориентированное управление рисками в масштабе.
Использование SBOM и оценки рисков
Оценка рисков может служить средством создания сжатого обзора, полученного на основе содержимого SBOM, что позволяет быстро сравнивать его с внешними источниками данных и облегчает оперативное принятие решений на основе полученных SBOM и определения приоритетов.
- SBOM повышает прозрачность, тем самым улучшая управление программными активами, управление исправлениями, выявление технических недостатков и управление уязвимостями для организаций-клиентов. Он также имеет потенциал для извлечения происхождения компонентов для проверки целостности и доверия.
- Анализ согласованности содержимого SBOM между программными продуктами, внедренными на предприятии, дает ценную информацию для групп реагирования на инциденты, управления рисками и проверки процесса закупок.
Превращение SBOM в информацию о рисках в больших масштабах – обоснование оценки рисков
Ключевой задачей для каждого специалиста AppSec и директора по информационной безопасности является управление усталостью от оповещений в ваших продуктах и услугах. В том числе оценка внешних рисков, исходящих от сторонних программных компонентов.
Ключевыми препятствиями на пути внедрения являются устаревшая контрактная или лицензионная поддержка, которая может повлиять на доступность последующих исправлений и обновлений продуктов, а также экспоненциальный рост сложности зависимостей в программных продуктах, как с открытым, так и с закрытым исходным кодом.
A оценка риска — это метрика, используемая для прогнозирования текущих и будущих рисков программного обеспечения и его компонентов, которая может эффективно поддерживать расстановку приоритетов в масштабе.
Оценка риска = вероятность x влияние
Оценка рисков позволяет организациям понять риск своей цепочки поставок программного обеспечения на основе определенных факторов риска и предвидеть потенциальный будущий риск, связанный с конкретным программным продуктом на предприятии.
Эффективная оценка риска может иметь шкалу от 1 до 10 (например, CVSS и Scorecard), поэтому мы можем сопоставить каждый компонент риска по шкале от 1 до 10 для удобства использования.
Совокупная оценка риска: Во многих сложных системах и системах систем может существовать несколько SBOM как часть коллективного решения и, следовательно, набора оценок риска.
Компоненты оценки рисков:
1.Уязвимости: Сопоставление известных уязвимостей с использованием перечисления CVE и Оценка CVSS на основе доступных каналов, таких как NVD, OSV и Github Advisories.
2. Контекст от поставщиков: VEX и консультативный контекст от поставщиков, которые могут изменить решение об оценке уязвимости в контексте использования. Связывание SBOM с уязвимостями позволяет использовать флаги риска, а документы VEX позволяют потребителю расставлять приоритеты уязвимостей.
3. ЭПСС 3.0: Метрика возможности использования от FIRST, которая прогнозирует вероятность (от 0 до 1.0) эксплуатации в течение следующих 30 дней. Это эффективный дополнительный слой правдоподобия к оценке CVSS, которая может помочь определить приоритетность наиболее важных CVE, которые необходимо обработать в первую очередь.
4. КЭВ: CISA также создала общедоступный канал разведки об угрозах, известный сегодня как Каталог CISA KEV (известные уязвимости, пригодные для использования). В этом каталоге содержится около 5% всех выявленных CVE, которые, по данным CISA, использовались или активно использовались. Таким образом, это хорошая отправная точка для определения приоритетности уязвимостей, требующих устранения. Кроме того, это часть контрольного списка, который вы должны проверить перед окончательным утверждением выпуска новой версии.
5. Разведка угроз – Добавить дополнительные источники угроз и уязвимостей передают известные вредоносные пакеты (Примеры: частные каналы от Snyk, Sonatype, Graynoise и т. д.)
6. Репутация OSS: Открытая система показателей SSF независимо оценивает показатели производительности, влияющие на различные части цепочки поставок программного обеспечения, включая исходный код, сборку, зависимости, тестирование и поддержку проектов, репутацию проектов с открытым исходным кодом (рейтинг 1–10).
7. Производительность с течением времени: Критические уязвимости MTTR (среднее время восстановления) версии продукта/пакета могут дать соответствующий показатель эффективности рисков безопасности.
8. Влияние и контекст. В этом аспекте расстановка приоритетов на основе бизнес-контекста программного продукта поможет расставить приоритеты и сортировать лес уязвимостей.
Несколько примеров
- Критичность модуля/продукта: является ли это критически важным (чувствительность или критичность)
- В скольких продуктах у меня есть конкретная уязвимость?
- Воздействие внешних эффектов на услугу/компонент
9. Соблюдение требований – Лицензии: Лицензии как на проприетарное программное обеспечение, так и на программное обеспечение с открытым исходным кодом важны для проверки соответствия правовой политике организации.
Концепция уровней оценки рисков – добавление показателей риска в SBOM:
- Начните с перечислением CVE и оценкой CVSS на основе данных SBOM.
- Используйте и добавляйте контекст VEX, чтобы изменить приоритет критичности.
- Оценивайте CVE с высоким показателем EPSS (т. е. 0.6–1.0).
- Расставить приоритеты в списке KEV – адрес первый.
- Оценить по репутации OpenSSF (1-10) – выявить рискованные зависимости.
- Анализировать экспозиция во внешнюю сеть (с использованием вектора CVSS)
- Оценка накапливает риск по количество продуктов за каждую уязвимость.
- Оценить по этикетка критичности конкретного контейнера SBOM для бизнеса.
- Идентифицировать нарушение требований риски при использовании анализа зависимостей SBOM согласно лицензионной политике компании.
- Поделиться и управлять данными as аттестаты на платформе для совместной работы с рабочими процессами для других систем, таких как Jira и других, через API и в машиночитаемом виде.
Использование SBOM с оценкой рисков для практических случаев:
- Непрерывная сортировка уязвимостей для продуктов с использованием показателей риска для определения приоритетности плана работ по исправлению для всех продуктов.
- Сравнивайте продукты на основе показателей риска.
- Сравните и утвердите обновления новой версии перед развертыванием/выпуском.
- Отслеживайте разрыв технического долга, используя пороговые значения оценки риска для версий продукта.
- Создайте быстрый отчет о 50 основных рисках в моих наиболее важных продуктах.
- Анализ воздействия для ускорения реагирования на инциденты – в случае обнаружения активно эксплуатируемой уязвимости. В этом случае, время имеет значение чтобы быстро определить, как я подвергся воздействию и каков будет радиус взрыва на тепловой карте этого воздействия.
Как использовать платформу Scribe Hub для эффективного управления рисками:
- Централизованная платформа управления SBOM – Создавайте, управляйте и делитесь SBOM вместе с их аспектами безопасности: уязвимостями, рекомендациями VEX, лицензиями, репутацией, возможностью использования, картами показателей и т. д.
- Создание и развертывание безопасного программного обеспечения – Обнаруживайте взлом, постоянно подписывая и проверяя исходный код, образы контейнеров и артефакты на каждом этапе конвейеров CI/CD.
- Автоматизируйте и упростите безопасность SDLC – Контролируйте риск на вашей фабрике программного обеспечения и обеспечьте надежность кода, преобразуя безопасность и бизнес-логику в автоматизированную политику, обеспечиваемую средствами защиты.
- Включите прозрачность. Улучшите скорость доставки – Предоставьте командам безопасности возможности выполнять свои обязанности, оптимизируя контроль безопасности, не препятствуя результатам работы команды разработчиков.
- Обеспечьте соблюдение политики. Демонстрация соответствия – Отслеживайте и применяйте политики и управление SDLC, чтобы повысить уровень рисков программного обеспечения и продемонстрировать соответствие требованиям, необходимое для вашего бизнеса.
Два примера Писец Хаб Возможности анализа рисков представлены:
Уязвимости картированы по SBOM, оценка рисков осуществляется по данным CVSS, VEX, EPSS и KEV.
Временной ряд производительности версий SBOM с течением времени, показывающий MTTR — среднее время устранения критических выявленных уязвимостей.
Резюме
Оценка рисков на основе SBOM позволяет организациям оценивать риски цепочки поставок путем оценки заранее определенных факторов риска и прогнозирования потенциальных будущих рисков, связанных с конкретным программным продуктом на предприятии. Оценка риска служит количественной мерой для прогнозирования как текущих, так и будущих рисков, связанных с программным обеспечением и его компонентами.
Этот показатель оценки получен на основе показателей, полученных из SBOM, VEX и других каналов, и соответствует контенту, поддерживающему управление рисками в цепочке поставок (SCRM). При применении или оценке оценки риска следует учитывать такие факторы, как контекст использования программного обеспечения, способ доступа к нему или его изоляции, а также процессы и системы, которые оно поддерживает.
Scribe Hub служит платформой для совместной работы, предназначенной для извлечения, управления, сбора аттестаций и анализа рисков SBOM в масштабе. Эта платформа эффективно обрабатывает множество внешних источников данных, чтобы справиться с тонкостями сложных систем и программных продуктов.
Этот контент предоставлен вам Scribe Security, ведущим поставщиком комплексных решений для обеспечения безопасности цепочки поставок программного обеспечения, обеспечивающим современную безопасность артефактов кода, а также процессов разработки и доставки кода по всей цепочке поставок программного обеспечения. Подробнее.
Статьи по теме
