Оценка безопасности цепочки поставок ПО: как проверить поставщиков, зависимости и сборку

Условный сценарий. Небольшая компания делает сервис онлайн-бронирования. В её продукт входят купленный у вендора SDK для распознавания документов, несколько сотен пакетов из публичного реестра (большая часть — транзитивные, о которых в команде никто не помнит), сборочный конвейер на облачных раннерах и виджет оплаты, который подгружает скрипт с CDN платёжного партнёра прямо на страницу оформления заказа. В понедельник команда выпускает релиз, в котором не меняла ни строчки собственного кода. Но в продакшен всё равно уехали новая минорная версия одной из транзитивных зависимостей, обновлённый образ сборочного раннера и свежая редакция партнёрского скрипта.

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

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

Что входит в оценку цепочки поставок ПО

Четыре уровня охвата

Первый уровень — закупаемое ПО и продукты вендоров: коробочные системы, SaaS с интеграциями, SDK и библиотеки, которые приходят в бинарном виде. Здесь у заказчика обычно меньше всего прозрачности, зато больше всего договорных рычагов.

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

Третий — конвейер сборки и выпуска, который превращает исходный код в развёртываемые артефакты: система контроля версий, CI/CD, раннеры, хранилище секретов, реестр артефактов и контейнерных образов.

Четвёртый — зависимости времени выполнения. Самый наглядный пример — сторонние скрипты, которые браузер пользователя загружает от имени вашего сайта: аналитика, чат-виджеты, платёжные формы, A/B-тесты.

Для каждого уровня нужно своё сочетание анализа документации, технического тестирования и договорной проверки. Один инструмент на все четыре уровня — частая ловушка.

Аудит процессов и техническая оценка — не одно и то же

NIST SP 800-204D посвящён встраиванию мер безопасности цепочки поставок в конвейеры CI/CD в рамках DevSecOps. Из него естественно вытекает важное различие. Аудит процессов отвечает на вопрос, кто владеет каждым этапом, кто согласует изменения и какие свидетельства этого остаются. Техническая оценка проверяет, где в конвейере проходят границы доверия и можно ли их пересечь: подменить зависимость, выполнить код на раннере, добраться до ключа подписи.

Обе работы нужны, но отвечают они на разные вопросы. Аккуратно оформленный регламент согласования релизов не доказывает, что раннер не выполнит код из чужого pull request с доступом к производственным секретам. О процессной стороне подробнее рассказано в материале про аудит процессов DevSecOps.

Почему одного сканирования поставленного артефакта недостаточно

MITRE публикует рейтинг CWE Top 25 Most Dangerous Software Weaknesses. Редакция 2025 года основана на анализе первопричин записей CVE из набора данных этого года. MITRE описывает эти слабости как часто легко обнаруживаемые и эксплуатируемые; по её оценке, они ведут к уязвимостям, которые позволяют полностью захватить систему, похитить данные или нарушить работу приложений. Для оценки цепочки поставок эти классы слабостей важны тогда, когда затронутое ПО закупается или попадает в другую организацию как зависимость.

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

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

Условный пример: у двух библиотек одинаковое число находок. У первой это остатки старого кода, и новых проблем с внедрением процесс уже не пропускает. У второй каждая новая функция приносит очередной SQL-запрос, собранный конкатенацией строк. Число совпадает, риск — нет.

Как провести оценку: от разрешения до повторной проверки

Каркас процесса по NIST SP 800-115

NIST SP 800-115 (Technical Guide to Information Security Testing and Assessment) вышел в сентябре 2008 года и заменил SP 800-42 2003 года. Формально документ делит оценку на три фазы: планирование, выполнение и работы после выполнения, куда входят анализ результатов, отчётность и выработка мер по устранению. Среди целей, которые он называет, — поиск уязвимостей в системе или сети и проверка соответствия политике или иным требованиям. Когда часть проверяемой системы принадлежит поставщикам, важны обе.

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

SP 800-115 соотносится с несколькими семействами мер защиты, включая System and Services Acquisition (приобретение систем и услуг), Risk Assessment, Assessment, Authorization and Monitoring и System and Information Integrity. Присутствие семейства про приобретение — хорошее напоминание: в охват входит не только то, что вы разрабатываете, но и то, что покупаете.

Рабочий цикл на практике

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

Всё начинается с инвентаризации: какие поставщики, компоненты и конвейеры существуют и что из них критично. Затем нужно письменное разрешение и правила проведения работ, согласованные с каждым владельцем систем, включая поставщиков, чьи среды могут быть затронуты. Дальше — изучение документации: практики разработки, перечни компонентов (SBOM, если поставщик его предоставляет), отчёты о прошлых оценках, политика раскрытия уязвимостей. Потом идёт разрешённое техническое тестирование поставленных артефактов и интегрированных приложений. Цикл завершается анализом с привязкой к требованиям конкретной версии стандарта и устранением с назначенными ответственными по обе стороны договора и датами повторной проверки.

1. ИнвентаризацияСоставить перечень поставщиков, компонентов, конвейеров и сторонних скриптов и ранжировать их по влиянию на бизнес.
2. РазрешениеСогласовать письменное разрешение и правила работ с каждым владельцем систем, включая поставщиков, чьи среды могут быть затронуты.
3. Документы и тестыИзучить практики разработки и перечни компонентов, затем провести разрешённое техническое тестирование артефактов и интеграций.
4. АнализСопоставить находки с требованиями конкретной версии стандарта и классами первопричин, указав тип доказательства.
5. Устранение и повторНазначить ответственных с обеих сторон договора, зафиксировать сроки и повторно проверить исправления.

Разрешение и среда: что можно утверждать по результатам

Перед тестированием продукта третьей стороны нужно подтвердить письменные полномочия: само размещение продукта в вашей инфраструктуре не определяет объём разрешённых действий, а лицензионный договор или условия SaaS могут их ограничивать. Разрешение перечисляет системы, допустимые техники, окна работ и контакты на случай сбоя.

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

Если такой охват собирается впервые, его стоит обсудить заранее — что принадлежит вам, что поставщикам, где нужно отдельное согласие и какие доказательства нужны. С этим можно прийти к Pentest.red через форму описания охвата. Важно понимать границу: пентест даёт технические находки и доказательства, но не является сертификацией, аттестацией или заключением о соответствии.

Конвейер сборки как граница доверия

Где проходят границы

Конвейер сборки — место, где исходный код становится тем, что реально попадает к пользователю. Поэтому его стоит рассматривать как цепочку границ доверия, а не как набор инструментов. Типичные вопросы технической оценки звучат так. Кто может изменить основную ветку в обход ревью? Выполняется ли на раннере код из pull request внешнего участника и есть ли у этого задания доступ к секретам? Откуда разрешаются зависимости — из внутреннего зеркала или напрямую из публичного реестра, и может ли публичный пакет с тем же именем вытеснить внутренний? Закреплены ли сторонние действия CI и базовые образы по неизменяемому идентификатору или по метке, которую владелец может переназначить? Кто имеет право записи в реестр артефактов?

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

Происхождение артефакта и его пределы

Спецификация SLSA 1.2 описывает происхождение сборки (build provenance) как проверяемые сведения, позволяющие проследить готовый артефакт до исходного кода и процесса сборки. Чтобы по ним решить, соответствует ли артефакт ожидаемому, нужно связать аттестацию с самим артефактом, проверить подпись, доверие к идентичности сборщика и соответствие полей заранее заданной политике ожиданий.

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

Таблица сводит уровни охвата, точки отказа и вид доказательства, который реально удаётся получить.

Требования с указанием версии: как сделать результаты сопоставимыми

ASVS как язык договора

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

В работе с поставщиками ASVS полезен ещё и как язык договора. Идентификаторы требований могут меняться между версиями, поэтому OWASP рекомендует записывать их с версией, например v5.0.0-1.2.5. Идентификатор без версии по умолчанию относится к последней редакции стандарта — то есть смысл ссылки в старом договоре может незаметно измениться. Списки требований публикуются в машиночитаемых форматах, включая CSV и JSON, поэтому их удобно встраивать в опросники, договоры и трекеры задач.

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

Остальные справочники и их роли

OWASP Web Security Testing Guide описывает процедуры тестирования. На момент подготовки исходного материала стабильной редакцией была 4.2, а версия 5.0 находилась в разработке, поэтому стоит заранее договориться, по какой версии работает исполнитель. OWASP Top 10 в редакции 2025 года — документ для повышения осведомлённости, отражающий широкий консенсус о самых критичных рисках веб-приложений. Это разумный минимальный ориентир, но не стандарт верификации. Одновременное существование редакций 2025, 2021 и 2017 годов лишний раз показывает, что ссылка «по OWASP Top 10» без года неоднозначна.

Здесь же важное ограничение. ASVS, WSTG и OWASP Top 10 ориентированы на веб-приложения. Для систем сборки, упаковки, мобильных SDK и других не-веб-компонентов нужны адаптированные критерии, и в отчёте стоит прямо указать, где справочные стандарты перестают быть применимыми.

Сторонний код в браузере: поставщик, которого нет в реестре закупок

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

Браузер даёт несколько механизмов, которые ограничивают последствия. Content Security Policy позволяет определить, какие ресурсы клиент может загружать для страницы, и помогает смягчать межсайтовый скриптинг и атаки внедрения данных. Cross-Origin Resource Policy позволяет сайту включить защиту от определённых межсайтовых запросов к своим ресурсам. Permissions Policy явно задаёт, какие функции браузера коду сайта разрешено использовать — например, камеру, геолокацию или платёжный API. Для внешних скриптов и таблиц стилей с фиксированным содержимым можно указать криптографический хеш Subresource Integrity: поддерживающий браузер не выполнит скрипт и не применит таблицу стилей, если полученные байты не соответствуют хешу. Для междоменного ресурса сервер поставщика должен разрешать запрос через CORS, а подключение должно использовать crossorigin. Если поставщик намеренно меняет содержимое по тому же адресу, выпуск нужно синхронизировать с новым хешем; иначе проверка заблокирует обновление.

Конфигурацию помогают проверить инструменты вроде Mozilla HTTP Observatory. Эти меры сокращают поверхность атаки, но не заменяют оценку самого поставщика кода. Строгая CSP, разрешающая домен платёжного партнёра, не поможет, если скомпрометирован именно этот домен.

Как расставить приоритеты по данным о слабостях

К CWE Top 25 за 2025 год прилагаются ещё два списка. On the Cusp содержит слабости, которые немного не дотянули до основного рейтинга. CWE Top 10 KEV Weaknesses ранжирует слабости, стоящие за уязвимостями, которые активно эксплуатируются по каталогу Known Exploited Vulnerabilities агентства CISA. Вместе они дают три плана: распространённые и опасные слабости, пограничные случаи и слабости, замеченные в реальной эксплуатации.

В работе с поставщиками эти списки удобно использовать двумя способами. Во-первых, спросите каждого критичного поставщика, как его процесс разработки предотвращает, выявляет и устраняет классы слабостей из этих списков. Конкретный ответ — какие проверки встроены в ревью, какие анализаторы и правила используются, как отслеживаются исправления — сам по себе говорит о зрелости. Уклончивый ответ тоже информативен. Во-вторых, смещайте техническое тестирование самых важных для вас компонентов в сторону этих классов. MITRE, например, отмечает, что внедрение команд ОС привлекает внимание злоумышленников. Если SDK передаёт пользовательский ввод во внешние утилиты, это очевидная точка для проверки.

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

Здесь нужна осторожность. Рейтинг, построенный на публичных записях CVE, отражает то, о чём сообщили и что проанализировали, а не все слабости во всех продуктах. Его стоит использовать для фокусировки усилий, но отсутствие находок у поставщика в этих классах не означает, что поставщик безопасен. Как превращать такие данные в очередь работ, подробно разобрано в статье про приоритизацию уязвимостей на основе риска.

Компромиссы, о которых стоит договориться заранее

Глубина против охвата

Глубокая верификация одного критичного поставщика по высокому уровню ASVS может стоить столько же усилий, сколько поверхностный обзор десятков малорисковых компонентов. Компромисс должен быть явным. Ранжируйте поставщиков по влиянию на бизнес и зафиксируйте это ранжирование в плане оценки, чтобы через полгода было понятно, почему одному уделили две недели, а другому — анкету.

Документальные доказательства против технических

Опросники хорошо масштабируются, но зависят от честности и компетентности того, кто их заполняет. Техническое тестирование даёт более сильные доказательства, но требует разрешения, сред и доступа, который поставщик может ограничить. Здесь напрямую работает принцип SP 800-115 об учёте преимуществ и ограничений каждой техники. Практическое правило — в каждой находке фиксировать, на каком виде доказательства она основана: «подтверждено тестированием», «заявлено поставщиком» или «выведено из документации».

Разовая проверка против повторяющейся

SP 800-115 вышел в 2008 году и полезен как справочник по процессу, а ASVS 5.0.0 и списки 2025 года могут пересматриваться. Любая оценка — снимок на дату проверки. Без графика повторов, привязанного к крупным релизам поставщика и обновлениям стандартов, со временем документ всё меньше говорит о текущем риске. Хороший повод для повтора — существенное изменение: новая мажорная версия SDK, смена CI-платформы, новый сторонний скрипт на чувствительной странице.

Как превратить находки в работу и решения о приёмке

Находка как инженерная задача

Результат оценки полезен, только если превращается в задачи с владельцами. Для каждой находки фиксируют основание доказательства, ответственного на стороне поставщика или внутри компании и условие повторной проверки; ссылку на требование с указанием версии и класс первопричины добавляют там, где они применимы. Повторная проверка — отдельная работа: в согласованных путях и сценариях нужно проверить, затрагивает ли исправление класс проблемы, а не только показанный пример; вывод остаётся ограничен этим охватом. О том, как это доказывать, рассказано в материале про проверку устранения уязвимостей после пентеста.

Чтобы результаты не остались отдельным техническим отчётом, их стоит связать с управлением рисками. Профили NIST CSF 2.0 позволяют описать текущее и целевое состояние, и тогда руководство видит результаты оценки цепочки поставок рядом с остальными показателями киберрисков.

Схема решения о приёмке

Схема решения — иллюстративная: окончательное решение принимает уполномоченный владелец риска с учётом контекста и остаточного риска; единая оценка в баллах его не заменяет. Поставщики и компоненты ранжируются по влиянию на бизнес и степени экспозиции. Для веб-приложений и API выбираются версия и уровень ASVS, а год OWASP Top 10 фиксируется как ориентир для повышения осведомлённости; для конвейеров сборки, упаковки, мобильных SDK и других не-веб-компонентов выбираются подходящие системные критерии с указанием версии. Затем решается, где нужно техническое тестирование, а где достаточно документов, и тестирование смещается к релевантным классам из CWE Top 25 и Top 10 KEV. Решение и его обоснование записываются, повторная оценка планируется на крупные релизы и обновления стандартов. Каждое решение должно прослеживаться до применимого критерия с версией и до типа доказательства.

Как выбрать исполнителя и что обсудить до начала работ

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

На какие стандарты и версии он будет ссылаться и будет ли в каждой находке идентификатор требования с версией? Как он разделяет анализ документации и техническое тестирование и как фиксирует тип доказательства? Охватывает ли процесс письменного разрешения системы поставщиков, и не начнётся ли тестирование без явного согласия каждого владельца? Может ли он показать образец отчёта с сопоставлением первопричин по CWE и разделом о проверке устранения? Как методика работает с не-веб-компонентами, конвейерами сборки и сторонним клиентским кодом? Как будут учитываться обновления стандартов, например выход новой редакции WSTG?

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

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

Итог: воспроизводимость важнее громкого отчёта

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

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