Скорость обнаружения новых уязвимостей постоянно увеличивается. В настоящее время оно составляет в среднем 15,000 2022 CVE в год. 26,000 год выделяется тем, что было зарегистрировано более XNUMX XNUMX новых CVE. Очевидно, что не все уязвимости имеют отношение к вашему программному обеспечению. Чтобы выяснить, является ли конкретная уязвимость проблемой, сначала необходимо выяснить, используете ли вы библиотеку или продукт, содержащий уязвимость, а затем выяснить, используете ли вы проблемную версию и модуль этой библиотеки. Наконец, вам необходимо проконсультироваться со своей командой разработчиков, чтобы узнать, относится ли эта уязвимость к вашему конкретному продукту и к тому, как вы использовали эту уязвимую библиотеку или продукт.
Процесс выяснения всего этого непрост и может занять довольно много времени. Том Алрич, известный эксперт по кибербезопасности, считает, что около 95% всех CVE, присутствующих в конкретном программном продукте, не подлежат эксплуатации.. Но если вы конечный пользователь или компания, которая собирается интегрировать стороннее программное обеспечение в свою систему, как вы можете определить проблемные 5%, чтобы можно было запросить надлежащее исправление или исправление?
Именно здесь возникла идея Появляется обмен уязвимостями (VEX). Цель VEX, как она определена руководство от Национального управления по телекоммуникациям и информации США (NTIA) в 2021 году, заключается в том, чтобы «предоставить пользователям (например, операторам, разработчикам и поставщикам услуг) дополнительную информацию о том, подвержен ли продукт конкретной уязвимости во включенном компоненте и, если она затронута, , есть ли рекомендованные действия по исправлению ситуации».
Прямо сейчас вы, вероятно, думаете: как мне получить эти документы VEX и начать проверять свои компоненты? Что ж, реальность использования VEX, как обычно, сложна.
Узнайте цель VEX
Проще говоря, VEX должен быстро и легко ответить на вопрос: «Пригодна ли моя версия этого программного обеспечения для этого?» уязвимость?.
Предполагается, что ответом на этот вопрос будет один из четырех основных вариантов:
- Не затронут: Никакого исправления этой уязвимости не требуется.
- Затронутый: Рекомендуется предпринять действия по исправлению или устранению этой уязвимости.
- Исправлена: Эти версии продукта содержат исправление уязвимости.
- Под следствием: Пока неизвестно, подвержены ли уязвимости эти версии продукта. Обновление будет предоставлено в более поздней версии.
Поскольку VEX должен быть одновременно машиночитаемым и автоматически генерируемым, идея состоит в том, чтобы где-нибудь иметь доступную для поиска базу данных этих документов, чтобы любая заинтересованная сторона могла запросить ее и получить необходимый ответ.
Поскольку предполагается, что 95% уязвимостей не могут быть использованы в каком-либо конкретном программном продукте, эта система предназначена для сокращения огромного списка уязвимостей, обнаруженных для каждого продукта, до тех, за которыми пользователь должен следить или запрашивать исправление или исправление. для.
Есть ряд интересных фактов об истории VEX.
Еще в 2020 году NTIA (Национальное управление США по телекоммуникациям и информации) начал обсуждать идею VEX как сопутствующего инструмента СБОМ (Спецификация программного обеспечения). В сентябре 2021 года NTIA опубликовало одностраничное введение и объяснение того, что должен делать VEX.
Позже работа над уточнением требований нового формата консультаций перешла под эгиду CISA – Агентства США по кибербезопасности и безопасности инфраструктуры, которое выпустило собственный документ в начале 2022 года я расскажу подробнее, а также о некоторых случаях использования, в которых должен был помочь документ VEX. В этом черновом документе определены минимальные обязательные поля документа VEX точно так же, как NTIA определило минимальные обязательные поля SBOM.
С тех пор было предпринято две крупные попытки создания машиночитаемого формата документации VEX:
- Команда Общая консультативная структура по безопасности (CSAF) был первым доступным форматом. Этот формат был выпущен в конце 2022 года OASIS Open, международной некоммерческой организацией, занимающейся разработкой стандартов с открытым исходным кодом для кибербезопасности, блокчейна, Интернета вещей и других областей.
- Циклон ДХ, стандартизированный формат для SBOM, запущенный OWASP (Open Web Application Security Project), который был адаптирован также для создания документов VEX.
CSAF — это всеобъемлющий формат, но для его успешного использования вам необходимо включить несколько полей и много метаинформации, что делает фактическое внедрение маловероятным. с форматом CyclonDX.
Почему VEX столкнулся с препятствием: выявление проблем, саботирующих его успех
VEX — хорошая идея, которая может предоставить ценную возможность быстро проверить, действительно ли конкретная уязвимость может быть использована в конкретном программном продукте.
Однако существует ряд проблем, которые пока тормозят его реализацию:
- Ответственность за подачу документов – кто должен отвечать за подачу необходимых документов VEX? Это производители программного обеспечения? Сторонние охранные фирмы или некоммерческие организации? Государственное учреждение? Что произойдет, если несколько источников предоставят противоречивую информацию?
- База данных VEX – кто или что должно сохранять и классифицировать информацию VEX? Если предположить, что в некоторых документах описываются уязвимые места в программном обеспечении, нет ли опасности, что информация попадет в чужие (злонамеренные) руки?
- Существующие форматы не охватывают должным образом вопрос версий и тем более проблему комбинированного управления версиями.
Комбинированные версии программного обеспечения/пакета относятся к практике объединения нескольких пакетов программного обеспечения или компонентов в один выпуск или установочный пакет.
Когда дело доходит до исправления уязвимостей, комбинированные версии программного обеспечения и пакетов могут как помочь, так и помешать этому процессу. С одной стороны, наличие единого установочного пакета, включающего все необходимые компоненты, может упростить процесс выявления и исправления уязвимостей. Вместо того, чтобы вручную идентифицировать и исправлять каждый отдельный компонент, вы можете просто применить исправление ко всему пакету.
Однако обратная сторона этого состоит в том, что если один компонент пакета уязвим, уязвимо все программное обеспечение. Это означает, что даже если некоторые компоненты пакета были исправлены, весь пакет все равно может оказаться под угрозой, если присутствует хотя бы один непропатченный компонент.
Допустим, версия 1 библиотеки А вашего программного обеспечения имеет уязвимость. Эта проблема проявляется только тогда, когда библиотека A присутствует вместе с библиотекой B версии 2. Существует исправление безопасности, но не все его установили. Это означает, что документ VEX об этой уязвимости в вашем программном обеспечении должен охватывать все возможные комбинации продукта, его версий, содержащихся в нем библиотек, их версий и возможных выпущенных исправлений. Это много сложной информации, которую нелегко выразить просто.
- Как VEX будет охватывать программное обеспечение, встроенное в аппаратное обеспечение, со всеми возможными версиями и исправлениями, доступными там? На кого будет возложена ответственность за исправление этого программного обеспечения, учитывая, что вы не можете легко открыть оборудование и исправить что-то самостоятельно?
Это лишь некоторые из проблем, которые любой автоматический инструмент для работы с VEX должен понимать и учитывать.
Не было бы проще, если бы вы могли запрашивать и получать информацию по любой версии?
Предположение, что лучший способ поделиться этой важной информацией — это документ, возможно, ошибочно. Создание достаточного количества документов VEX, чтобы охватить каждую комбинацию версий, исправлений и уязвимостей, — это важная задача, за которую, по понятным причинам, никто не хочет браться.
Писец создала платформу для отслеживания и обмена информацией, связанной с безопасностью, для каждой сборки конкретного программного проекта или продукта. В рамках этого каждая сборка генерирует точный SBOM и список уязвимостей, обнаруженных в продукте.
Scribe позволяет производителю программного обеспечения добавлять рекомендации в формате VEX к каждой из этих уязвимостей, чтобы отметить, что они не могут быть использованы, находятся ли они под расследованием и т. д. После выпуска версии вся информация о безопасности этой версии может быть передана заинтересованным третьим лицам, пользователям , регуляторы и так далее. Включение списка уязвимостей, а также консультативного списка VEX означает, что получатель должен иметь возможность просмотреть только те уязвимости, которые представляют собой потенциальную проблему в этом конкретном продукте. Это снимает большую нагрузку как с производителя программного обеспечения, который может внести свой продукт в белый список, так и с потребителя программного обеспечения, который точно понимает, какой уровень риска связан с конкретным программным продуктом.
Поскольку производитель программного обеспечения является единственным, кто может точно сказать, действительно ли конкретная уязвимость имеет отношение к конкретной версии продукта, он единственный, кто может добавлять и изменять рекомендации для своих собственных продуктов. Решение производителя программного обеспечения в этом отношении является окончательным и неоспоримым. Решение о том, кому поделиться этой информацией, также является прерогативой производителя программного обеспечения.
Поскольку Scribe сохраняет полную историю сборок продукта, SBOM и информацию о безопасности, пользователи могут легко запрашивать и получать эту информацию для любой версии, которую они могут использовать на протяжении всего жизненного цикла программного обеспечения.
Заключение
Помните, что любое приличное сканирование программного продукта в наши дни приведет к появлению сотен, если не тысяч возможных уязвимостей. Большинство людей не могут справиться с таким количеством. Наступает усталость от оповещений, и количество уязвимостей становится просто числом.
Возможность сокращения количества обнаруженных проблем до приемлемого уровня стала бы благом для производителей и пользователей программного обеспечения. Цель состоит в том, чтобы сосредоточиться только на реальных проблемах, чтобы производитель программного обеспечения мог исправить их как можно скорее.
Автоматизированные инструменты, такие как Писец предложите простой способ увидеть только актуальные уязвимости для каждого из ваших проектов и сборок, информацию, которой вы можете легко поделиться, что делает гору уязвимостей значительно меньшими и более управляемыми.
Однако важное предостережение заключается в том, что такое будущее, в котором мы можем легко видеть и реагировать только на соответствующие уязвимости, было бы невозможно без активного участия сообщества открытого исходного кода. Большая часть кода в наши дни состоит из значительного количества программного обеспечения с открытым исходным кодом, поэтому нам нужно, чтобы сопровождающие и разработчики таких библиотек принимали участие в обнаружении и устранении уязвимостей, которые можно использовать в их коде.
Проблема соответствующих уязвимостей, которые можно использовать, не исчезнет, поэтому всем нам следует найти наиболее эффективный и экономически выгодный способ получить ответ на вопрос: «пригодна ли моя версия этого программного обеспечения для этого?» уязвимость'.
Этот контент предоставлен вам Scribe Security, ведущим поставщиком комплексных решений для обеспечения безопасности цепочки поставок программного обеспечения, обеспечивающим современную безопасность артефактов кода, а также процессов разработки и доставки кода по всей цепочке поставок программного обеспечения. Подробнее.
Статьи по теме
