The two aspects of CSPM
Cloud security posture management (CSPM) is the continuous checking of cloud configuration for risky settings, whilst cloud vulnerability management refers to the continuous process of identifying, prioritising and remediating exploitable flaws in the software running on cloud resources. Most teams buy the two separately. Each scanner then works fine on its own terms, while ranking one set of findings against the other stays a manual job.
Configuration checks
one.O Guard tests every connected cloud account against hundreds of curated policies, from unencrypted data stores to open network paths.
Vulnerability scanning
One connection scans your container images, dependencies, source code and committed secrets.
External exposure discovery
one.O Guard enumerates your internet-facing domains and IPs the way an outside attacker would, and records what responded and when.
Agentless by design
one.O Guard reads each cloud through its provider API and installs nothing on your workloads. The onboarding process grants read-only access per cloud account.
Two backlogs, no shared order of work
A misconfigured bucket shows up in one console. The CVE (Common Vulnerabilities and Exposures) in the image running beside it sits in another. Nobody owns the join between the two queues, so the same risk is triaged in both and closed in one, depending on which console someone opened first.
- Separate consoles
- Manual correlation
- Duplicate triage
- Tool sprawl at renewal
How cloud posture controls are organised
Every check traces to a named benchmark. A failed check cites its source, for example a clause in the CIS Microsoft Azure Foundations Benchmark, and carries the OWASP risk category it belongs to.
The set is curated and extensible, so you can add the rules you already enforce internally.
- Data security
- Endpoint security
- Entitlements
- IAM security
- Network security
Vulnerability management from code to cloud
Image scanning, dependency scanning, static code analysis and secret scanning each read a different layer, and every finding lands in one queue in the same shape.
Image scanning before it reaches production
Container images in your registries are checked for known CVEs. In-use context travels with the finding, so you can tell an image running in production from one sitting unused in a registry.
Dependency scanning in connected repositories
Vulnerable components arrive through the build, where infrastructure scanning never looks. Dependency scanning reads your connected repositories and names the component, and the fix goes into the owning team's sprint.
Static code analysis on your source
Static analysis finds insecure patterns in the code itself. Findings arrive with the repository and the file path.
Secret scanning with detector attribution
A committed credential is what stalls an enterprise deal. It is the finding a vendor security assessment or a SOC 2 readiness review turns up first. Secret scanning names the repository, the file path, the highlighted snippet and the detector that matched it, so a developer can confirm the match type at a glance.
External exposure with timestamped evidence
Endpoint scanning probes your public perimeter from the outside and reports reachable endpoints, open ports and related OSINT findings. Each exposure finding keeps a screenshot of the endpoint and the time it was captured.
What decides which finding comes first
Exploitability sets the order ahead of severity, which is what risk-based prioritisation comes down to in practice. one.O Guard includes your own infrastructure to that assessment, weighing whether the component runs in production, who can reach it, and which resources are affected.
One grade per scope
A cloud security posture score reduces one scope to a single number, and the worst issue present sets its ceiling. A critical finding holds it down until that issue is closed.
Clearing a critical or high issue never lowers the score, and medium issues are scaled against the number of assets affected, so a large environment is judged on the same terms as a small one.
Four findings that form one attack path
one.O Guard evaluates a misconfiguration, a CVE, an exposed secret and a public route as a single finding when they form one path to the same resource. A CVE in a running image, an over-privileged service account, a public route in, and the database credential sitting in a repository are four ordinary findings on their own.
What arrives with the finding
Every finding carries its own rationale, description, recommended action, impact and policy evaluation. The action is written for that resource, whether that means console steps with a command to copy or the network ACL (Access Control List) change that closes an exposed endpoint.
Alerting rules route tickets into Jira automatically by team scope. The route from detection to closure runs in five steps.
- Scanners report the finding.
- Cloud, identity and exposure context is attached.
- That context sets its rank.
- The recommended action is applied.
- The fix is verified, or the risk accepted.
Easy integrations
one.O Guard works across AWS, Google Cloud, Microsoft Azure, STACKIT, and many more. It scans computing resource, serverless, containers, databases and datasets, and treats container images and serverless functions as standalone assets.
CSPM is one domain of the one.O Guard CNAPP
one.O Guard is a cloud-native application protection platform (CNAPP) built and operated in the EU. Cloud posture and vulnerability management is one of its six domains, alongside application security, continuous compliance, identity and data, workload protection and AI security, each drawing on the connections you have already granted.
FAQs about CSPM & Vulnerability Management
Both tools detect fine on their own. Ranking a configuration finding in one console against a CVE in another is the part that breaks, so someone rebuilds that connection by hand every week. Keep both detection methods and merge the backlog, and the weekly reconciliation disappears along with one of the consoles.
No agent is deployed to your compute, so there is no rollout to schedule against your release work and no agent version to maintain afterwards. one.O Guard authenticates to each cloud provider's API with read permissions and works from what those APIs return, alongside external scanning of your public perimeter.
Code scanning reads your connected GitHub repositories for credential patterns. A finding names the repository, the file path, the snippet with the secret highlighted, and the detector that matched it, which is enough for the owning developer to act without a second investigation and enough for the answer you owe a customer's security review.
The provider secures the platform underneath. What you configure on top of it stays yours, from access permissions and network settings to how your data is stored. CSPM is the discipline that watches that layer, and one.O Guard does it across your cloud accounts, reporting what has drifted.
Work only on what is reachable, and only where the finding already contains the fix. Ranking by exploitable path shortens the queue that severity ranking keeps full, and routing by resource owner sends the remainder to the people who already maintain those services.
Risk-based vulnerability management means prioritising weaknesses by how likely they are to be exploited and what they expose, with CVSS severity as one input among several. Typical inputs are exploitation status, published for European entries in the EUVD, plus two questions about your own estate: does the vulnerable code run anywhere, and can the asset be reached externally.
Scanning runs from outside your perimeter against your public domains and IP ranges, in the way an attacker enumerates them, and reports reachable endpoints, open ports and related open-source intelligence findings. Each finding ships with a screenshot of the endpoint and its capture time, so the answer goes back with evidence attached.
Ready to take control of your cloud security?
We're happy to help with your questions and requirements. Book your personal consultation now, or send us a message.
