Перейти к содержанию

A03:2025 Уязвимости цепочки поставок программного обеспечения icon

Общие сведения.

Эта категория заняла первое место в опросе сообщества Top 10: ровно 50% респондентов поставили её на #1. С момента первого появления в Top 10 2013 года как «A9 — Использование компонентов с известными уязвимостями» риск расширился до охвата всех сбоев цепочки поставок, а не только связанных с известными уязвимостями. Несмотря на расширенный охват, сбои цепочки поставок по-прежнему сложно идентифицировать: только 11 CVE имеют связанные CWE. Однако в предоставленных данных эта категория имеет наибольшую среднюю частоту встречаемости — 5,19%. Соответствующие CWE: CWE-477: Использование устаревшей функции, CWE-1104: Использование неподдерживаемых сторонних компонентов, CWE-1329: Зависимость от компонента, который не может быть обновлён, и CWE-1395: Зависимость от уязвимого стороннего компонента.

Таблица оценок.

Число CWE Макс. частота встречаемости Ср. частота встречаемости Макс. охват Ср. охват Ср. взвешенная эксплуатируемость Ср. взвешенное воздействие Общее число встречаемостей Общее число CVE
6 9,56% 5,72% 65,42% 27,47% 8,17 5,23 215 248 11

Описание.

Сбои в цепочке поставок программного обеспечения — это сбои или иные компрометации в процессе создания, распространения или обновления программного обеспечения. Они часто вызваны уязвимостями или вредоносными изменениями в стороннем коде, инструментах или других зависимостях, на которые опирается система.

Вы, вероятно, уязвимы, если:

  • Вы не ведёте тщательного учёта версий всех используемых компонентов (как на стороне клиента, так и на стороне сервера), включая прямые и транзитивные зависимости.
  • Программное обеспечение уязвимо, не поддерживается или устарело: ОС, веб-/серверы приложений, СУБД, приложения, API, компоненты, среды выполнения, библиотеки.
  • Вы не проводите регулярное сканирование на уязвимости и не подписаны на бюллетени безопасности для используемых компонентов.
  • У вас нет процесса управления изменениями или отслеживания изменений в цепочке поставок, включая IDE, расширения и обновления IDE, изменения в репозитории кода, sandbox-среды, репозитории образов и библиотек, способы создания и хранения артефактов и т.д. Каждая часть цепочки поставок должна быть задокументирована, особенно изменения.
  • Вы не усилили каждую часть цепочки поставок, уделяя особое внимание контролю доступа и принципу наименьших привилегий.
  • В системах вашей цепочки поставок нет разделения обязанностей. Ни один человек не должен иметь возможность написать код и продвинуть его вплоть до производственной среды без контроля со стороны другого человека.
  • Компоненты из ненадёжных источников, в любой части технологического стека, используются в производственных средах или могут влиять на них.
  • Вы не исправляете и не обновляете базовую платформу, фреймворки и зависимости своевременно на основе оценки рисков. Это часто происходит в средах, где применение патчей — ежемесячная или квартальная задача, что оставляет организации уязвимыми на дни или месяцы до исправления.
  • Разработчики не тестируют совместимость обновлённых или пропатченных библиотек.
  • Вы не обеспечиваете безопасность конфигурации каждой части системы (см. A02:2025-Небезопасная конфигурация).
  • Ваш CI/CD-конвейер имеет более слабую защиту, чем системы, которые он собирает и разворачивает, особенно если он сложный.

Как предотвратить.

Необходимо наладить процесс управления патчами:

  • Централизованно генерировать и управлять Software Bill of Materials (SBOM) для всего вашего программного обеспечения.
  • Отслеживать не только прямые зависимости, но и их транзитивные зависимости, и далее по цепочке.
  • Сокращать поверхность атаки за счёт удаления неиспользуемых зависимостей, ненужных функций, компонентов, файлов и документации.
  • Непрерывно вести инвентарь версий клиентских и серверных компонентов (фреймворков, библиотек) и их зависимостей с помощью инструментов, таких как OWASP Dependency Track, OWASP Dependency Check, retire.js и т.д.
  • Непрерывно отслеживать источники, такие как CVE, NVD и Open Source Vulnerabilities (OSV), для выявления уязвимостей в используемых компонентах. Использовать инструменты анализа состава ПО, безопасности цепочки поставок или SBOM-инструменты для автоматизации процесса. Подписывайтесь на уведомления об уязвимостях для используемых компонентов.
  • Получать компоненты только из официальных (надёжных) источников по защищённым каналам. Предпочитать подписанные пакеты для снижения риска включения изменённого вредоносного компонента (см. A08:2025-Нарушение целостности ПО и данных).
  • Сознательно выбирать версию используемой зависимости и обновлять её только при необходимости.
  • Отслеживать библиотеки и компоненты, которые больше не поддерживаются или не выпускают патчи безопасности для старых версий. При невозможности применения патча рассмотрите переход на альтернативу или виртуальный патч для мониторинга, обнаружения или защиты.
  • Регулярно обновляйте CI/CD, IDE и другие инструменты разработчиков.
  • Избегайте одновременного развёртывания обновлений на всех системах. Используйте поэтапные или канареечные развёртывания для ограничения воздействия в случае компрометации доверенного поставщика.

Необходимо наладить процесс управления изменениями для отслеживания изменений в:

  • Настройках CI/CD (все инструменты сборки и конвейеры)
  • Репозиториях кода
  • Sandbox-областях
  • IDE разработчиков
  • Инструментах SBOM и создаваемых артефактах
  • Системах журналирования и журналах
  • Сторонних интеграциях (например, SaaS)
  • Репозиториях артефактов
  • Реестрах контейнеров

Усилите следующие системы, включив MFA и ограничив IAM:

  • Репозиторий кода (не допускайте попадания секретов, защищайте ветки, создавайте резервные копии)
  • Рабочие станции разработчиков (регулярное применение патчей, MFA, мониторинг и др.)
  • Сервер сборки и CI/CD (разделение обязанностей, контроль доступа, подписанные сборки, секреты с ограниченным областью применения, журналы с защитой от фальсификации и др.)
  • Артефакты (обеспечьте целостность через провенанс, подписание и временны́е метки, продвигайте артефакты вместо пересборки для каждой среды, следите за неизменяемостью сборок)
  • Инфраструктура как код (управляется как весь код, включая использование PR и контроля версий)

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

Примеры сценариев атак.

Сценарий №1: Доверенный поставщик скомпрометирован вредоносным ПО, что приводит к компрометации ваших компьютерных систем при обновлении. Наиболее известный пример:

Сценарий №2: Доверенный поставщик скомпрометирован таким образом, что ведёт себя вредоносно только при определённых условиях.

Сценарий №3: Атака на цепочку поставок Shai-Hulud в 2025 году стала первым успешным самораспространяющимся npm-червём. Атаки засеяли вредоносные версии популярных пакетов, которые использовали скрипт post-install для сбора и утечки конфиденциальных данных в публичные репозитории GitHub. Вредоносная программа также обнаруживала npm-токены в среде жертвы и автоматически использовала их для публикации вредоносных версий доступных пакетов. Червь охватил более 500 версий пакетов до его нейтрализации.

Сценарий №4: Компоненты, как правило, работают с теми же привилегиями, что и само приложение, поэтому уязвимости в любом компоненте могут иметь серьёзные последствия. Примеры эксплуатируемых уязвимостей компонентов:

  • CVE-2017-5638 — уязвимость удалённого выполнения кода в Struts 2, позволяющая выполнять произвольный код на сервере.
  • CVE-2021-44228 («Log4Shell») — уязвимость нулевого дня в Apache Log4j для удалённого выполнения кода, использовавшаяся в атаках с программами-вымогателями, криптомайнингом и других кампаниях.

Ссылки

Список связанных CWE