The question that exposes the gap
"What's running in production right now, and can you prove it came from an approved, scanned source?" is a reasonable question — from a SOC 2 auditor, a new security hire, or your own team after a vulnerability disclosure. In a lot of organizations, answering it means checking three or four systems by hand, and the answer still comes with caveats: scanning exists for some Applications but not others, images get built the same way but not always through the same pipeline, and nobody's fully sure whether last quarter's exception ever got revoked.
That gap isn't usually the result of anyone being careless. It's what happens when supply chain security gets bolted onto each Application individually instead of built into the path every Application goes through.
Why "we have scanning" isn't the same as "we have a supply chain"
Most teams past a certain size already run some scanning — a step in CI, a tool the security team asked for last year. What's usually missing is the chain connecting it end to end: does every image trace back to a specific commit and its scan results? Does anything unscanned have a path into GKE? Is there one system, or five, disagreeing about whether an artifact was approved? A scanner catches a vulnerability. A supply chain proves, after the fact, that the right checks ran on the right thing before it reached production.
What the provable version looks like
- Source to build. Images produced through the approved delivery path are linked to the Git commit and workflow that created them, providing a documented source of origin.
- Build to scan. Container, dependency, and infrastructure checks run as part of the approved delivery workflow.
- Scan to approval. Scan results and policy decisions determine whether an image is approved for promotion and deployment.
- Registry to runtime. Admission controls can prevent images that do not meet enforced requirements from reaching GKE.
- Runtime to evidence. Git history, pull requests, CI/CD records, Artifact Registry metadata, scan results, and relevant audit logs provide the evidence needed to trace an approved build into an Environment.
This is the same delivery path every Application already goes through — supply chain security isn't a separate program running alongside it, it's what the default path already does. The full control-by-control detail — specific tools, enforcement stages — lives on Security and Guardrails; the platform-level framing is on Security and DevSecOps. This page is about the specific moment that makes this worth fixing now.
The compliance conversation gets shorter
Vertro doesn't certify anyone as compliant — no platform can make that claim honestly. What it can do is generate the evidence a compliance program actually needs: scan results tied to specific builds, approval history in Git, and a consistent control model applied the same way across every Application, not reconstructed by hand when an auditor asks. That turns "let us reconstruct the delivery history" into "here is the record," making change-management and software-delivery evidence easier to produce during an audit.
Frequently asked questions
Does Vertro help with SOC 2 or similar compliance audits?
Vertro can provide technical controls and evidence-generating mechanisms — scan results, approval history, Git-based change records — that support a customer's compliance program. Vertro does not itself certify a customer as compliant with SOC 2, NIST, or any other framework.
What happens to images that fail a required scan?
Approved image scanning and admission controls can prevent images that fail required checks from reaching GKE, depending on which controls your platform and security teams have enabled and enforced.
Can we see which commit and scan results produced a given production image?
Traceability runs through Git history, pull requests, and Artifact Registry together — each build links back to the source commit and its scan results, rather than production artifacts existing without a documented origin.
Do we need to adopt every supply chain control at once?
No. Controls typically move through stages — available, then default, then enforced, then measured — so a team can validate that a stricter check won't break existing workloads before it becomes mandatory across every Application.
Does this replace our existing vulnerability scanning tools?
Not necessarily. Vertro connects approved scanning tools into the standard delivery path rather than requiring one specific vendor. Where multiple scanners are used, each should have a defined purpose to avoid unnecessary duplication and conflicting results.