Ключевые выводы
- Риск стал системным. В OWASP Top 10:2025 категория Software Supply Chain Failures заняла A03, а 50% участников опроса поставили её на первое место, что отражает переход проблемы из зоны отдельных библиотек в зону инженерного управления.
- Компонентный учёт без SBOM уже недостаточен. Для команды с 50 разработчиками даже 200-400 внешних зависимостей быстро превращаются в непрозрачный контур, если нет машинно-читаемого состава ПО.
- SCA закрывает только часть риска. Сканеры Snyk, Solar appScreener и аналоги помогают находить известные CVE и лицензионные нарушения, но не доказывают, что артефакт собран из доверенного исходного кода.
- Пять слоёв защиты работают только вместе. SBOM, SCA, проверка происхождения по SLSA, воспроизводимые сборки и проверенные базовые образы закрывают разные стадии атаки: от выбора зависимости до развёртывания контейнера.
- Российский контекст усиливает приоритет. В 2025 году Positive Technologies отнесла Россию к тройке наиболее атакуемых стран, а атаки на разработчиков, администраторов и инфраструктуру обновлений стали практическим риском для ИТ-команд.
- TCO нужно считать не по цене лицензии. Для 200 разработчиков реалистичная оценка начинается примерно с 9-18 млн ₽ в год с учётом инструментов, сопровождения, регламентов, интеграции в CI/CD и времени инженеров.
Контекст исследования
Supply-chain атака на ПО — это компрометация программного продукта через зависимость, инструмент сборки, репозиторий, инфраструктуру обновлений, контейнерный образ, расширение среды разработки или поставщика, которому доверяет команда. Для бизнеса опасность в том, что вредоносный код попадает не через прямой взлом периметра, а через легитимный путь доставки: пакетный менеджер, CI/CD, обновление, образ контейнера или плагин.
В 2026 году supply chain attack защита перестала быть отдельной задачей отдела информационной безопасности. Она стала частью инженерного управления: как команда принимает зависимости, кто подписывает артефакты, где хранится SBOM, какие сборки считаются доверенными, какие базовые образы разрешены и как быстро организация понимает, затронула ли её новая уязвимость.
Материал сфокусирован на практической защите российских компаний, но использует международные стандарты NIST SSDF, OWASP SCVS и OpenSSF SLSA, потому что именно они дают наиболее зрелую терминологию и проверяемые контрольные меры.
Методология
IT Institute сопоставил открытые публикации OWASP, NIST, CISA, OpenSSF, Sigstore, «Лаборатории Касперского» и Positive Technologies с практикой внедрения DevSecOps-контролей в командах разработки разного размера. Оценка стоимости дана как ориентир для планирования бюджета, а не как коммерческое предложение поставщика.
Охват исследования
- География: Россия и международные практики, применимые для российских команд разработки, интеграторов, финтеха, промышленности и ИТ-поставщиков.
- Сегмент: команды от 50 до 1000 разработчиков, использующие Git, CI/CD, контейнеры, открытые библиотеки, внутренние пакеты и внешних подрядчиков.
- Период: актуальные угрозы и защитные меры на 2025-2026 годы.
- Исключения: исследование не оценивает физическую безопасность дата-центров, криптографические алгоритмы как отдельный класс и юридическую проверку лицензий вне контекста SCA.
Цепочки атак и векторы компрометации
Что такое supply-chain атака на ПО
Supply-chain атака использует доверие. Разработчик доверяет пакету из npm или PyPI, DevOps-инженер доверяет базовому образу, продуктовая команда доверяет обновлению, администратор доверяет утилите, а заказчик доверяет поставщику. Если злоумышленник внедряется в один из этих узлов, вредоносный код может пройти обычный маршрут поставки и оказаться в продуктивной среде без классического взлома.
На практике выделяются 5 основных видов атак. Первый — вредоносная зависимость в пакетном менеджере, включая typosquatting и захват учётной записи сопровождающего. Второй — компрометация процесса сборки, когда артефакт отличается от проверенного исходного кода. Третий — подмена обновлений через инфраструктуру поставщика. Четвёртый — заражение контейнерных образов или базовых слоёв. Пятый — компрометация инструментов разработчика: расширений IDE, скриптов, MCP-серверов, генераторов кода и внутренних шаблонов.
Известные примеры 2025-2026 годов
В феврале 2026 года «Лаборатория Касперского» разобрала атаку на Notepad++, где инфраструктура обновлений была скомпрометирована после инцидента на уровне хостинг-провайдера. Согласно данным исследования, вредоносные цепочки активности наблюдались с июля по октябрь 2025 года, а злоумышленники меняли адреса управляющих серверов и полезные нагрузки. Для CISO это важный пример: даже популярный легитимный инструмент может стать каналом доставки вредоносного обновления.
В сентябре 2025 года Securelist описал риск вредоносных MCP-серверов. Это особенно актуально для команд, которые подключают ИИ-ассистентов к файловой системе, репозиториям и внутренним инструментам. Если MCP-сервер получает чрезмерные права, он становится новым элементом цепочки поставки и может собирать конфиденциальные данные при запуске инструмента разработчиком.
В октябре 2025 года Securelist сообщил о вредоносном npm-пакете, связанном с AdaptixC2. Пакетный менеджер в таком сценарии используется не как вспомогательный сервис, а как канал первичной доставки. В апреле 2026 года была описана компрометация сайта cpuid.com, через который распространялись установщики CPU-Z, HWMonitor и Perfmonitor 2. Это уже риск уровня администрирования: заражается не приложение компании, а привычный инструмент инженера.
SBOM как инвентаризация состава ПО
SBOM, или Software Bill of Materials, фиксирует состав программного продукта: прямые и транзитивные зависимости, версии, поставщиков, хэши, лицензии и связи компонентов. Его ценность проявляется не в момент генерации, а в момент инцидента. Когда появляется критическая CVE в библиотеке, CISO должен получить ответ за часы: какие продукты затронуты, где они развёрнуты, кто владелец, можно ли обновить компонент и какой риск для клиентов.
CISA описывает SBOM как инструмент прозрачности программной экосистемы. Для российской компании практический минимум — генерировать SBOM на каждую сборку, хранить его рядом с артефактом, связывать с номером версии и использовать при приёмке внешнего ПО. Без этого SCA-сканер видит только часть картины, а закупка фактически принимает продукт как «чёрный ящик».
SCA-сканеры и политика зависимостей
SCA-сканеры анализируют компоненты на известные уязвимости, устаревшие версии, рискованные лицензии и запрещённые пакеты. В российской практике часто рассматривают Snyk, Solar appScreener и другие инструменты, которые можно встроить в CI/CD. Но зрелость определяется не названием продукта, а политикой: что блокируется автоматически, что отправляется на ручное согласование, какие исключения живут 30, 60 или 90 дней и кто несёт ответственность за просрочку.
| Уровень контроля | Что проверяется | Типовое действие |
|---|---|---|
| Базовый | Критические CVE в прямых зависимостях | Блокировка сборки при CVSS 9.0+ |
| Средний | Транзитивные зависимости, лицензии, возраст пакетов | Согласование исключений владельцем сервиса |
| Зрелый | SBOM, происхождение, подписи, воспроизводимость | Политика допуска артефакта в среду |
Проверка происхождения по SLSA
SLSA от OpenSSF описывает уровни доверия к артефактам. Идея проста: компания должна понимать, кто изменил код, где он был собран, какие шаги выполнялись, кто подписал результат и можно ли проверить эту цепочку машинно. Provenance verification особенно важна для поставщиков ПО, потому что клиентам всё чаще нужен не только дистрибутив, но и доказательство происхождения.
На практике это означает переход от «у нас есть сборка в CI» к «у нас есть аттестация сборки, подпись, неизменяемый журнал и политика допуска». Для контейнеров проверка может выполняться через Sigstore Cosign: команда подписывает образ, а среда развёртывания принимает только образы с доверенной подписью и ожидаемой идентичностью сборщика.
Воспроизводимые сборки и проверенные базовые образы
Reproducible builds снижают риск скрытой подмены: если два независимых процесса из одного и того же исходного кода получают идентичный артефакт, доверие к сборке выше. Полная воспроизводимость сложна, особенно в крупных продуктах, но частичная дисциплина уже даёт эффект: фиксированные версии зависимостей, lock-файлы, запрет неуправляемых загрузок из интернета, контроль времени сборки и изоляция окружения.
Verified base images закрывают другой слой. Многие компании тщательно проверяют свой код, но запускают его поверх образов, скачанных без проверки подписи, происхождения и политики обновления. Базовый образ должен иметь владельца, допустимый реестр, подпись, срок поддержки и регулярный пересбор. Иначе контейнер становится удобной упаковкой для старых уязвимостей.
Чек-лист CISO: 12 первичных действий
- 1. Назначить владельца риска. Supply-chain безопасность должна иметь ответственного между CISO, CTO и руководителем платформенной команды.
- 2. Ввести реестр критичных продуктов. Начать с систем, которые обрабатывают персональные данные, платежи, коммерческую тайну или управляют производством.
- 3. Генерировать SBOM на каждую значимую сборку. Минимум — CycloneDX или SPDX для серверных приложений и контейнеров.
- 4. Подключить SCA в CI/CD. Проверка должна запускаться до попадания артефакта в реестр.
- 5. Запретить неутверждённые источники пакетов. Использовать прокси-репозитории и список разрешённых реестров.
- 6. Закрепить lock-файлы. Случайное обновление транзитивной зависимости не должно менять продуктивную сборку.
- 7. Подписывать артефакты. Контейнеры, пакеты и важные бинарные файлы должны иметь проверяемую подпись.
- 8. Проверять provenance. Сборка должна быть связана с исходным коммитом, средой CI и утверждённым процессом.
- 9. Ввести политику базовых образов. Только проверенные образы из доверенных реестров, с понятным сроком поддержки.
- 10. Ограничить секреты в CI/CD. Токены публикации пакетов и ключи подписи не должны быть доступны обычным задачам сборки.
- 11. Проверить инструменты разработчика. Расширения IDE, MCP-серверы и локальные скрипты включить в модель угроз.
- 12. Отработать сценарий отзыва. Команда должна уметь быстро отозвать пакет, пересобрать артефакт и найти все затронутые установки.
Практики защиты по контурам
| Размер команды | Минимальный контур | Оценочный TCO в год | Основной источник затрат |
|---|---|---|---|
| 50 разработчиков | SBOM, SCA в CI, политика зависимостей, ручные исключения | 3,6-7,5 млн ₽ | Инструменты, 0,3-0,5 ставки инженера ИБ, настройка процессов |
| 200 разработчиков | SBOM-репозиторий, SCA, подпись контейнеров, контроль базовых образов | 9-18 млн ₽ | Лицензии, сопровождение CI/CD, владелец платформенного контроля |
| 1000 разработчиков | Политики допуска, provenance, SLSA-профиль, автоматизация исключений | 24-48 млн ₽ | Платформенная команда, интеграция с реестрами, аудит поставщиков |
Интерпретация
Главная ошибка при внедрении supply chain attack защиты — начинать с покупки сканера и считать задачу закрытой. Сканер полезен, но он не отвечает на вопросы о происхождении артефакта, доверии к среде сборки, правах токена публикации и допустимости базового образа. Поэтому зрелая модель строится как инженерный контур, где каждый артефакт имеет состав, происхождение, подпись, владельца и статус допуска.
- Для CTO: риск нужно встроить в платформу разработки, иначе безопасность будет тормозить команды ручными согласованиями.
- Для CISO: приоритет — определить критичные продукты, минимальный набор обязательных контролей и процесс исключений с ограниченным сроком действия.
- Для DevOps: CI/CD становится точкой принудительного контроля: без SBOM, подписи и проверенного образа артефакт не должен попадать в продуктивный реестр.
- Для закупки: требования к поставщикам ПО должны включать SBOM, описание процесса сборки, политику обновлений и порядок уведомления об уязвимостях.
Рекомендации
- Начните с инвентаризации. За 30 дней можно собрать список критичных приложений, реестров пакетов, CI/CD-систем, контейнерных реестров и владельцев сервисов.
- Сделайте SBOM обязательным для новых релизов. Это даст быстрый эффект при разборе CVE и подготовит основу для требований к поставщикам.
- Настройте SCA как политику, а не как отчёт. Критические уязвимости должны блокировать сборку, а исключения должны иметь владельца и дату пересмотра.
- Подписывайте контейнеры и проверяйте подпись при развёртывании. Sigstore Cosign и аналогичные механизмы уменьшают риск подмены образа между сборкой и средой.
- Выделите доверенные базовые образы. Разработчики не должны самостоятельно выбирать случайные образы из публичных реестров для продуктивных сервисов.
- Свяжите тему с DevSecOps-планом. Подходы из DevSecOps Q2 2026 и практики SBOM и SCA в России 2026 стоит использовать как единый контур, а не как два отдельных проекта.
Выводы
Supply-chain атаки стали практическим риском для российских ИТ-команд, потому что современная разработка зависит от открытых библиотек, внешних инструментов, контейнеров, CI/CD и поставщиков. Защита требует не одного продукта, а управляемой цепочки доказательств: из чего собран продукт, где он собран, кем подписан, из какого образа запущен и какие исключения приняты бизнесом.
Для большинства компаний разумная стратегия на 2026 год — не пытаться сразу построить идеальный SLSA-контур, а закрыть пять слоёв по приоритету: SBOM, SCA, проверка происхождения, воспроизводимость сборок и доверенные базовые образы.
Supply chain attack защита — это зрелость инженерной системы: компания должна доверять не обещаниям, а проверяемым артефактам, политикам и журналам сборки.
- Оценочный TCO. Стоимость рассчитана как ориентир и зависит от выбранных инструментов, модели лицензирования, доли собственных разработок и зрелости CI/CD.
- Открытые источники. Анализ примеров ограничен публично опубликованными отчётами и не включает закрытые данные расследований.
- Разный уровень зрелости команд. Для организаций без централизованного CI/CD внедрение будет дороже и дольше, чем для платформенных команд с едиными реестрами.
- Регуляторная интерпретация. Упоминание ФСТЭК дано в контексте общих требований к безопасной разработке и защите информации, а не как юридическое заключение.
FAQ о supply chain attack защита
Что такое supply-chain атака на ПО простыми словами?
Это атака через доверенный элемент разработки или поставки: библиотеку, обновление, контейнерный образ, инструмент сборки, расширение IDE или поставщика. Злоумышленник не обязательно взламывает продуктивный сервер напрямую. Он может внедрить вредоносный код в зависимость, скомпрометировать учётную запись сопровождающего пакета или подменить артефакт в процессе сборки. Поэтому защита строится вокруг контроля состава ПО, происхождения артефактов, подписей, доверенных реестров и политики допуска в среду.
Чем SBOM отличается от SCA-сканера?
SBOM отвечает на вопрос «из чего состоит продукт», а SCA-сканер отвечает на вопрос «есть ли в этих компонентах известные риски». SBOM — это инвентарная ведомость компонентов, версий и связей. SCA использует такую информацию или собственный анализ, чтобы найти CVE, устаревшие зависимости и лицензионные проблемы. В зрелой модели они работают вместе: SBOM хранится как артефакт релиза, а SCA регулярно проверяет его при сборке, публикации и появлении новых уязвимостей.
Достаточно ли Snyk или Solar appScreener для защиты от supply-chain атак?
Нет, одного SCA-инструмента недостаточно. Он важен для поиска известных уязвимостей и контроля зависимостей, но не подтверждает происхождение сборки, не гарантирует неизменность артефакта и не защищает от подмены базового образа. Для практической защиты нужны дополнительные слои: подпись артефактов, проверка provenance по SLSA, доверенные реестры, контроль секретов CI/CD, воспроизводимые сборки и регламент исключений. Инструмент закрывает часть задачи, а не весь риск.
Какие требования к поставщикам ПО стоит включить в договор?
Минимальный набор требований: предоставление SBOM в формате CycloneDX или SPDX, описание процесса безопасной разработки, срок уведомления о критических уязвимостях, порядок выпуска исправлений, подтверждение контроля зависимостей, сведения о подписи артефактов и правилах сборки. Для критичных систем стоит запрашивать доказательства происхождения артефактов, результаты SCA-проверок и описание политики доступа к CI/CD. Это переводит разговор с общих обещаний безопасности на проверяемые материалы.
Сколько времени занимает внедрение supply chain attack защиты?
Первый рабочий контур обычно можно собрать за 6-10 недель: инвентаризация критичных приложений, генерация SBOM, подключение SCA в CI/CD, политика блокировки критических CVE и список доверенных базовых образов. Более зрелый уровень с подписью контейнеров, проверкой provenance, централизованным хранилищем SBOM и автоматизацией исключений занимает 4-9 месяцев. Срок зависит от количества команд, разнородности стеков и того, насколько централизованы сборки и реестры.
*Глубинный разбор. Источники указаны построчно. Авторские интерпретации помечены явно.*