SCA-анализ и практика безопасности цепочек поставок ПО: в чем разница

Число атак на цепочки поставок, по сообщениям разных источников, выросло как минимум на 300%. Риск эксплуатации доверия вошел в топ-5 самых критичных операционных угроз, согласно отчету BCI Horizon Scan Report 2022. Сегодня только 20% компаний при взаимодействии с подрядчиками и поставщиками услуг используют меры безопасности, соответствующие специфике партнерства. Остальные применяют те же методы, что установлены для удаленных сотрудников. Менее 10% игроков проверяют защищенность поставщиков, но чаще всего эта процедура носит формальный характер.

Как результат, злоумышленники имеют много возможностей для атак и продолжают совершенствовать свои техники, чтобы быстрее обходить средства защиты и дольше оставаться незамеченными. Так, за последние несколько месяцев сразу два банка подверглись атакам, в которых использовалось вредоносное ПО с открытым исходным кодом. Эксперты утверждают, что это первые инциденты подобного вида.

Защититься от таких атак позволяют две ключевые практики: безопасность цепочки поставок ПО (Software Supply Chain Security) и анализ состава программных продуктов (Software Composition Analysis, SCA). Они связаны между собой, но в то же время имеют различия. Понимание этих расхождений необходимо для эффективного обеспечения защищенности.

В данной статье вместе с Антоном Башариным, техническим директором Swordfish Security, мы разберемся, чем отличаются практики и почему они так важны.

Почему происходят атаки на цепочки поставок

Относительно свежий пример атаки на цепочки поставок — инцидент, произошедший с сетью аптек Dis-Chem Pharmacies, которая работает в ЮАР. Компания сотрудничала со сторонним поставщиков базы данных. Его взломали, в результате чего были скомпрометированы персональные данные 3,7 миллиона клиентов сети.

Еще один пример — компанию Okta, разрабатывающую решения для многофакторной аутентификации, взломали через подрядчика, который занимался поддержкой клиентов от имени организации. В итоге хакеры получили доступ к основным системам и коммуникациям, а также могли атаковать, по оценкам Okta, 2,5% клиентов компании. Сами же злоумышленники сообщали, что имели возможность обнулить пароли и многофакторную аутентификацию 95% пользователей. Кроме этого, благодаря взлому Okta, хакеры смогли атаковать Microsoft, которая использовала решения компании.

Подобные инциденты происходят в результате реализации главных рисков цепочек поставок ПО. Среди них:

Уязвимый код — может привести к различным последствиям, вплоть до полной потери созданного ПО с раскрытием информации о функциях и принципах работы продукта.

Незащищенные компоненты сторонних производителей, в том числе open source software — они могут сильно облегчить задачи разработчиков, но при этом внести уязвимости и зависимости. Даже в самых популярных компонентах встречаются крайне опасные ошибки, например в 2021 году в библиотеке журналирования Log4j была обнаружена уязвимость Log4Shell, которая получила 10 из 10 баллов по шкале CVSS. Она проста в эксплуатации, с помощью нее можно удаленно выполнить произвольный код и получить полный контроль над системой.

Небезопасная цепочка поставок — ненадежные поставщики и партнеры способны стать самым слабым звеном, которое позволит атаковать разработчика и его клиентов. Сегодня этот риск закрывается редко, зачастую компании проверяют юридическую чистоту подрядчиков и смотрят на конфликт интересов. Зрелость процессов безопасности изучают лишь единицы, и в основном это происходит уже после атаки.

Незащищенные каналы распространения — 38% организаций обмениваются большими файлами со сторонними компаниями с помощью внешних бесплатных сервисов. При этом сотрудник, инициирующий отправку, чаще всего сам устанавливает требования к безопасности. Такой подход порождает риск перехвата и подмены злоумышленниками важной информации.

В числе других рисков можно выделить незащищенные конвейеры разработки, ненадежную цепочку инструментов и небезопасное развертывание ПО.

Реализация этих угроз способна вызвать следующие последствия:

• крупные расходы на устранение уязвимостей, выплату штрафов или компенсаций;

• репутационные потери: компания может лишиться доверия клиентов, но здесь также важно правильно вести себя после атаки в публичном поле, например, вышеупомянутая Okta сообщила об инциденте только спустя два месяца и пыталась «маневрировать» деталями, чем вызвала осуждение со стороны профессионального сообщества;

• юридическую ответственность, например, за халатность, нарушение нормативных актов или законов, связанных с защитой данных;

• поломку бизнес-процессов и, как результат, снижение производительности и уровня прибыли.

Какие задачи решает практика безопасности цепочек поставок ПО

Защита цепочек поставок предполагает комплекс мер по обеспечению безопасности и целостности процесса разработки и распространения ПО, начиная с этапа проектирования и заканчивая развертыванием и сопровождением программного обеспечения.

Цепочка поставок ПО включает в себя процессы, а также инструменты и технологии, применяемые для создания и распространения продукта: интегрированные среды разработки (Integrated Development Environment, IDE), системы контроля версий, серверы сборки и так далее. Также сюда входят все люди, которые работают над ПО, — разработчики, тестировщики, специалисты по контролю качества, ИБ-эксперты, менеджеры проектов и другие члены команды. Помимо внутренних стейкхолдеров, цепочка поставок включает в себя внешних партнеров, предоставляющих продукты для разработки и поддержки ПО, например облачные платформы, библиотеки, фреймворки.

Таким образом, обеспечение безопасности и целостности цепочки поставок ПО представляет собой объемный, комплексный набор активностей по повышению защищенности всех процессов системы. Поэтому практика является критически важной для общей безопасности и надежности продукта. При реализации всех ее зон ответственности компания сможет снизить количество уязвимостей до минимума и тем самым закрыть обозначенные выше риски, а также повысить доверие клиентов.

Что такое SCA-анализ и для чего он нужен

SCA — это анализ состава ПО, позволяющий отследить и идентифицировать компоненты, которые не просто использовались при разработке продукта, а вошли в конечный дистрибутив. Сегодня практика особенно актуальна, поскольку 90% компаний в целях сокращения ИТ-бюджета и сроков создания решений и снижения зависимости от поставщиков проприетарного ПО прибегают к внедрению готовых компонентов с открытым исходным кодом. 34% из этих организаций планируют нарастить активность в данном направлении.

В рамках SCA-анализа создается спецификация материалов ПО (Software Bill of Materials, SBOM). Это перечень компонентов с открытым исходным кодом и других элементов, которые входят в состав программного продукта. Спецификация содержит базовые сведения о каждом компоненте, такие как название, версия, лицензия, иногда также указывается тип элемента, например библиотека или фреймворк. Дополнительно SBOM может включать в себя информацию об уязвимостях, подлинности, дочерних зависимостях и другие контекстные сведения.

Эта практика в рамках защиты цепочек поставок ПО решает несколько важных задач:

Повышает прозрачность. Есть риск, что разработчики внедрят в код ряд пакетов с открытым исходным кодом, которые включают в себя другие компоненты open source, связанные в свою очередь с третьими продуктами и так далее. Нередко подобные зависимости уходят вглубь на много уровней, и именно в них встречаются уязвимости. Так, по данным исследования Snyk, 86% проблем безопасности платформы Node.js обнаруживаются в транзитивных зависимостях. При этом разработчики могут и не знать до конца, какой и чей код они внедряют в свой продукт. SCA-анализ помогает отслеживать зависимости и тем самым предостерегать себя от неприятных сюрпризов.

Находит уязвимости. SCA-инструменты способны в автоматизированном режиме отслеживать проблемы безопасности, приоритизировать их, давать рекомендации по исправлениям, которые помогут сэкономить время, и даже инициировать запросы на обновления при обнаружении уязвимостей. Платформы компонентного анализа различаются по широте функционала и точности проверок. Одни используют только общедоступные базы данных, другие объединяют несколько ресурсов в единую, постоянно дополняемую систему.

Обеспечивает непрерывный мониторинг. Инструменты SCA-анализа можно интегрировать с системами репозиториев. Это позволит автоматически сканировать код по мере его добавления в хранилище и обнаруживать уязвимости на ранних этапах, когда стоимость их устранения еще невысока. Также с помощью технологии SCA можно контролировать использование конкретных компонентов.

Проверяет соответствие лицензионным требованиям. Практика позволяет идентифицировать компоненты, которые используются с нарушением требований лицензий, и тем самым снижать юридические риски.

Вывод

Безопасность цепочек поставок ПО и анализ состава программных продуктов (SCA) — это разные практики, но каждая из них важна для обеспечения защищенности и качества решений. Первая носит глобальный характер, поскольку направлена на защиту комплекса процессов и инструментов, задействованных в разработке, тестировании и распространении ПО. Вторая выполняет точечные задачи по поиску зависимостей, уязвимостей и отклонений от требований лицензий и дополняет практику обеспечения безопасности цепочек поставок ПО.

Для организации эффективной защиты стоит использовать и другие технологии, такие как статическое тестирование (SAST), динамический анализ (DAST), сканирование секретов, корреляция и оркестрация (ASOC), инфраструктура как код (IaC). Также можно внедрить профилирование конвейеров, сканирование целостности и безопасности цепочки инструментов и другие методы, закрывающие вышеупомянутые риски. Все эти технологии в комбинации с первыми двумя практиками позволят в полной мере обеспечить безопасность цепочки поставок ПО и добиться высокого результата.