Материал

Provenance и attestations без overkill: когда это реально нужно, а когда — преждевременная сложность

Опубликовано: 08 мая 2026 Время чтения: 16 мин

Честный разбор для команд, которые не хотят внедрять ещё один фреймворк ради фреймворка**

Почему тема снова актуальна

Число атак на software supply chain удвоилось в 2024 году — при этом отрасль остаётся в значительной степени незащищённой от этого вектора [1]. По данным Verizon DBIR 2025, доля брешей с участием третьей стороны выросла с 15% до 30% за один год [2].

Атака на xz-utils в 2024-м показала, как злоумышленник потратил два года на социальную инженерию, чтобы получить роль мейнтейнера и внедрить бэкдор с CVSS 10.0 в критическую библиотеку Linux — и обнаружили его случайно, через аномалию производительности [1]. В 2025-м компрометация GitHub Actions позволила атакующим извлекать секреты и токены CI/CD через доверенные автоматические пайплайны [2].

Всё это сместило вектор атаки: угроза теперь не в самом коде, а в инфраструктуре, которая его собирает и доставляет. Именно здесь build provenance и attestations приобрели практический смысл.

Но прежде чем внедрять — разберёмся с терминологией. Она в этой теме особенно запутана.

Что такое provenance, attestation и зачем разделять понятия

Build provenance

Build provenance — это верифицируемые метаданные, которые описывают, где, когда и как был создан артефакт [3]. Они включают: точный commit SHA из репозитория, версии toolchain и build platform, прямые и транзитивные зависимости, параметры конфигурации, временны́е метки и идентификатор того, кто запустил сборку [4].

Проще говоря: провенанс — это криптографически верифицируемая цепочка происхождения вашего артефакта. Аналог сертификата подлинности, только для бинарника или Docker-образа.

Attestation

Attestation — это подписанная упаковка для provenance и других метаданных. Технически она строится на основе in-toto Attestation Framework: фиксированный лёгкий «Statement», который связывает метаданные с артефактом [5]. Структура включает: envelope (подписанная обёртка на основе DSSE), subject (артефакт, идентифицированный криптографическим дайджестом) и predicate (типизированная нагрузка с самими данными) [6].

Predicate-типы бывают разные: SLSA Provenance, SBOM, результаты сканирования уязвимостей и так далее [6].

SLSA, in-toto и Sigstore

Эти три понятия часто смешивают. Вот как они соотносятся:

in-toto — CNCF-graduated фреймворк и базовый формат для всех supply chain attestations. Он определяет, как описывать шаги pipeline и верифицировать их выполнение. SLSA и другие фреймворки строятся поверх него [7].
SLSA (Supply-chain Levels for Software Artifacts, произносится «salsa») — набор последовательно усиливающихся требований к безопасности supply chain, предложенный Google в 2021 году и управляемый OpenSSF [8]. Определяет уровни от 1 до 3, каждый из которых добавляет гарантии.
Sigstore — инфраструктура для подписания и верификации артефактов. Включает Cosign (CLI для подписания), Fulcio (CA для краткосрочных сертификатов) и Rekor (прозрачный лог). Убирает необходимость самостоятельно управлять ключами подписания [9].

Если SLSA — это стандарт «что нужно доказать», то Sigstore — это «как это сделать без головной боли с ключами».

Уровни SLSA: что реально защищает каждый

Понять, когда именно нужен каждый уровень, проще через призму угроз, которые он нейтрализует [8, 10]:

SLSA Level 1 требует наличия документированного provenance. Защищает от случайных ошибок, помогает audit trail. Даёт видимость — «что, когда и откуда». Для большинства команд это уже полезно само по себе, без всякого compliance.

SLSA Level 2 требует, чтобы provenance был подписан и сгенерирован самой build platform, а не разработчиком вручную. Защищает от фальсификации provenance после сборки. На GitHub это достигается буквально четырьмя строками в workflow с GitHub Artifact Attestations [11].

SLSA Level 3 требует hardened, tamper-resistant build platform с изоляцией сборок. Защищает от компрометации самого build процесса. Здесь каждая сборка выполняется как независимый процесс на мультитенантной платформе, и builder.id идентифицирует всю цепочку доверия [12]. Это уровень, который потребовал бы SolarWinds заблокировать атаку Sunburst [3].

Важная ремарка: SLSA полезен только если кто-то проверяет attestations. Организация должна иметь автоматическую верификацию на этапе сборки или деплоя — иначе это просто метаданные, которые никто не читает [15].

Когда provenance и attestations реально нужны

Вот критерии, при наличии хотя бы одного из которых внедрение оправдано и прагматично:

1. Вы публикуете open-source или распространяете артефакты внешним потребителям. Тогда attestations — это гигиена, а не overhead. Потребитель должен иметь возможность верифицировать, что он получил именно то, что вы собрали. Sigstore/Cosign здесь — стандарт де-факто для open-source экосистемы.

2. У вас enterprise-клиенты или государственный сектор в числе покупателей. NIST SSDF (SP 800-218) де-факто обязателен для всех поставщиков ПО в US federal government — через OMB Memorandum M-22-18 и Executive Order 14028 [16]. SSDF требует трактовать provenance-данные как доказательства и хранить их с теми же контролями доступа, что и критичные артефакты [17].

3. Вы попадаете под EU Cyber Resilience Act. CRA вступил в силу 10 декабря 2024 года. Полные обязательства применяются с 11 декабря 2027-го [18]. Регламент охватывает все «products with digital elements», продаваемые на рынке ЕС, и требует прозрачности supply chain на протяжении всего жизненного цикла продукта. Для компаний, продающих B2B-软件 в ЕС, provenance и SBOM — это уже не «хорошо бы иметь».

4. Ваш CI/CD pipeline — это широкая поверхность атаки. Если к вашим Actions workflow, build scripts или dependency resolution имеют доступ несколько людей, если вы используете сторонние Actions без pin по digest, если секреты хранятся в переменных окружения без rotation — компрометация пайплайна становится реальным сценарием. В этом случае hardened build с SLSA Level 3 и верификацией перед деплоем существенно сокращает blast radius.

5. Вы входите в supply chain downstream-потребителей. Если ваши библиотеки, SDK или контейнеры используются другими командами внутри организации или внешними разработчиками — атакующий может использовать вас как точку входа к ним. Это именно тот сценарий 3CX, где атака прошла через trusted vendor [2].

6. Compliance требует demonstrable evidence. Сертификации типа SOC 2, ISO 27001 или FedRAMP всё чаще включают вопросы о secure development practices, integrity of build artifacts и evidence of provenance. Attestations — это готовый ответ на audit questionnaire.

Когда provenance — premature complexity для небольшой команды

Это важный контрпункт, и его нужно проговорить честно.

Если ваш продукт — внутренний сервис без внешних потребителей. Вы контролируете весь pipeline сами, у вас нет downstream-зависимых команд, нет compliance-требований — тогда полный SLSA Level 3 с кастомными in-toto layouts добавляет мейнтейнс без пропорциональной пользы.

Если у вас ещё нет воспроизводимых сборок. Провенанс фиксирует «как было собрано». Если сборки не воспроизводимы — провенанс фиксирует хаос. Сначала нужно добиться детерминированных сборок, lock-файлов, фиксации версий toolchain.

Если никто не верифицирует attestations на деплое. Генерировать provenance без настроенной автоматической верификации — это создавать метаданные, которые дают ложное ощущение безопасности. Исследователи SLSA прямо указывают: верификация в build или deploy stage обязательна [15]. Без неё attestations — театр.

Если у команды нет ресурса на мейнтейнс. Ключи подписания нужно ротировать, хранилище provenance — бэкапить, верификационные процессы — поддерживать. Это не разовая настройка [13]. Kusari прямо фиксирует: SLSA не разовая имплементация, она требует ongoing внимания [13].

Если основные проблемы безопасности лежат в другом месте. Провенанс защищает build pipeline. Но если у вас хардкоженые секреты в репозитории, нет ротации credentials, открытые S3-бакеты или SQL-инъекции в API — начать с провенанса означает игнорировать более критичные риски.

Практический decision framework: что выбрать и когда

Вместо таблицы — последовательность вопросов.

Вопрос 1: Есть ли внешние потребители ваших артефактов? Да → переходите к вопросу 2. Нет → ограничьтесь SBOM + базовым подписанием образов.

Вопрос 2: Есть ли регуляторные требования (SSDF, CRA, SOC 2, FedRAMP)? Да → SLSA Level 2 минимум + SBOM как attestation + проверьте конкретные требования регулятора. Нет → переходите к вопросу 3.

Вопрос 3: Вы входите в supply chain других команд или продуктов? Да → SLSA Level 2–3 оправдан, начните с GitHub Artifact Attestations если на GitHub. Нет → переходите к вопросу 4.

Вопрос 4: Есть ли у вас воспроизводимые сборки и зрелый CI/CD? Нет → сначала lock-файлы, фиксация версий, детерминированные сборки. Да → SLSA Level 1–2 как следующий шаг.

Вопрос 5: Есть ли ресурс на верификацию и мейнтейнс? Нет → ограничьтесь Level 1 + Cosign-подписанием. Да → Level 2–3 в зависимости от ответов выше.

Минимальный стартовый стек: что реально внедрить без боли

Для небольшой команды на GitHub рекомендуется следующий минимальный набор [14]:

Шаг 1 — Подпись образов через Cosign (keyless). Четыре строки конфигурации в workflow. Cosign использует OIDC-идентичность GitHub Actions, ключи не нужно хранить самостоятельно. Подписи хранятся в OCI-реестре рядом с образом [9].

- uses: actions/attest-build-provenance@v1
  with:
    subject-name: ${{ env.IMAGE_NAME }}
    subject-digest: ${{ steps.build.outputs.digest }}
    push-to-registry: true

Шаг 2 — GitHub Artifact Attestations (SLSA Level 3 «из коробки»). С июня 2024 года GitHub генерирует и подписывает provenance-аттестацию на уровне платформы — пользователь не может подделать её содержимое [11]. Это SLSA Level 3 практически без дополнительных усилий. Важная оговорка: для приватных репозиториев нужен GitHub Enterprise Cloud [19].

Шаг 3 — Генерация SBOM. Интегрируется в тот же workflow, добавляет SBOM как attestation. Docker BuildKit поддерживает --attest type=provenance по умолчанию [20].

Шаг 4 — Верификация на деплое. Без этого шага предыдущие три теряют смысл. Настройте policy, которая проверяет attestation перед деплоем. В Kubernetes это реализуется через admission webhook + Cosign verify.

Для команд, которые не на GitHub или используют Jenkins, Azure Pipelines и другие CI-системы, отмечу: экосистема Sigstore здесь менее зрелая. CircleCI поддерживает OIDC-токены для Cosign [21], но для собственной CI-инфраструктуры потребуется больше работы по настройке Fulcio и Rekor.

Проблемы, о которых не говорят в туториалах

Реальный опыт внедрения Sigstore и SLSA фиксирует несколько трений [22]:

Фрагментация экосистемы. Каждая экосистема (npm, PyPI, GitHub, Docker) верифицирует по-своему. cosign verify работает для контейнеров, но для Python-пакетов с Sigstore нужен другой формат bundle и флаг --new-bundle-format. npm прячет верификацию за npm audit signatures. Унифицированного CLI нет.

Privacy в keyless-подписании. При keyless-подписании email из OIDC-провайдера попадает в прозрачный лог Rekor и становится публично виден навсегда. Для корпоративной инфраструктуры, где нежелательно раскрывать идентичности сотрудников, это требует собственного экземпляра Fulcio/Rekor [22].

Хранение non-container attestations. Для контейнерных образов attestations хранятся прямо в OCI-реестре. Для JAR-файлов, бинарников или Python-пакетов единого решения нет — нужны дополнительные инструменты типа GUAC или собственные storage backend [22].

Исследование на 1523 GitHub issues в 233 репозиториях показало: два главных барьера при внедрении SLSA — сложность имплементации и неясная коммуникация требований [23]. Авторы отмечают необходимость упрощения процессов генерации provenance и улучшения документации.

Operational overhead на высоких уровнях. SLSA Level 3 требует изолированной, hardened build platform. Достижение и поддержание этого уровня требует значительных изменений в CI/CD, построения trust chain от платформы до артефакта и ongoing мейнтейнса [24].

Supply chain в мире AI-кодинга: почему провенанс важен именно сейчас

В контексте AI-ускоренной разработки риск компрометации supply chain растёт нелинейно. AI-инструменты регулярно предлагают зависимости, которые могут оказаться несуществующими (package hallucination) или типосквоттинговыми. Новая зависимость приезжает в PR незаметно, её транзитивные зависимости никто не читает, lock-файлы обновляются автоматически.

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

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

Регуляторный контекст: что уже работает, что ещё впереди

NIST SSDF (SP 800-218 v1.1, обновление v1.2 в декабре 2025) [25] — де-факто обязателен для поставщиков ПО в US federal government. Требует трактовать provenance как доказательства с соответствующими контролями хранения и доступа [17].

EU Cyber Resilience Act (Regulation EU 2024/2847) — вступил в силу 10 декабря 2024 года [18]. Обязательная отчётность об уязвимостях — с 11 сентября 2026-го, полные требования — с 11 декабря 2027-го [26]. Охватывает всех производителей «products with digital elements» для рынка ЕС. Свободное open-source ПО без монетизации освобождено; монетизируемое — нет [27].

OpenSSF SLSA End-to-End — к сентябрю 2025-го планируются референсные реализации полного цикла SLSA (Source Track → Build → Verification → Publication → Use) [28].

Российский регуляторный контекст в части software supply chain security пока не имеет прямых аналогов SSDF или CRA с требованиями к провенансу. Тем не менее стандарты ФСТЭК в части безопасности разработки и требования к SSDLC для аттестованных систем движутся в схожем направлении.

Чек-лист: что проверить до внедрения

Перед принятием решения о внедрении провенанса и attestations проверьте следующее.

Относительно зрелости вашего pipeline:

Сборки воспроизводимы и детерминированы?
Все зависимости зафиксированы через lock-файлы?
Версии toolchain пинятся в CI-конфигурации?
Есть ли процедура ротации секретов?

Относительно обоснования внедрения:

Кто является потребителем ваших артефактов — внутренние или внешние?
Есть ли регуляторные или contractual требования?
Входите ли вы в supply chain downstream-потребителей?
Есть ли у вас ресурс на настройку верификации и ongoing мейнтейнс?

Относительно минимального набора для старта:

Образы подписаны через Cosign?
SBOM генерируется автоматически при каждой сборке?
Верификация attestation настроена на деплое (а не только генерация)?
Политика деплоя запрещает образы без верифицированного provenance?

Заключение: не нужно всё сразу

Build provenance и attestations — это не checkbox compliance и не серебряная пуля. Это конкретный инструмент против конкретного класса угроз: компрометации build pipeline и подмены артефактов в supply chain.

Для небольшой команды без внешних потребителей и регуляторных требований SLSA Level 3 с полной in-toto layout — это действительно premature complexity. Но подписать образ через Cosign и сгенерировать SBOM — это уже не сложно и занимает несколько часов, а не недель.

Граница проходит не по размеру команды, а по контексту: кто потребляет ваши артефакты, какие у вас регуляторные обязательства, и насколько ваш build pipeline — реальная поверхность атаки.

Начинайте с минимума. Добавляйте сложность только тогда, когда она решает реальную проблему — не воображаемую.

Источники

[1] Sonatype — "State of the Software Supply Chain Report 2024" — https://www.sonatype.com/state-of-the-software-supply-chain/2024/10-year-look

[2] DeepStrike — "Supply Chain Attack Statistics 2025: Costs, Cases, Defenses" — https://deepstrike.io/blog/supply-chain-attack-statistics-2025

[3] Kusari — "What is Build Provenance? Definition & Explanation for SLSA Compliance" — https://www.kusari.dev/learning-center/build-provenance

[4] JFrog — "What Is Software Provenance? Secure Supply Chain Practices" — https://jfrog.com/learn/grc/software-provenance/

[5] SLSA — "in-toto and SLSA" — https://slsa.dev/blog/2023/05/in-toto-and-slsa

[6] Sbomify — "What Is in-toto? Securing the Software Supply Chain End to End" — https://sbomify.com/2024/08/14/what-is-in-toto/

[7] in-toto Community — GitHub — https://github.com/in-toto/community

[8] GitHub Blog — "Enhance build security and reach SLSA Level 3 with GitHub Artifact Attestations" — https://github.blog/enterprise-software/devsecops/enhance-build-security-and-reach-slsa-level-3-with-github-artifact-attestations/

[9] Sigstore — "Quickstart with Cosign" — https://docs.sigstore.dev/quickstart/quickstart-cosign/

[10] Harness — "SLSA: Supply Chain Levels for Software Artifacts" — https://www.harness.io/blog/slsa-supply-chain-levels-for-software-artifacts

[11] GitHub Docs — "Using artifact attestations to establish provenance for builds" — https://docs.github.com/en/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations

[12] SLSA — "Build: Provenance" — https://slsa.dev/spec/draft/build-provenance

[13] Kusari — "SLSA: Supply-chain Levels for Software Artifacts" — https://www.kusari.dev/learning-center/slsa-supply-chain-levels-for-software-artifacts

[14] Rajesh Kumar — "Top 10 Secure Software Supply Chain Attestation Tools" — https://www.rajeshkumar.xyz/blog/secure-software-supply-chain-attestation-tools-slsa-provenance/

[15] Wiz — "What is The SLSA Framework?" — https://www.wiz.io/academy/application-security/slsa-framework

[16] Anchore — "An Introduction to NIST's Secure Software Development Framework" — https://anchore.com/blog/about-new-nist-ssdf/

[17] NIST — "Secure Software Development Framework (SSDF) Version 1.1, SP 800-218" — https://csrc.nist.gov/projects/ssdf

[18] European Commission — "Cyber Resilience Act" — https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act

[19] Medium / Rémi Rey — "SLSA, it's all about provenance attestation" — https://medium.com/@rrey94/slsa-its-all-about-provenance-attestation-09a83b7b9de7

[20] Docker Docs — "Provenance attestations" — https://docs.docker.com/build/metadata/attestations/slsa-provenance/

[21] CircleCI — "Sign OCI containers & other artifacts using Sigstore Cosign & CircleCI OIDC tokens" — https://circleci.com/blog/sign-oci-containers-and-other-artifacts-using-sigstore-cosign/

[22] code.mendhak.com — "Modern artifact signing with Cosign, what works and what hurts" — https://code.mendhak.com/understanding-sigstore-cosign-as-a-beginner/

[23] arXiv — "Analyzing Challenges in Deployment of the SLSA Framework for Software Supply Chain Security" — https://arxiv.org/abs/2409.05014

[24] ResearchGate — "Software Supply Chain Security: Implementing SLSA Compliance in CI/CD Pipelines" — https://www.researchgate.net/publication/393457635

[25] NIST — "SP 800-218 Rev. 1 (Draft), SSDF Version 1.2" — https://csrc.nist.gov/pubs/sp/800/218/r1/ipd

[26] OpenSSF — "EU Cyber Resilience Act" — https://openssf.org/public-policy/eu-cyber-resilience-act/

[27] ArmorCode — "EU Cyber Resilience Act (CRA) Requirements Guide" — https://www.armorcode.com/learning-center/eu-cyber-resilience-act-cra-requirements-guide

[28] SLSA — "SLSA End-to-End: Request for examples" — https://slsa.dev/blog/2025/07/slsa-e2e