Workload security for containers, Kubernetes and VMs
A cloud workload protection platform (CWPP) is a security solution that finds, monitors and prioritises risk in the virtual machines, containers and serverless functions your applications run on in the cloud, from build artefact to what is live right now.
one.O Guard makes that view part of the platform already scoring your configurations and identities, with agentless scanning for cloud, code and endpoints.
CWPP vs CSPM in one.O Guard
CSPM assesses your cloud by its settings; workload protection assesses what those settings are running. one.O Guard carries both in one connected view, so an issue on either side arrives with the context of the other.
Configuration belongs to cloud posture. Access belongs to CIEM and data security. The workloads themselves belong to CWPP, where a flaw in live traffic becomes an attacker's way in.
Guarding workloads into production
Most workload risk only appears once things run, which is where one.O Guard's idea of runtime protection starts. Run-state is a first-class input. The security graph can pull several minor findings into one higher-risk issue, ranked by CVSS severity, EPSS exploit probability and CISA KEV data attached to guide what comes first. A secret in an image that is running publicly, for example, shows up both on its own and inside the combined issue.
Signals like these raise the risk level in the backlog, and a click sends the corrective action to Jira or GitHub with guidance instructions attached.
What risks does a CWPP scan for?
Most workload findings fall into six recurring categories:
Vulnerable software
Published CVEs surface in OS packages, application libraries and stale base images. one.O Guard weights them by exploitability rather than raw severity.
Misconfigurations and exposure
Insecure container and host settings can quietly leave a workload open to the outside. That exposure decides how urgent the rest becomes.
Accidentally exposed secrets
Keys, tokens and credentials get left in code or images more often than anyone admits. A leaked one turns a minor flaw into an open door.
Excessive permissions
Service accounts and root containers tend to hold more rights than they need. The identity half of this risk carries on in CIEM.
Sensitive data on workloads
Personal or confidential records sometimes sit on workloads where nobody expects them. Classifying and protecting them is the job of data security.
Compliance violations
A workload that breaks a CIS benchmark or a regulatory baseline counts as a finding too. Cross-framework tracking happens in continuous compliance.
What gets scanned in one.O Guard
Coverage starts from what you already run; results collect in one backlog, weighted by severity and context. Serverless functions join as inventoried assets.
Container images from any registry
The image scanner takes each image apart, hunting for packages with published CVEs (Common Vulnerabilities and Exposures), and the package catalogue shows which images carry them. It covers registry images and public pulls from Docker Hub, so a vulnerable base image is visible before your CI/CD pipeline ever ships it. Once that image goes live, its findings gain the run-state context too.
Kubernetes resources down to CRDs
The Kubernetes scanner walks the whole cluster through the Discovery API, from Pods, Deployments and Services to the CRDs (Custom Resource Definitions) your platform team has added. The result is a cluster inventory security and engineering can share.
VM hosts and discs
Host scanning combs a virtual machine and its discs for vulnerable packages. It also detects host misconfigurations and validates secrets, licences and end-of-life software, with no agent involved. Its output lands beside the image and cluster results.
SBOMs, packages and licences
Each image also yields an SBOM (Software Bill of Materials). one.O Guard keeps a catalogue of the packages and versions you run, joins it to the CVE database, and flags licence violations alongside vulnerabilities. As soon as a new CVE is published, the catalogue shows exactly where the affected package is located within your cloud infrastructure.
Internet-facing workloads
Endpoint scanning records whether a workload answers to the internet and stores a timestamped capture of what it detected. That signal reshuffles your priorities, because an exposed workload with a known vulnerability is a different problem from the identical one kept private.
How the scanning reaches your workloads
one.O Guard covers cloud accounts, code repositories and endpoints from the outside, leaving the workloads untouched.
For Kubernetes, a lightweight scanner runs in a dedicated namespace inside the cluster, whether that cluster is a hyperscaler or on STACKIT. You deploy it once with Kustomize or Terraform, and it reports back over an encrypted, mutually authenticated channel. Both routes end in one policy engine and one backlog.
How to roll out workload protection
Teams that adopt workload security successfully follow a recognisable sequence, even with no one to spare for tuning. one.O Guard was designed around it; the goal is prevention without a flood of warnings.
Connect your cloud accounts
API access is all it takes; nothing is installed on the workloads. Inventory builds on its own while you watch the scope take shape.
Deploy the cluster scanner
One Kustomize or Terraform apply per Kubernetes cluster, starting where it matters most. Coverage grows cluster by cluster, at your own pace.
Establish the risk baseline
The first full scan shows the backlog as it really is. Treat that number as the starting point for prioritisation, not as a to-do list.
Fix what is reachable
Exposed, exploitable and running comes first; severe-but-inactive can wait. Working in that order clears real risk early.
Record what you accept
Not fixing something can be a sensible decision when the reason is written down. The paper trail is already there when an auditor asks.
See workload risk with its surroundings
A workload issue in one.O Guard comes with the identities that touch the workload while it runs, the data behind it, and the configuration underneath. One platform spanning six domains supplies all of it.
Recognised frameworks
The policies behind these scans reference CIS benchmarks, ISO 27001, PCI DSS and NIST; the rest of the compliance picture is continuous compliance territory. one.O Guard processes and stores workload scan data in the EU.
FAQs about CWPP
Because the richest view of a cluster is the one from within. The scanner sees the cluster's full resource map, custom types included, plus the contents of the images it runs. Deploying it needs cluster access and permission to apply resources, nothing more; it lives in its own namespace, and its connection status is visible in the dashboard at any time.
Image scanning pulls the image apart and ingests its SBOM without waiting for anything to run. A bad base image becomes a problem you solve where it is stored, long before deployment. Fixing it there is a small edit; fixing it in production is a rollback.
Yes. When your containers run images that never touch your registries, those get the same treatment. Public base images are common in day-to-day operations, and the one nobody checked is the classic blind spot in container security.
Kubernetes security posture management (KSPM) is the discipline of continuously checking cluster configurations, workloads and access against security best practice. It is the Kubernetes-shaped part of the wider CWPP promise. In one.O Guard, the in-cluster scanner delivers KSPM, and its results queue up alongside image, host and exposure findings.
Protection while workloads run comes from run-state signals rather than an in-workload agent. one.O Guard tracks what is serving traffic, what answers to the internet, which runtime accounts are in play and which systems have aged out of support, and moves live risk to the front of the queue.
Use exposure and exploitability instead of raw severity. An issue that is internet-exposed, carries a high EPSS probability or appears in CISA's KEV list matters more than a technically severe CVE on a dormant workload. The signals behind that call are facts about the workload, which keeps the effort on fixing instead of fine-tuning.
They are the three reference points one.O Guard attaches to a finding. CVSS (Common Vulnerability Scoring System) rates how severe a vulnerability is on a scale of 0 to 10. EPSS (Exploit Prediction Scoring System, from FIRST.org) estimates how likely a published CVE is to be exploited in the wild within the next 30 days. The CISA KEV catalogue (Known Exploited Vulnerabilities, from the US Cybersecurity and Infrastructure Security Agency) lists flaws already under active exploitation. A finding that scores high on all three is the one to fix today.
GKE on Google Cloud, EKS on AWS and AKS on Azure are supported, and so is STACKIT. One scanner and one policy engine apply across them; a multi-cluster setup behaves as a single inventory.
Ready to see how workload protection works in one.O Guard?
We're happy to help with your questions and requirements. Book your personal consultation now, or send us a message.
