Supply-chain

Secure supply chain — scan, sign, SBOM, provenance

`sc image scan`, `sc image sign`, `sc sbom generate`, `sc provenance generate`, and `sc release` ship the artifact-security primitives every regulated buyer asks for, built into the deploy pipeline.

Image scanning
Grype, Trivy, or both against the image you’re about to deploy. Fail-on-severity stops a release if a critical CVE shows up. No separate Snyk subscription.
Cosign signing + verification
Sigstore Cosign signatures, keyless (Fulcio OIDC) by default. Verify with one command — reject unsigned pulls.
SBOMs as OCI artifacts
CycloneDX or SPDX bills of materials, attached to the image. Verify the attestation in CI; export for compliance audits.
SLSA Build L3 provenance
Cryptographic proof of how the artifact was built, who built it, and where. Attestable with gh attestation verify.
All-in-one — `sc release`
One command runs build → scan → sign → SBOM → provenance → deploy. Every release ships with receipts.

Why this is in SC at all

The first generation of artifact-security tooling assumed you’d buy each piece separately: Snyk for scanning, Sigstore for signing, Anchore for SBOMs, in-toto for provenance. Each has its own auth, its own dashboard, its own pricing page.

SC bundles them because a regulated buyer asks for all four together or none of them. If you can hand a SOC 2 / SLSA / NIST SSDF auditor gh attestation verify and sc sbom verify and they pass — you’re done. No assembly required.

This matches the 2026 reality:

  • EU CRA (Cyber Resilience Act) requires SBOMs for digital products
  • US Executive Order 14028 + NIST SSDF requires provenance attestations
  • SLSA L3 is becoming the table-stakes ask for enterprise software vendors

The customers asking us about SC in 2026 are asking for receipts, not promises.

What the commands actually do

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
# Scan an image for CVEs (grype + trivy, or pick one)
sc image scan --image ghcr.io/me/api:v1.2.0 --tool grype --fail-on high

# Sign with cosign (keyless OIDC by default — omit --key for keyless mode)
sc image sign --image ghcr.io/me/api:v1.2.0

# Generate + attach a CycloneDX SBOM
sc sbom generate --image ghcr.io/me/api:v1.2.0 \
                 --format cyclonedx-json --output api.sbom.json
sc sbom attach   --image ghcr.io/me/api:v1.2.0 --sbom api.sbom.json

# Verify everything someone hands you
sc image verify  --image ghcr.io/me/api:v1.2.0
sc sbom verify   --image ghcr.io/me/api:v1.2.0 --output api.sbom.verified.json

Or skip the orchestration entirely:

1
2
3
# Run the whole chain as part of release
sc release create -s api -e prod
# build → scan → sign → SBOM → provenance → deploy → push attestations

Every step is also a separate command, so any CI pipeline can mix and match.

Forge eats this dogfood

Forge ships every release with:

  • Cosign signatures on every container image
  • CycloneDX SBOMs attached as OCI artifacts
  • SLSA Build L3 provenance, attestable with gh attestation verify

That’s not because we wrote a custom pipeline. It’s because sc release already did the work. Same for forge-aigateway, forge-conductor, forge-sessions, forge-runtime. Receipts on file for the whole platform.

Compared to the standalone tools

CapabilitySCStandalone
Image CVE scansc image scan (grype/trivy under the hood)Snyk Container, Aqua, Anchore
Image signingsc image sign (cosign)Sigstore Cosign
SBOM generationsc sbom generate (syft under the hood)Anchore Syft, FOSSA
Provenancesc provenance generate (SLSA Build L3)in-toto, slsa-github-generator
Unified release pipelinesc release create — all of the aboveGlue it yourself in 200 lines of GHA YAML

The bundled approach is the value. The underlying tools are open-source and we don’t try to hide that — we just wire them into a single command surface so customers don’t have to.

Ship your infrastructure on autopilot.

Try the SC parent stack in your own repo, or see what we built on top of it — Forge, our flagship AI workflow engine for teams.