Supply Chain Compliance

Verity signs and attests every container image it publishes. Helm charts are signed but do not yet carry build provenance attestations. This page details the security controls currently in place and the compliance frameworks they support.

SLSA L3
Build Provenance
Cosign
Keyless Signing
CycloneDX
SBOM Attested
Rekor
Transparency Log

SLSA Level 3 — Build Integrity

Supply-chain Levels for Software Artifacts (SLSA) v1.0

Build L1
Provenance Exists

Every patched container image has an attached SLSA provenance attestation generated at build time. Helm charts are signed but do not yet carry build provenance attestations.

Build L2
Hosted Build Platform

All builds execute on GitHub Actions using ephemeral, GitHub-hosted runners with no self-hosted infrastructure.

Build L3
Hardened Builds

Provenance is generated by the platform via actions/attest-build-provenance, outside the control of the build definition.

Sigstore — Artifact Signing

Sigstore · Cosign · Rekor

Keyless Signing

All patched container images and Helm chart OCI packages are signed using cosign with keyless OIDC. The GitHub Actions workflow identity token is used as the signing identity via Fulcio — no long-lived keys to manage or rotate.

Transparency Log

Every signature is recorded in the Rekor transparency log, providing a tamper-evident, publicly auditable record of all signing events. Signatures are tied to the specific GitHub Actions workflow run that produced the artifact.

Signing Identity

Signatures can be verified against the GitHub Actions OIDC issuer and the Verity repository identity:

Issuer: https://token.actions.githubusercontent.com
Identity: https://github.com/descope/verity/

Software Bill of Materials

CycloneDX Specification · NTIA SBOM

Every patched container image has a CycloneDX SBOM generated by Trivy and attached as an in-toto attestation via actions/attest-sbom. SBOMs enumerate all OS packages, libraries, and their versions, enabling downstream consumers to assess transitive risk independently.

SBOM attestations are stored both in the GitHub attestation store and pushed directly to the OCI registry alongside the image, so they travel with the artifact.

Dependency Management

OpenSSF Best Practices

Pinned Dependencies

Go modules are pinned with cryptographic hashes in go.sum. GitHub Actions are pinned by full commit SHA, not floating tags. Helm chart dependencies use explicit versions.

Automated Updates

Renovate continuously monitors for dependency updates. Security patches are auto-merged for Go minor/patch updates and GitHub Actions patch updates, keeping the supply chain current.

Continuous Vulnerability Scanning

Trivy · Project Copacetic (Copa)

Daily Scans

A scheduled workflow runs every day at 02:00 UTC, re-scanning all images for newly disclosed vulnerabilities.

Automatic Patching

Copa patches fixable OS-level vulnerabilities in-place without rebuilding images, then signs and attests the result.

PR-driven Updates

When new vulnerabilities are found, a pull request is created automatically with updated patched images for review.

FedRAMP & NIST 800-53 Rev 5

FedRAMP · NIST SP 800-53 Rev 5

FedRAMP authorization requires adherence to NIST 800-53 controls. Verity's supply chain practices address several control families that auditors evaluate when container images and Helm charts flow into FedRAMP-authorized environments.

SR-3 / SR-4
Supply Chain Provenance

SLSA L3 build provenance attestations provide a verifiable chain from source to artifact. Every image records the GitHub Actions workflow, commit SHA, and runner environment that produced it.

SR-11
Component Authenticity

Cosign keyless signatures tied to the Verity repository OIDC identity let consumers cryptographically verify that every artifact was produced by the authorized build pipeline.

SI-7
Software & Information Integrity

Artifact signatures and Rekor transparency log entries ensure integrity from build through deployment. Any tampering breaks signature verification.

RA-5
Vulnerability Monitoring & Scanning

Daily automated Trivy scans with auto-generated remediation PRs. Vulnerability reports are retained as workflow artifacts for audit evidence.

CM-14
Signed Components

All container images and Helm chart OCI packages are cryptographically signed before entering the registry. Unsigned artifacts are never published.

SA-11
Developer Testing & Evaluation

CI runs unit tests, linting (actionlint, shellcheck), and image scanning on every pull request before any artifact is built or published.

SOC 2 Type II

AICPA Trust Services Criteria

SOC 2 audits evaluate controls around security, availability, and processing integrity. Verity's automated, auditable pipeline supports multiple trust service criteria.

CC8.1
Change Management

All changes flow through pull requests with CI gates. Scheduled scans create PRs rather than modifying main directly. Every published artifact has provenance linking it to a specific commit and workflow run.

CC7.1
Monitoring & Detection

Daily vulnerability scans detect new CVEs across all published images. Trivy reports are retained for 30 days as workflow artifacts, providing continuous monitoring evidence.

CC6.1
Logical Access Controls

Workflows use scoped GITHUB_TOKEN permissions with least-privilege (e.g. packages: write only where needed). No long-lived credentials or static API keys.

PI1.4
Processing Integrity

Cryptographic signatures and attestations verify that artifacts have not been altered between build and deployment. Consumers can independently validate integrity.

ISO 27001:2022

ISO/IEC 27001:2022 Information Security Management

A.5.21
ICT Supply Chain Security

Upstream images are continuously scanned and patched. All dependencies are pinned with cryptographic hashes and automatically updated by Renovate. SBOM attestations provide full component visibility.

A.8.25
Secure Development Lifecycle

Automated CI with linting, testing, and vulnerability scanning gates. No artifact can be published without passing the full pipeline on GitHub-hosted runners.

A.8.26
Application Security Requirements

Vulnerability scanning enforces OS-level security requirements on every container image. Copa patches fixable CVEs before artifacts reach the registry.

A.8.30
Outsourced Development

Third-party chart dependencies and upstream images are treated as untrusted inputs — scanned, patched, re-signed, and attested before publication under the Verity identity.

OWASP ASVS

Application Security Verification Standard v4.0

V14.2
Dependency

All components come from known, trusted sources. Dependencies are pinned by hash, not by mutable tag. Renovate monitors for outdated or vulnerable packages and creates PRs automatically.

V10.3
Deployed Application Integrity

Consumers can verify that every artifact was built by the Verity pipeline and has not been modified, using cosign signature verification and GitHub attestation checks.

V14.1
Build & Deploy

Build processes are scripted and reproducible on ephemeral CI runners. No manual steps, no local builds, no self-hosted infrastructure. Provenance attestations link every artifact to its build definition.

NIST CSF 2.0 & CISA Secure by Design

NIST Cybersecurity Framework 2.0 · CISA Secure by Design

GV.SC
Supply Chain Risk Management

NIST CSF 2.0 added supply chain risk management as a governance function. Verity addresses this through provenance attestation, dependency pinning, continuous scanning, and cryptographic signing of all published artifacts.

Secure by Design
Radical Transparency

CISA's Secure by Design pledge calls for transparency in vulnerability disclosure and software composition. Verity publishes vulnerability scan results, attaches SBOMs to every image, and makes all verification publicly accessible via Rekor.

Framework Reference

Quick-reference mapping of Verity controls to specific framework requirements.

Framework Control / Requirement How Verity Meets It
SLSA v1.0 Build L3 — Hardened provenance Platform-generated provenance via actions/attest-build-provenance on ephemeral runners
Source integrity Version-controlled manifests in Git; provenance links artifacts to commit SHAs
EO 14028 SBOM for delivered software CycloneDX SBOM attested to every container image
NIST SSDF PS.1 — Protect software integrity Cosign keyless signatures; Rekor transparency log
PW.4 — Verify third-party components Trivy scanning of all upstream images; Copa patching
RV.1 — Identify and confirm vulnerabilities Daily scheduled scans; auto-generated PRs
NIST 800-53r5
(FedRAMP)
SR-3 / SR-4 — Supply chain provenance SLSA L3 provenance attestations linking artifacts to source, build, and runner
SR-11 — Component authenticity Cosign OIDC-based signatures verify artifact origin
SI-7 — Software integrity Signature verification detects any post-build tampering
RA-5 — Vulnerability monitoring Daily Trivy scans; 30-day report retention for audit evidence
SOC 2 CC8.1 — Change management PR-gated changes; provenance ties artifacts to specific commits and runs
CC7.1 — Monitoring and detection Daily CVE scans; vulnerability report artifacts retained
CC6.1 — Logical access controls Scoped GITHUB_TOKEN; least-privilege workflow permissions; no static keys
ISO 27001:2022 A.5.21 — ICT supply chain security Pinned dependencies; SBOM attestation; continuous upstream scanning
A.8.25 — Secure development lifecycle Automated CI gates (lint, test, scan) before any artifact is published
A.8.30 — Outsourced development Third-party images scanned, patched, re-signed under Verity identity
OWASP ASVS v4 V14.2 — Dependency verification All deps pinned by hash; Renovate auto-updates; no mutable tags
V10.3 — Deployed application integrity Cosign + gh attestation verify for end-to-end integrity
NIST CSF 2.0 GV.SC — Supply chain risk management Provenance, signing, SBOM, pinning, and scanning as a unified supply chain posture
CISA Secure by Design Radical transparency Public vulnerability reports; SBOM on every image; Rekor for public audit
OpenSSF Scorecard Pinned-Dependencies Actions pinned by SHA; Go deps via go.sum; Renovate auto-updates
Signed-Releases All OCI artifacts signed with cosign keyless
Sigstore Artifact transparency All signatures in the Rekor transparency log; verifiable by anyone

Verify It Yourself

You don't have to trust us — verify signatures and attestations directly.

Verify cosign signature on an image
cosign verify \
  --certificate-identity-regexp "https://github.com/descope/verity/" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  quay.io/verity/grafana/grafana:11.6.0-patched
Verify GitHub build provenance attestation
gh attestation verify \
  oci://quay.io/verity/grafana/grafana:11.6.0-patched \
  --owner descope
Verify cosign signature on a Helm chart
cosign verify \
  --certificate-identity-regexp "https://github.com/descope/verity/" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  quay.io/verity/charts/prometheus:28.9.1-4

Build Pipeline Overview

  1. Discover — Helm chart dependencies and standalone images are enumerated from version-controlled manifests
  2. Scan — Trivy scans each image for OS-level vulnerabilities with fixable-only filtering
  3. Patch — Copa patches fixable CVEs in-place on parallel ephemeral GitHub Actions runners
  4. Push — Patched images are pushed to the GHCR OCI registry
  5. Sign — Cosign signs each artifact using keyless OIDC; signatures are logged in Rekor
  6. Attest — SLSA build provenance and CycloneDX SBOM are attached as in-toto attestations
  7. Publish — Wrapper Helm charts are packaged, pushed, and signed in the OCI registry