Как обеспечить безопасность цепочек поставок с помощью SCA
Обычно в сфере производства под цепочкой поставок понимается цепочка компаний, на которые организация полагается при создании продукта. Например, если вы выпускаете мобильные телефоны, то покупаете детали и комплектующие у поставщиков. Эти поставщики заказывают более мелкие детали у других компаний. А они полагаются на производителей сырья.
Цепочка поставок программного обеспечения (ПО) охватывает все компоненты, используемые для создания приложения. Только вместо производства товаров она включает разработку, вместо сторонних комплектующих — вспомогательные сервисы от поставщиков, вместо сырья — коммерческий код или библиотеки с открытым кодом (open-source).
Если не изучать риски в цепочке поставок ПО, уязвимость в одной из зависимостей может привести к компрометации инфраструктуры организации или ее клиентов. Рассказываем подробнее о том, что такое риск в цепочке поставок ПО и какие существуют решения для повышения ее безопасности.
Цепочка поставок включает в себя людей, процессы и технологии, которые участвуют в создании, распространении и обслуживании ПО. Это могут быть:
- разработчики, тестировщики, менеджеры проектов и другие члены команды;
- инструменты, технологии и платформы, такие как интегрированные среды разработки (integrated development environment, IDE), системы контроля версий и серверы сборки;
- партнеры и поставщики, которые предоставляют организации ресурсы и услуги. Например, внешняя команда разработки или поставщики облачного хостинга.
Безопасность цепочек поставок зависит от целостности корпоративных процессов в части разработки и распространения ПО. Компании следует изучить риски появления уязвимостей в этих процессах и внедрить средства контроля.
Злоумышленники часто атакуют цепочки поставок ПО, чтобы внедрить вредоносный код или бэкдор для будущего использования. Они могут проникнуть в цепочку поставок такими путями:
- через ошибки в коде;
- небезопасные конфигурации инструментов разработки;
- сторонние библиотеки или платформы, содержащие уязвимости;
- при взломе поставщиков или партнеров организации;
- через ошибки при развертывании конвейеров сборки, недостаточные проверки безопасности;
- незащищенные каналы распространения.
Анализ состава ПО (software composition analysis, SCA) не может защитить от всех рисков, связанных с цепочкой поставок. Но он позволяет автоматизировать процесс проверки зависимостей и устранения уязвимостей в них на каждом этапе процесса разработки, распространения и поддержки ПО.
SCA — класс инструментов для проверки целостности ПО, который помогает выявлять риски, связанные с компонентами от сторонних разработчиков и зависимостями с открытым кодом. Работу инструментов SCA можно разделить на несколько этапов:
- Сканирование менеджеров пакетов, файлов манифеста, исходного кода, бинарных файлов, образов контейнеров и других компонентов.
- Анализ компонентов и их версий, сравнение их с известными базами компонентов.
- Проверка наличия известных уязвимостей и оценка рисков.
- Подготовка отчетов для оценки рисков и устранения уязвимостей.
- Обеспечение непрерывного мониторинга и пересмотр результатов анализа.
Во время анализа SCA компилирует фрагменты кода зависимостей в спецификации ПО (software bill of materials, SBOM) и сравнивает их с базами известных уязвимостей. Некоторые инструменты SCA также находят проблемы с лицензиями на ПО и анализируют общее качество кода. Так специалисты могут выявить критические уязвимости и проблемы соответствия требованиям законодательства.
Помимо SCA, существует несколько видов инструментов для анализа кода и приложений, таких как SAST
На первый взгляд, SAST — это отличная альтернатива SCA‑сканерам, ведь в теории такие анализаторы могут закрыть все задачи по проверке кода. Но на практике ни один из этих инструментов по отдельности не гарантирует абсолютной безопасности.
SAST‑сканеры хороши для проприетарного кода, но для контроля зависимостей SAST‑анализаторы, скорее всего, не подойдут. Чем больше код компонента с открытым исходным кодом, тем больше ложноположительных срабатываний нужно верифицировать специалисту. А чем больше таких библиотек используется в проекте, тем больше правил нужно создать для SAST‑сканера.
Поскольку компоненты с открытым кодом часто составляют подавляющее большинство всего кода в проекте, SCA оказывается более эффективным инструментом. Решения SCA способны определить такие компоненты, проверить их на уязвимости и лицензионное соответствие, а для своевременного реагирования — подготовить рекомендации по исправлению обнаруженных ошибок. Для российских компаний SCA особенно актуален, ведь компоненты с открытым кодом и атаки на цепочку поставок стали особенно популярной мишенью для атак злоумышленников.
SCA и SAST не могут полноценно заменить друг друга, эффективнее применять их вместе. Если у вас уже используется SAST‑сканер, то включение в ваши процессы SCA не составит проблемы. Если же вы только начинаете строить безопасную разработку, то полезнее начать с SCA, а уже после интегрировать с SAST.
Модуль SCA в BI.ZONE SSDLC помогает учитывать весь код сторонних разработчиков, обеспечивает безопасность контейнеризированных приложений и инфраструктуры. В базе модуля хранятся данные по всем проектам с открытым кодом, которые используются для рекомендаций по устранению уязвимостей.
В модуле SCA интегрировано два популярных инструмента — Dependency‑Check и Trivy. Они позволяют увеличить область покрытия потенциальных уязвимостей:
- Dependency‑Check анализирует сторонние библиотеки и сравнивает их с базой данных уязвимостей. Инструмент можно интегрировать со средами разработки и инструментами CI/CD. Это позволяет автоматически проверять зависимости на уязвимости при каждом обновлении кода, уведомлять о них разработчиков.
- Trivy интегрируется с репозиториями кода для автоматического поиска уязвимостей в зависимостях, используемых в проекте. Он может анализировать кластеры Kubernetes и Docker‑образы для выявления уязвимостей в компонентах и операционных системах. Инструмент гарантирует безопасность контейнеризированных приложений перед их развертыванием.
Используя BI.ZONE SSDLC, вы также можете обнаружить уязвимости в коде, которые еще не попадали в общую базу данных уязвимостей. Интеграция решения BI.ZONE SSDLC и процесса разработки и развертывания позволяет контролировать зависимости ПО на протяжении всего жизненного цикла приложения.