CSPM — Cloud Security Posture Management

CSPM is the core posture engine of the Onam platform. It evaluates every resource in your connected clouds against a registry of 10,000+ configuration rules, produces a PASS or FAIL result for each rule-resource pair, and turns every FAIL into a severity-ranked finding with remediation steps, MITRE ATT&CK mapping, and compliance citations.

This page explains what the rule registry covers per cloud, how a single rule is evaluated, how the severity model works, how to suppress findings you have accepted, and how PASS/FAIL results roll up into compliance scores.

What CSPM checks

CSPM answers one question continuously: is every resource configured the way it should be? Public buckets, unencrypted databases, permissive security groups, disabled audit logging, missing MFA, stale credentials — each is a rule, and each rule is evaluated on every scan.

• Agentless and read-only. Scans run through the same read-only credential you created at onboarding (IAM role, service principal, or service account). Nothing is installed and nothing in your cloud is modified.
• All 7 clouds. AWS, Azure, GCP, OCI, Alibaba Cloud, IBM Cloud, and Kubernetes are covered by the same rule format and the same finding schema.
• Every finding is actionable. A finding carries the failing resource, the rule rationale, step-by-step remediation, the MITRE ATT&CK technique it maps to, and the compliance controls it affects.

CSPM checks deployed resources through cloud APIs. To catch the same misconfigurations before deployment, pair it with IaC Scanning — the two engines share rule intent, so a policy blocked in CI is the same policy flagged in production.

Rule coverage by cloud

The master rule registry contains 10,864 rules across the five primary scan targets:

The rule-metadata corpus is larger still — 11,372 rule definition files — and additionally covers Alibaba Cloud (1,541 rules) and IBM Cloud (613 rules). Every rule ships with metadata: severity, domain, rationale, remediation steps, references, and MITRE mapping.

How a rule evaluates

CSPM evaluation is a deterministic pipeline, not a heuristic:

1. Discovery. The Discovery & Inventory engine enumerates every resource in the account and records its full configuration in the asset inventory.
2. Scoping. The Check engine selects the rules whose scope matches each discovered resource — an S3 bucket is evaluated against S3 rules, a Cognito user pool against Cognito rules.
3. Assertion. Each rule references an assertion — a precise condition tested against the recorded configuration. The result is binary: PASS or FAIL.
4. Finding creation. Every FAIL becomes a finding with the rule's severity, remediation, MITRE technique, and compliance mappings attached. PASS results are retained too — they are the evidence behind your compliance scores.

Every rule is defined in YAML. This is a real (trimmed) rule from the AWS registry:

rule_id: aws.cognito.userpool.access_keys_rotated_90_days_or_less_when_present
service: cognito
resource: userpool
scope: cognito.userpool.configuration
domain: configuration_and_change_management
severity: medium
assertion_id: security.configuration.cognito_userpool_access_keys_rotated_90_days_or_less_when_present
description: >
  Verifies security configuration for AWS Cognito user pools to ensure
  alignment with security best practices and compliance requirements.
remediation: |
  1. Open the Cognito console and select the user pool
  2. Review current permissions and key usage
  3. Rotate any access key older than 90 days
  4. Prefer IAM roles over long-lived access keys
mitre_techniques:
  - T1098.001
mitre_tactics:
  - persistence

The naming convention is stable across all clouds — <cloud>.<service>.<resource>.<requirement> — so azure.storage.account.secure_transfer_required and gcp.gcs.bucket.uniform_access_enabled are immediately recognizable, filterable, and scriptable.

Custom rules

The Rule Builder lets you author tenant-specific rules in the same YAML format — for example, enforcing your organization's tagging standard or a stricter TLS minimum. Custom rules evaluate in the same pipeline and appear in the same findings stream as built-in rules.

Severity model

Every rule carries one of five severities. Severity is set per rule and can be re-graded per tenant if your risk tolerance differs.

Severity feeds everything downstream: finding sort order, alerting thresholds, the posture score, and the FAIR risk engine, which only quantifies Critical and High findings in dollar terms.

Suppressions and exceptions

Not every FAIL is a problem you intend to fix. A sandbox account, a compensating control, or a vendor requirement can make a finding acceptable. Suppressions record that decision without deleting the evidence:

• Scope it precisely — suppress a single resource-rule pair, a rule for one account, or a rule tenant-wide.
• Justify it — every suppression requires a reason, which is stored in the audit trail.
• Expire it — set an expiry date so exceptions are re-reviewed instead of becoming permanent.
• Review it — the Suppressions view in the console lists every active suppression, who created it, and when it lapses.

Suppressed findings are excluded from posture scores and alert routing but remain queryable, so auditors can see both the finding and the documented exception.

Prefer expiring suppressions over permanent ones. A suppression with no expiry is how "temporary" exceptions become invisible permanent risk. The console flags suppressions older than 12 months.

Compliance mapping

Every rule is mapped to the controls it satisfies across 70+ compliance frameworks — including CIS Benchmarks, NIST CSF 2.0, NIST 800-53, PCI-DSS v4.0, HIPAA, ISO 27001, SOC 2, GDPR, FedRAMP, DORA, and NIS2. The mapping is maintained in a single policy-to-framework catalog, so one scan produces evidence for every framework simultaneously:

1. A rule evaluates PASS or FAIL per resource.
2. Each result is attributed to every control the rule maps to.
3. Per-control pass rates roll up into framework scores in the Compliance view.

There is no separate "compliance scan" — posture and compliance are the same evaluation viewed through different lenses. See Framework Coverage for the full framework list.

Next steps

• Onboard your first AWS account — connect a cloud in about 10 minutes
• Compliance — how PASS/FAIL results become framework scores
• Attack Path Analysis — how individual findings chain into attack paths
• Book a demo — see the rule registry against your own environment