When you need it
Customers ask for SBOMs and proof of where your software comes from. Your images start from base images nobody updates, dependency updates wait for months, and nothing stops an image that skipped the pipeline from running in production.
What sets the quote
- Up to 10 repositories on one CI platform, one container registry and up to 3 base images.
- Deploy-time verification on one runtime, such as Cloud Run, GKE, EKS, AKS or OpenShift.
- Provenance to SLSA Build Level 2, or Level 3 where your CI platform supports it (for example GitHub Actions with reusable workflows, or Google Cloud Build).
- Can be combined with the Standard tier of the secure CI/CD pipeline, which already includes image signing; the quote then covers only the extra work.
- Larger scopes are quoted after the call.
What changes
- Only images signed by your pipeline reach production; the runtime or the deploy step rejects the rest.
- You can give customers an SBOM and signed build provenance for every release.
- Base images and dependencies stay current through automated update pull requests.
- Your team knows which base images are allowed and how quickly they must be rebuilt after a fix.
What you get
- An SBOM for every image, in SPDX or CycloneDX format, stored with the image in your registry
- Signed build provenance to SLSA Build Level 2, or Level 3 where the CI platform supports it
- Image signing with Sigstore Cosign or Notation, using a key in your cloud key service or keyless signing
- Deploy-time verification: Binary Authorization, Kyverno, Gatekeeper with Ratify, or signature and digest checks in the pipeline
- Base-image policy for up to 3 approved base images, with owners and rebuild rules
- Automated dependency and base-image updates with Renovate or Dependabot
- Runbook for key rotation, emergency deploys and exceptions
What we cover on each platform
| Runtime | How images are verified before they run |
|---|---|
| Cloud Run and GKE | Binary Authorization policy that requires an attestation from your pipeline |
| EKS, AKS and OpenShift | Admission control with Kyverno, or with Gatekeeper and Ratify |
| Other runtimes | Signature and digest checks in the pipeline before each deploy |
Not included
- Fixing the vulnerabilities found in images and dependencies
- Building the CI/CD pipeline itself (see secure CI/CD pipeline)
- Signing packages or binaries other than container images
- Legal review of the open-source licences listed in the SBOMs
What we need from you
- Admin rights on the repositories in scope and on the container registry (Amazon ECR, Azure Container Registry, Artifact Registry or another OCI registry).
- The cluster-admin role on EKS, AKS or OpenShift, or the Binary Authorization policy and attestor admin roles on Google Cloud, for the runtime where verification is enforced.
- Rights to create signing keys or certificates in your cloud key service (AWS KMS or AWS Signer, Azure Key Vault or Cloud KMS).
- A tech lead for decisions on base images and exceptions, about 2 hours a week.
How it works
Free 30-minute call, then a written fixed quote based on your repositories, registry, base images and runtime.
Agree the base-image policy, the signing keys and the verification rule for each environment.
Add SBOMs, provenance and signing to the builds, one repository at a time.
Switch on verification in audit mode, fix what it flags, then enforce it.
Handover session and runbook.
At a glance
- Duration
- 2–3 weeks
- Price
- Fixed quote after a free 30-minute call
- Delivered by
- Our lead architect and a cloud engineer
Related services
DevSecOps gap check
In 1–2 weeks, a check of how your teams build and ship software, scored against OWASP SAMM and NIST SSDF, ending in a gap list and a 90-day plan.
Pipeline security check
A one-week review of one CI/CD platform, from organisation settings to runners and secrets, with findings mapped to the OWASP Top 10 CI/CD Security Risks and SLSA.
Keyless pipelines and secrets cleanup
Your pipelines move from long-lived cloud keys to short-lived federated tokens, with secret scanning and dependency gates that stop new leaks and risky dependencies before merge.