SecurityVault
Request a demo
For platform engineering

Build security into
the path to production.

Connect pipeline policy, container images and Kubernetes posture. Give teams clear release guardrails and the evidence behind each decision.

Request a demo Deployment gates
The platform release reviewcluster
Artifact, workload and policy
Build artifact
Workload context
Release evaluation
Investigation context
01 / Trace artifact

Know which build is under review.

  • Artifact digest
  • Workload reference

Use artifact identity to connect the security evidence to the workload.

Where guardrails leak

Why do platform guardrails erode?

01

Gates that fail open

When the scanner is down the build goes green, so the guardrail is only as reliable as the least reliable tool behind it.

02

Policy drift between pipelines

Rules live in a YAML file per pipeline and drift apart, and an override leaves no record of who decided what.

03

Git is not what runs

Manifests describe what was approved, not what is running. A tag moves, an image is edited in place, and nobody can say which digest is live.

The paved road, enforced

How does SecurityVault change a platform team's week?

Pipelines
One Open Policy Agent policy evaluated the same way in every pipeline, through the CLI or the gate API, with an evaluator error treated as a deny and every override recorded. See deployment gates.
Infrastructure code
Terraform, Kubernetes manifests, Helm charts and CI workflows checked before apply, with module and variable resolution, and paired with live cloud posture on the same graph. See IaC security.
Images
Scans pinned to a digest, never a mutable tag; cosign signatures verified by digest; SBOMs exported as CycloneDX or SPDX. See container security.
Clusters
CIS Kubernetes benchmarks per cluster, a workload and image inventory, and an admission webhook that refuses privileged or unsigned workloads and denies on error. See Kubernetes security.
Cloud
Agentless posture for AWS, Azure and GCP with drift detection and posture SLAs, on the same graph as the code. See cloud posture.
Your view in SecurityVault

What does a platform team see in SecurityVault?

Platform teams work from the asset-owner lens, the Team Owner Home, scoped to the code and cloud they own. Its question: which commitments are overdue, what is blocked, and what changed since last review?

Team commitments

The ranked stories your team owns, beside your open findings and a remediation funnel.

Since last review

A briefing composed deterministically from live metrics, not a language model, with scan freshness for the assets you own.

Blocked

The crown-jewel assets you own that are currently at risk, so a blocked fix on a critical service is never buried.

Built for the platform layer

Why do platform teams build guardrails on SecurityVault?

One policy, three stages

The same policy can fire at the pull request, the build and admission, because all three read the same chain from commit to workload.

Digest to workload

Registry watchers and the cluster sensor bind each running workload to its digest, and the digest to the build and commit that produced it.

Isolate analysis from the delivery platform

Every scanner runs isolated and short-lived, with no platform credentials, and reports through one authenticated, signed path. Everything it emits is handled as untrusted input.

Decisions on the record

Gate decisions are signed, overrides are audited events, and exceptions carry an owner, an expiry and an approver.

Rollout without breakage

How do platform teams roll SecurityVault out?

01

Pick the policy

Request a demo with one pipeline, one cluster and the policy you want enforced on both.

02

Connect pipeline and cluster

Add the CLI to the pipeline, connect the cloud account and run a cluster scan.

03

First gate in audit mode

Start the admission policy in audit, review the decisions, then promote it with two approvers.

FAQ

Operating SecurityVault in your delivery environment

How does a pipeline tell a policy denial from an outage?
The esos ci scan CLI exits 0 on success, 1 on a policy failure and 2 on an API error, so a pipeline can block on a real denial and alert on an outage instead of guessing. See deployment gates.
Can we enforce admission policy without breaking deploys?
Yes. Export image policies to Kyverno and introduce enforcement in stages: audit first, then staging, then production. Each promotion requires approvals from two different people. See Kubernetes security.
Do scanners need credentials to our platform?
No. Scanners are treated as hostile. Each scan runs isolated and short-lived with credentials for its target only — never platform credentials or data access.
Can we run SecurityVault inside our own environment?
A self-hosted deployment of the full platform, with the same Helm charts and signed images, is available on request.
Is there runtime threat detection in the cluster?
The cluster sensor reports inventory and which image digest each workload runs today. eBPF runtime signals and detection and response are in development. Discuss rollout with our team.

SecurityVault for other roles: CISOs · Security engineers · AppSec · Developers · GRC and audit · SOC and IR. See every role.

Further reading: policy-as-code deployment gates with OPA, Kubernetes admission gates and cluster drift, image-to-workload binding and IaC scanning before apply.

See it on your platform

Connect one pipeline and one cluster.

Watch a gate deny on error, an unsigned image refused at admission and a digest traced to its commit.

Request a demo Read the architecture