Контроль уязвимостей сторонних артефактов в процессе безопасной разработки

Одной из ключевых практик безопасной разработки является управление уязвимостями в сторонних компонентах. Для решения этих задач разработчики, как правило, прибегают к следующим инструментам:

• Статический анализ кода (SAST) — выявление уязвимостей на этапе написания кода посредством проверки исходного кода без необходимости запуска.
• Динамическое тестирование (DAST) — тестирование работающего приложения для обнаружения рисков, проявляющихся в режиме реального времени.
• Анализ компонентов (SCA) — сканирование сторонних библиотек и зависимостей на наличие известных уязвимостей.

Кроме того, важно понимать, что контроль безопасности внешних артефактов и зависимостей – это не просто периодическое тестирование, а системный процесс, последовательно реализуемый на всех этапах их жизненного цикла.

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

Первичный анализ сторонних компонентов

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

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

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

Создание политик управления зависимостями

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

Мы считаем правильным использовать расширенный список параметров и комбинировать их.

Не все уязвимости одинаково опасны, поэтому на данном этапе ключевая задача — отделить «шум» от критических рисков, используя структурированный подход. Что полезно учитывать при анализе:

• CVE (Common Vulnerabilities and Exposures) – список известных уязвимостей в ПО различного типа, в том числе opensource-компонентах.
• CWE (Common Weakness Enumeration) – список потенциальных недостатков в дизайне кода.
• Возраста артефакта – библиотеки, созданные совсем недавно, как минимум, нуждаются в дополнительной проверке.
• CVSS (Common Vulnerability Scoring System) — скоринг уязвимости по шкале от 0 до 10.
• EPSS (Exploit Prediction Scoring System) — прогноз вероятности эксплуатации уязвимости.

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

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

И еще раз подчеркнем, что политики безопасности должны применяться во время запроса стороннего компонента, а не после его развертывания.

Прослеживаемость цепочки поставок

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

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

Кроме того, необходимо внедрить практику генерации Software Bill of Materials (SBOM) – реестра компонентов, входящих в состав той или иной сборки. Стандартные инструменты для создания SBOM – CycloneDX или SPDX, которые позволяют документировать все сторонние библиотек, зависимостей и их версий.

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

Внедрение лучших практик по контролю безопасности зависимостей

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

• Загрузку внешних артефактов нужно производить из доверенных источников. Например собственного репозитория, где имеются только провалидированные артефакты.
• Необходимо внедрить и поддерживать в компании процесс регулярного мониторинга и обновления сторонних компонентов.
• Хорошая практика – проведение регулярного аудита кода, чтобы минимизировать количество используемых библиотек. Удаляйте неиспользуемые или избыточные зависимости, чтобы сократить возможную поверхность атаки.

Практические проверки

Эффективность любой защиты проверяется «в бою». Это касается и безопасности цепочки поставок. Мы рекомендуем периодически моделировать соответствующие атаки и тестировать инфраструктуру и процессы управления зависимостями. Такие «учения» помогут выявить слабые места и улучшить защиту.

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

Эти шаги помогут создать надежный процесс управления сторонними компонентами и зависимостями. снижая риски безопасности, обеспечивая соответствие стандартам ИБ и поддерживая высокое качество разработки.

Автор: Сергей Авраменко, руководитель направления безопасной разработки компании СICADA8.