This repository has been archived on 2026-07-08. You can view files and clone it. You cannot open issues or pull requests or push a commit.
Files
infospace-bench/infospaces/patterns-of-it-securita-architecture/artifacts/entities/pattern-supply-chain-provenance.md

2.5 KiB

Pattern: Supply-Chain Provenance

Status: seed Readiness target: RL3 production Primary owners: Railiance platform, artifact-store, product repos

Problem

Production artifacts become hard to trust when source, dependencies, build runners, images, signatures, SBOMs, and deployment admission are not connected.

Context

Use this pattern for container images, packages, release artifacts, SBOMs, dependency updates, GitHub/GitLab workflows, artifact-store, and Kubernetes admission.

Forces

  • Teams need fast dependency updates and builds.
  • Production needs evidence that artifacts came from reviewed source.
  • Build systems need secrets, but secret exposure in CI is high impact.
  • Admission should verify artifacts without blocking all development.

Solution

Require production artifacts to carry review, dependency, build, signature, and provenance evidence. Admission and release workflows use that evidence to decide what can run or be promoted.

Implementation Sketch

  1. Protect main branches and release tags.
  2. Generate SBOMs per release.
  3. Sign container images and release artifacts.
  4. Emit SLSA-style build provenance from trusted runners.
  5. Keep build runners isolated and least privilege.
  6. Verify signatures and provenance before production admission.

Failure Modes

Failure Mitigation
SBOM generated but not stored with releases store SBOMs in artifact-store or release records
Signatures exist but admission ignores them enforce signed image admission
CI runner has broad production secrets quarantine runners and restrict secret access
Dependency bot floods unreviewed changes require tests and review gates
  • Software supply chain security.
  • Platform and Kubernetes hardening.
  • Security governance and production readiness.
  • Observability, detection, and audit.

Maturity

Seed. The pattern has strong external standards, but NetKingdom still needs concrete artifact-store and admission integration.

Verification

  • Releases include SBOM, signature, and provenance.
  • Admission rejects unsigned or untrusted production artifacts.
  • Build runner access to secrets is minimized.
  • Dependency updates are tested and reviewed.

Research Basis

Seeded by protected main branch, dependency update bot, SBOM-per-release, SLSA build provenance, signed container images, and quarantined build runner patterns.

References

  • Initial exploration: Software supply chain security.
  • Initial exploration: Supply-chain patterns.