Triggered by alert
Fires when a CVE is published in a feed you subscribe to, or on demand from a chat command.
Recurring operations work
Proactively map a new CVE to every affected workload, before anyone asks
When a CVE drops, Hyground returns the full impact map: which images, which clusters, which deployment owners, and the upgrade path per service. Read-only kubectl and GitHub. No external image scanner installed in your perimeter.
The artefact
A complete blast-radius report, on the morning the CVE drops
When a new CVE is published against a base image, library or runtime in your fleet, the question is always the same: where are we running it, who owns each instance, and how do we upgrade. Hyground encodes that triage as a deterministic workflow that runs on alert and returns the same answer every time.
Full inventory
Every workload across every cluster running a matching image tag or affected library version.
Owner-attributed
Each finding tagged with the responsible team via labels or your service catalogue.
What the agent reads
The data sources the agent walks
No vulnerability scanner. No SBOM agent. The blast radius is computed from kubectl, your Git repositories and the CVE feed itself.
Kubernetes
Live image inventory across every cluster and namespace, with their pinned tags and digests.
GitHub or GitLab
Dockerfiles and Helm values, used to follow image-build chains and identify transitive exposure.
CVE feed
NVD, GitHub Advisories or your internal vulnerability database, depending on what your security team already uses.
What you get back
The report your security review actually needs
Designed to land in your ticket of record, not a chat thread. One artefact, with the evidence pinned next to every claim.
01
Affected workloads inventory
Every deployment, statefulset or job running a vulnerable image tag, with cluster, namespace and image digest.
02
Owner attribution
Each finding tagged with the responsible team via Kubernetes labels or your service catalogue.
03
Upgrade path per service
The fixed version, the upstream advisory link and the change required in your Helm chart or manifest.
04
Suggested rollout sequence
Lowest-risk environments first, the production stagger, and any service that needs coordinated downtime.
Sovereign AI SRE, in your perimeter
No SaaS. No data leaves. Hyground runs in your perimeter as your Sovereign AI SRE. It speeds up incident resolution and your daily work, both. Trusted by industry giants.
Read deeper
Six pillars of secure, auditable operations
Hyground is built on six architectural pillars: fully self-hosted, zero external access, credential control, flexible integration, bring your own models, and standard tooling. The compliance whitepaper unpacks each one and shows why every Hyground action is read-only by default, typed, scoped and audit-grade.
Related use cases
Other recurring operations work
Audit dangerous RBAC bindings
Every binding granting cluster-admin or wildcard verbs across every cluster, with subject attribution and change history.
Sweep TLS certificates expiring this month
Every cert-manager Certificate object expiring within 30 days, grouped by owner, with the renewal state per cert.
Run recurring operations work as code
Codify the operations work senior engineers repeat every week and let Hyground execute it deterministically with a full audit trail.
Run a blast-radius pass against your fleet
Pick a recent CVE, give us a sandbox cluster with read access, and we will run the same workflow against your environment in front of your security lead.