OWASP SPVS: Уроки обеспечения безопасности программного обеспечения Pipeline

Долгие годы злоумышленники атаковали приложения по одному. Теперь они изменили тактику: зачем взламывать одно приложение, если можно скомпрометировать все остальные? pipeline Кто строит много таких зданий? Xygeni's Раннее предупреждение о вредоносном ПО (MEW) обнаруженный 4,452 вредоносных пакета в 2025 году и На данный момент в 2026 году добавилось еще 1,281 человек.Каждый громкий инцидент последних нескольких лет затрагивал различное звено в цепочке разработки программного обеспечения:

• Солнечные ветры (2020)Компромисс в среде сборки; обновления с бэкдорами были отправлены 18 000 клиентам.
• Кодеков (2021)Неправильно настроенный образ Docker позволил злоумышленникам изменить скрипт загрузки bash, что привело к утечке секретов CI от более чем 23 000 клиентов.
• CircleCI (2023): кража сессионных cookie с ноутбука инженера привела к получению токенов доступа к производственной среде; каждому клиенту было предписано регулярно менять все секретные файлы.
• Бэкдор XZ Utils (2024) Многолетняя кампания социальной инженерии, охватившая практически все дистрибутивы Linux.
• tj-actions (2025) — каскадная ошибка в цепочке поставок GitHub Actions, которая привела к сбою компонента, используемого более чем 23 000 репозиториями.
• Атаки на Аква Триви и галочка (2026) — Кампания TeamPCP превратила два широко используемых сканера безопасности в средства атаки, а затем использовала украденные устройства. CI/CD учетные данные для последующей обработки в npm, OpenVSX и PyPI.

Каждая атака использовала разные части системы. pipeline: среда сборки, инструменты CI, зависимости, учетные данные разработчика, доверие к сопровождающему, изменяемые ссылки на артефакты. Большинство организаций реагируют на это с помощью точечного контроля, сканера в CI, двухфакторной аутентификации на поставщике идентификации, защиты ветвей. mainКак правило, отсутствует способ задать вопрос. Мы имеем систематическую страховку? , а не Мы не забыли включить X после последнего инцидента?

Поставщики решений в области безопасности приложений находятся под прицелом, поскольку компрометация одного из них затрагивает каждого клиента, доверяющего их продуктам. Необходимость перехода от реактивного контроля к системному подходу не является теоретической. Это предварительная подготовка.cisЧто послужило мотивацией для внедрения OWASP SPVS? standard в качестве приоритетного проекта.

Что такое SPVS и почему важна его структура?

История происхождения проста. На LASCON 2023 Фаршад Абаси и Кэмерон Уолтерс постоянно задавали друг другу один и тот же вопрос: где ASVS для pipelineOWASP ASVS обеспечила всестороннюю и проверяемую безопасность приложений. standardАналогов для не существовало. CI/CD.

Там был список 10 лучших пунктов OWASP. CI/CD Risks, ориентированный на повышение осведомленности, но не поддающийся тестированию; SLSA, сфокусированный только на происхождении сборки; S2C2F, сфокусированный только на потреблении зависимостей; и OpenSSF Система показателей, которая охватывала конкретные проверки репозитория. Каждая из них охватывала отдельный аспект. Ни одна не охватывала все целиком.

Структура или проект	Основная область применения
OWASP Top 10 CI/CD Риски	Ориентированный на повышение осведомленности CI/CD руководство по оценке рисков, а не проверяемая проверка. standard.
SLSA	Обеспечьте целостность информации о происхождении и хранимых материалах.
S2C2F	Безопасное потребление зависимостей.
OpenSSF Scorecard	Специальные проверки безопасности на уровне репозитория.

Разрыв: каждая из этих структур охватывала важный аспект. software supply chain securityно ни один из них не предоставлял сквозного, проверяемого решения. standard для всего CI/CD pipeline.

Этот разговор растянулся на два года работы, и в октябре 2025 года рабочая группа SPVS выпустила версию 1.0: 127 требований на протяжении всего жизненного цикла — планирование, разработка, интеграция, выпуск, эксплуатация — разделенных на три уровня зрелости: L1 — базовый, L2 — стандартный. Standardи L3 Advanced. Все требования соответствуют стандартам NIST SP 800-53 и OWASP. CI/CD Топ-10 и CWE.

Именно здесь большинство организаций сталкиваются с трудностями. Они сканируют зависимости, но игнорируют управление релизами. Они подписывают артефакты, но не анализируют угрозы для своих систем. pipeline Архитектура. Они контролируют производство, но не строительную площадку.

Это тезис, который оправдывает затраченные усилия. Сильные стороны на одном этапе не компенсируют слабые стороны на другом. Злоумышленникам достаточно разорвать всего одно звено. Жизненный цикл. standard Это заставляет вас проверить их все, а последовательность L1-L2-L3 позволяет сделать это, не пытаясь усложнить задачу. SPVS не заменяет SLSA, S2C2F, Scorecard или Sigstore; он предоставляет вам основу, которая показывает, где каждый из них может быть использован.

Адаптация Standard вашей организации

Естественным первым шагом является прямой аудит вашей организации и программной инфраструктуры на соответствие каждому требованию. Таблица Google Sheets, заполненная данными из официального источника. Требования SPVS CSV Это хорошо подходит в качестве отправной точки. Полезны три представления: матрица требований со статусом и ответственным за каждый элемент управления, тепловая карта для каждого репозитория и dashboard Отслеживание прогресса по этапам и уровням. Полученные результаты естественным образом вписываются в техническую дорожную карту — постоянно обновляемый документ, охватывающий каждый этап от планирования до эксплуатации.

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

Однако электронная таблица — это лишь моментальный снимок, а SPVS требует большего. В версии 1.1.7 предусмотрен ежеквартальный аудит администраторов VCS; в версиях 5.1.1–5.1.3 добавлены регулярные проверки пользователей, анализ журналов доступа и мониторинг привилегированного доступа; несколько элементов управления в версиях 2.1.x, 3.3.x и 4.2.x требуют постоянной проверки чистоты рабочих процессов в формате YAML. Выполнение этой процедуры вручную по всей организации занимает полдня на отслеживание кликов каждый квартал с реальным риском упущений. Это работа, которую либо автоматизируют, либо проверяют только после того, как произошло что-то плохое.

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

Зона SPVS	Тип требования
V1.1.7	Ежеквартальный аудит администраторов VCS.
V5.1.1–V5.1.3	Регулярный аудит пользователей, анализ журналов доступа и мониторинг привилегированного доступа.
V2.1.x, V3.3.x, V4.2.x	Текущая гигиена YAML-файлов в рамках рабочего процесса.

Решение заключается в создании или внедрении инструментов, работающих под учетной записью владельца организации и формирующих структурированный ежеквартальный пакет данных: список администраторов, защита веток, покрытие CODEOWNERS, очистка YAML-файлов рабочих процессов с закрепленными действиями, явные разрешения. pull_request_target Контроль доступа, двухфакторная аутентификация участников, установленные приложения GitHub и ключи развертывания. То, что раньше занимало полдня работы с электронными таблицами, теперь превращается в одну команду, генерирующую JSON и Markdown. Ежеквартальный обзор между CISАдминистраторы организаций становятся деcisЭто не совещание по сбору данных, а совещание, направленное на принятие решений, превращает выявленные проблемы в задачи, требующие решения, с соглашениями об уровне обслуживания, основанными на степени серьезности.

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

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

Технический контроль — это легко. С людьми сложнее.

Наиболее ярким примером почти всегда являются CODEOWNERS. Добавлю .github/workflows/ @your-org/security Кажется, что проверка каждого репозитория — это пустяк. Один файл, одна строка. Но это означает, что инженерам, которые годами самостоятельно объединяли изменения в рабочем процессе, теперь необходима проверка безопасности. Даже люди, заботящиеся о безопасности, возражают: я написал этот рабочий процесс, я его понимаю, зачем мне ждать?

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

Другие виды трения имеют аналогичную форму:

• Явные разрешения: Блокировка рабочих процессов приводит к сбоям CI до тех пор, пока участники не поймут ограничения прав доступа. Это не проблема прав доступа, а проблема ментальной модели.
• Неизменяемость тегов: нарушает работу инструментов выпуска, которые годами незаметно переименовывали файлы.
• Подписанный commits: Это создаёт сложности при адаптации новых пользователей до тех пор, пока ключи GPG или SSH не будут корректно настроены на всех рабочих станциях. SPVS делает это обязательным для каждого репозитория и каждого участника, а не только для основных.
• Замена классических персональных токенов доступа: Это затрагивает множество репозиториев и файлов рабочих процессов, практически каждую команду.

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

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

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

Что дальше

В ближайшем будущем ожидается SPVS v1.5 с элементами управления, связанными с ИИ: отслеживание происхождения кода, созданного с помощью ИИ. guardrails Для рабочих процессов CI, которые вызывают LLM, просматривайте журналы событий на предмет сгенерированных ИИ данных. pull requestsа также средства защиты от новых угроз, таких как сквоттинг, когда злоумышленники регистрируют имена пакетов, которые генерируются программистами с искусственным интеллектом, и от вредоносного ПО, созданного ИИ, о котором сообщает CrowdStrike. Организации, которые уже используют ИИ для маркировки вредоносного ПО. commitВ своих внутренних руководствах по развитию специалисты по связям с общественностью будут рассматривать эту адаптацию как поэтапную, а не как новую программу работы.

Ожидается, что версия 2.0 углубит мониторинг в режиме реального времени и требования к жизненному циклу учетных данных. Разумный организационный план: устранить оставшиеся пробелы уровня L3 к концу второго квартала 2026 года, включая SLSA provenance интегрированы в standard CI/CDручные настройки для развертывания в производственной среде и централизованный поставщик идентификационных данных, затем переход в режим обслуживания. Каждый новый репозиторий изначально соответствует требованиям, а ежеквартальный аудит выявляет отклонения на ранней стадии.

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

Основные выводы

Несколько моментов, которые актуальны и за пределами нашего конкретного контекста:

• Чтобы попробовать: Скачайте CSV-файл с требованиями SPVS и сопоставьте ваши текущие меры контроля с электронной таблицей. В течение дня вы узнаете, подходит ли он.
• Выберите один целевой уровень и выполните его, прежде чем переходить к следующему. Переход от L1 к L2 и к L3 — это особенность, а не ограничение.
• pipeline это цель. Контроль, ориентированный на приложения, необходим, но недостаточен; следует учитывать следующее: pipeline в качестве первоклассной атакующей поверхности.
• Проверьте всё pipelineни одной детали. Эффективность сканирования зависимостей не компенсирует слабое управление релизами или неконтролируемые среды сборки.
• Электронные таблицы представляют собой моментальные снимки; изменения происходят постоянно. Создайте автоматизированную систему, даже самый простой внутренний инструмент, для выявления отклонений между проверками.
• Организационная работа сложнее технической. Заложите время на обсуждения и пилотный проект перед внедрением, а также объясните, какую конкретную угрозу блокирует каждый из методов контроля.

Чтобы прочитать больше

• ОВАСП: Безопасный Pipeline Проверить Standard (SPVS) v1.0Страница проекта OWASP.
• Фаршад Абаси: Почему мы создали OWASP SPVSСтатьи OWASP SPVS.
• Фаршад Абаси: Pipeline Нападения участились. Вот как к ним подготовиться.Статьи OWASP SPVS.
• Фаршад Абаси: OWASP SPVS против других фреймворков для управления цепочками поставокСтатьи OWASP SPVS.
• ОВАСП: Топ-10 CI/CD БезопасностьСтраница проекта OWASP.
• SLSA: Уровни цепочки поставок для программных артефактов. slsa.dev.
• OpenSSF: Scorecard. securityscorecards.dev.