Know what you ship and who can change it
Secure the path from commit to production with SBOMs, signed images, SLSA provenance, image scanning, proper secrets management and least-privilege IAM.
Overview
Enterprise customers and regulators now ask what is inside your software and how you know it was not tampered with. Many teams cannot answer: images are pulled from public registries, secrets sit in CI variables, and pipeline roles have far more access than they need.
We secure the delivery chain step by step. Builds produce an SBOM and provenance, images are signed with Sigstore cosign and checked at admission, scanners run where developers will see the results, secrets move to a proper store, and IAM roles are cut down to what each job actually uses. The aim is controls that stay switched on because they do not slow teams down.
Signs you need this
- You cannot produce a list of the open source packages in a given release
- Long-lived cloud keys are stored as CI secrets
- Any image can be deployed to production, including untagged or unscanned ones
- Scanner reports are produced but no one triages them
What you get
- Pipeline threat review
- A walk through source control, CI, registries and deployment, listing where code or credentials could be tampered with.
- SBOM and provenance
- Syft or Trivy SBOMs and SLSA provenance generated on every build and stored with the image.
- Image signing and admission
- Sigstore cosign signing in CI with keyless identity, and a Kyverno or policy-controller rule that rejects unsigned images.
- Scanning with triage
- Dependency, image and infrastructure scanning in pull requests, with severity thresholds and an agreed process for exceptions.
- Secrets management
- Secrets moved to Vault or the cloud secret manager, CI switched to OIDC federation, and long-lived keys removed.
- Least-privilege IAM
- Roles for pipelines, workloads and people trimmed using access logs, with permission boundaries where needed.
How the work runs
- 1
Review
1 to 2 weeks
Map the delivery chain, list credentials and their scope, and rank the gaps by how easily they could be abused.
- 2
Credentials first
2 to 3 weeks
Replace long-lived keys with OIDC federation, move secrets into a store and reduce pipeline permissions.
- 3
Build integrity
2 to 4 weeks
Add SBOMs, provenance, signing and scanning to pipelines, starting in report-only mode.
- 4
Enforcement
1 to 3 weeks
Turn on admission checks and merge gates once teams have fixed existing findings, then hand over the triage process.
Timings depend on the size of your estate. The assessment fixes them before any build starts.
What you can check afterwards
- Every production image has an SBOM and a verifiable signature
- The cluster rejects images that are unsigned or from unapproved registries
- CI pipelines authenticate to the cloud without stored long-lived keys
- Scanner findings have an owner and a documented triage rule
Tools we work with
- Sigstore cosign
- Syft
- Trivy
- Grype
- SLSA GitHub Generator
- Kyverno
- HashiCorp Vault
- AWS Secrets Manager
- GitHub Actions OIDC
- Checkov
- Dependabot
- IAM Access Analyzer
Questions buyers ask
- Will this slow down our releases?
- Checks start in report-only mode so nothing breaks on day one. We only enforce once existing findings are handled and the build time cost is understood.
- Does this make us compliant with a standard?
- It produces controls and evidence that map to common standards, but certification is a separate audit. We can align the work with your auditor's control list.
- What access do you need?
- Admin access to your CI system and container registry, IAM admin in the cloud accounts, and cluster admin for admission policies.
- What happens with the vulnerabilities you find?
- We fix the pipeline and platform issues ourselves. Application dependency findings go to the owning teams with a severity and suggested fix.
Talk to us about DevSecOps and software supply chain security.
Tell us what you run and where. We reply within one business day with questions or a quote.