Architecture Overview

The Onam platform is a multi-tenant SaaS that continuously discovers, evaluates, and monitors cloud resources across seven cloud providers — AWS, Azure, GCP, OCI, Alibaba Cloud, IBM Cloud, and Kubernetes — using read-only credentials. There are no agents to install for cloud scanning and no changes to your environment. This page explains how the platform is organized: the 29 engines, the pipeline a scan flows through, the unified data model behind every finding, and how your data is isolated from every other tenant.

By the end you will be able to trace any number in the Onam console — a posture score, a compliance percentage, an attack path — back to the exact engine, table, and scan run that produced it.

What you're looking at, top to bottom:

1. Your cloud environments — AWS, Azure, GCP, OCI, Alibaba Cloud, IBM Cloud, and any Kubernetes cluster connect via a read-only IAM role, service principal, or service account.
2. The scan pipeline — every connected account flows through the same ordered stages: credential validation, Discovery & Inventory (DI), rule evaluation, domain-engine fan-out, attack-path graph build, compliance mapping, and FAIR risk quantification.
3. Security engines — 29 engines cover posture, identity, data, network, container, AI, vulnerability, and behavioral detection.
4. The data platform — findings, inventory, relationships, and the attack-path graph are stored in tenant-isolated databases that only your authenticated users can read.
5. Outputs — a posture score (0–100), compliance reports for 70+ frameworks, prioritized findings, attack paths with choke points, and step-by-step remediation guidance.

A typical scan of a 40-service AWS account completes in around 15 minutes. Findings appear in real time as each stage completes — you don't wait for the full pipeline to see results.

The 29 security engines

The platform runs 29 engines, each a dedicated microservice responsible for one area of cloud security. (Attack Path v1 remains in maintenance for legacy tenants; Attack Path v2 is the active engine.)

Every engine writes to the unified security_findings table (see the finding contract below). The API layer reads exclusively from this table — there are no per-engine report tables in the current architecture.

The API layer — BFF gateway

All console and programmatic access goes through a single BFF (backend-for-frontend) API gateway built on FastAPI. It exposes roughly 166 endpoints across ~60 routers under the /api/v1 base path, with a per-engine prefix for each domain (/api/v1/di, /api/v1/check, /api/v1/compliance, /api/v1/iam-security, /api/v1/data-security, /api/v1/network-security, /api/v1/container-security, /api/v1/cdr, /api/v1/risk, and so on).

Representative endpoints:

GET /api/v1/dashboard
GET /api/v1/attack-paths
GET /api/v1/compliance/framework/{framework_id}/report
GET /api/v1/cdr/heatmap
GET /api/v1/vulnerability/findings/stats
GET /api/v1/risk/blast-radius
GET /api/v1/inventory/asset/{resource_uid}/blast-radius
GET /gateway/health
GET /gateway/services
GET /gateway/openapi.json

The gateway enforces authentication and tenant scoping before any request reaches an engine — see Platform data security and tenancy.

Core design principles

Five non-negotiable principles drive every decision in the platform. Together they make it safe to deploy in regulated environments, easy to integrate, and predictable to operate.

1. Agentless by default

You install nothing to scan your clouds. The platform never deploys agents on your VMs, never injects sidecars into your containers, and never adds a daemon to your Kubernetes nodes. Every scan is performed externally over read-only cloud APIs (AWS SDK, Azure Management API, GCP Cloud Asset API, and equivalents) using credentials you control.

The one deliberate exception is opt-in: the optional onam-agent for Linux, macOS, and Windows performs OS-level vulnerability scanning on hosts you choose and reports outbound to the central engine. The cloud connection itself always stays agentless.

Why this matters for you: zero blast radius from the platform itself. If you revoke access tomorrow, your environment keeps running unchanged. There is nothing to uninstall.

2. Multi-tenant always

Every database query is filtered by your tenant identifier taken from the authenticated request. There are no shared tables, no cross-tenant views, and no admin "see-everything" mode. Tenant isolation is enforced independently at three layers — the API gateway, the security engines, and the database — so a bug in any one layer cannot expose another tenant's data.

Why this matters for you: SOC 2 and ISO 27001 auditors look for defense-in-depth on data isolation. Three independent enforcement points satisfy that requirement.

3. Pipeline-driven with a single scan ID

Every cloud account scan is assigned a single UUID called scan_run_id. That ID flows through every stage and is stamped on every finding the scan produces. Two scans of the same account produce two completely separate finding sets, each tagged by its own scan_run_id.

Why this matters for you: when you investigate "why did the score change last Tuesday?", you can pull every finding from that exact run, compare it to the previous run, and see precisely what changed. Findings never leak between scans.

4. Standardized finding contract

Every security domain produces findings using the same standard fields — finding_id, scan_run_id, account_id, resource_uid, resource_type, severity, status, first_seen_at, last_seen_at. The contract is consistent across all clouds and all security pillars.

Why this matters for you: a single API call, a single export, a single CSV download gives you the same shape of data whether the finding came from CSPM, CIEM, DSPM, or vulnerability management. There's nothing per-domain to learn.

5. Rule-as-code in YAML

All 10,000+ security rules are defined in human-readable YAML and versioned in a catalog. The master rule registry holds 10,864 rules: AWS 2,278 (157 services), Azure 3,741 (112 services), GCP 2,676 (47 services), OCI 1,451 (42 services), and Kubernetes 718 (51 resource kinds), with rule-metadata coverage extending to Alibaba Cloud (1,541) and IBM Cloud (613). Dedicated CIEM rule packs, Technology Engine rules, and SecOps rules add further coverage. Each rule declares its cloud, service, severity, MITRE ATT&CK mapping, framework controls, and remediation guidance. The platform only loads and evaluates rules — it never hardcodes them in software.

Why this matters for you: auditors can read the YAML to verify exactly what the platform checks. You can request new rules, propose changes, and see the diff between rule versions over time.

From cloud account to posture score

A connected cloud account flows through a value pipeline that turns raw cloud configuration into prioritized, framework-mapped, dollar-quantified findings. This is the loop the platform repeats for every account on every scan.

The output serves three audiences: a posture dashboard for security engineers, compliance reports for auditors, and actionable findings with remediation steps for the cloud account owner.

Domains by layer in the diagram:

• Web tier — the Onam console, where you investigate findings, run scans, and configure your tenant; protected by SSO, RBAC, and tenant-scoped routing.
• Core pipeline (sequential) — Onboarding (credential validation), DI (enumeration and enrichment), Check (rule evaluation), Attack Path (graph build). These run in order because each consumes the previous stage's output.
• Security domains (parallel) — IAM/CIEM, Network, Data Security, Database Security, Encryption, Container, AI Security, API Security, Vulnerability, CDR, CWPP, CNAPP. These run simultaneously after inventory completes.
• Intelligence layer — Compliance mapping, FAIR risk scoring, and AI-generated threat narratives from the Remediation/Fix engine.

You don't enable domains individually. Once a cloud account is connected, every applicable domain runs on every scan.

The ten security pillars and what each one answers:

The unified posture score is a weighted roll-up across all pillars, normalized to 0–100. Each pillar contributes proportionally to its severity-weighted findings — fixing a single Critical finding moves the score more than fixing ten Low findings.

For the stage-by-stage walkthrough of a scan — triggers, DI phases, engine fan-out, graph build, and monitoring — see The scan pipeline.

Multi-cloud coverage

The platform supports seven cloud providers using a read-only IAM role (AWS, OCI, Alibaba Cloud, IBM Cloud), service principal (Azure), service account (GCP), or kubeconfig (Kubernetes). The same pipeline and the same rule registry run against every provider — what differs is the per-cloud service catalog and the credential model.

Rule depth per provider (master registry, plus rule-metadata coverage for Alibaba and IBM):

Dedicated CIEM rule files add identity-specific coverage on top: AWS 530, Azure 202, GCP 176, Alibaba 114, IBM 110, OCI 107, and Kubernetes 103. Beyond the clouds, the Technology Engine extends the same model to 40 self-hosted technologies in 10 categories — databases, Linux/OS, network devices, web servers, virtualization, containers, DevOps, collaboration, data platforms, and middleware.

Coverage parity: the same finding contract, the same severity grading (Critical, High, Medium, Low, Info), and the same MITRE mapping apply across all seven providers. A "publicly exposed object storage" finding on AWS S3 and on Azure Blob shows up identically in your dashboard — same severity, same control mapping, same remediation pattern.

The platform never writes, deletes, or modifies anything in your cloud account. Read-only is enforced by the IAM policy you grant — you can audit it before you enable scanning. See Platform data security and tenancy.

Data flow and the finding contract

A single cloud resource — say one S3 bucket — flows through the platform from raw configuration to a posture-score contribution. Understanding this flow tells you where every piece of information in your dashboard came from and how to trace any finding back to its source data.

Following one S3 bucket through the pipeline:

1. DI enumeration captures the raw bucket configuration — every property the AWS API exposes. Nothing is filtered or summarized at this stage.
2. DI enrichment and normalization turns the bucket into a standard asset record in asset_inventory — common fields like resource_uid, region, and tags become first-class. Relationships (for example "this bucket is read by these Lambda functions") are written to asset_relationships. Drift vs the prior scan is tagged.
3. Check evaluates every applicable rule ("S3 public access blocked", "S3 default encryption enabled", "S3 versioning enabled") against the configuration. Each rule produces a PASS or FAIL.
4. Attack Path v2 loads assets and relationships into the Neo4j graph and derives edges through ~25 catalog-driven derivers (IAM policy, network exposure, security-group rule match, KMS, CDR behavioral, is-public). If "S3 public access blocked = FAIL" and the bucket holds PII, the graph gains a candidate edge toward MITRE technique T1530 (Data from Cloud Storage Object).
5. Compliance maps the FAIL to framework controls. The same single FAIL on "S3 public access blocked" appears in CIS AWS 2.1.5, NIST SP 800-53 SC-7, PCI-DSS 1.3.4, HIPAA §164.312, and SOC 2 CC6.1 — one finding, five framework citations, all auto-mapped.
6. Risk weights the finding by severity, blast radius (how many resources depend on this bucket, straight from the graph), and asset criticality (does this resource expose PII?). The FAIR model converts that into a dollar-exposure estimate and a posture-score contribution.

Every finding record carries a standard set of fields regardless of which engine produced it. This is what enables cross-domain queries, exports, and a unified dashboard:

The security_findings table

All 29 engines write to a single security_findings table in the DI database. This is the canonical source of truth for every finding on the platform; the BFF gateway reads exclusively from it. Every engine upserts findings using a shared writer, keyed on (tenant_id, account_id, rule_id, resource_uid):

Auto-resolution: a finding is marked PASS when the next scan of the same resource no longer triggers the rule. The last_seen_at timestamp is updated on every scan; findings not seen for 30 days are auto-closed.

Inventory and posture tables

Two more tables complete the data model. asset_inventory and asset_relationships are produced by DI — normalized asset records plus typed edges (containment, attachment, network reachability, IAM trust) that feed the attack-path graph and the blast-radius APIs. posture_snapshot stores one row per engine per scan — total findings, Critical and High counts, and a 0–100 domain score — and backs every engine's /api/v1/{engine}/status endpoint.

Platform security, reliability, and data residency

The platform protects your data with defense-in-depth across independent layers — tenant isolation, role-based access control, and read-only credential handling. Any single layer's failure cannot cause a data exposure because the others still hold.

Multi-tenant isolation

Every API request carries an AuthContext — a server-built object with the caller's tenant ID, role, and permissions. Tenant isolation is enforced at three independent points so a bug in any one cannot leak another tenant's data.

1. Layer 1 — API gateway. The auth middleware validates your access token, looks up the user, and constructs the AuthContext. The token is signed; tampering invalidates it immediately. Engines never trust client-supplied identity.
2. Layer 2 — security engine. Every route validates that the caller holds the right feature:action permission (e.g. findings:read, scans:create). Unauthorized callers receive HTTP 403 with no data leakage in the error body.
3. Layer 3 — database query. Every read and write is filtered by your tenant ID. There is no global query path and no admin bypass.

There is no environment variable, debug toggle, or support-mode switch that bypasses authentication, and there are no shared tables. Onam support staff cannot read your tenant's findings without an explicit, fully audit-logged impersonation handshake that you must approve. The full storage, credential, and residency model is documented in Platform data security and tenancy.

Role-based access control

The platform ships with five seeded roles and 27 permissions in the feature:action format. Roles are hierarchical — higher levels inherit the read permissions of lower levels.

Sensitive areas — Data Security, AI Security, Encryption, Database Security, Container Security, SecOps, and Vulnerability — require tenant_admin or higher, because they contain sensitive resource details that should not be exposed to read-only auditors. SAML 2.0 SSO and SCIM provisioning are supported on Enterprise plans; group-to-role mappings sync from your identity provider on every login.

Reliability

A live status page and historical incident reports are available at status.onam.io. Maintenance windows are announced 7 days in advance.

Data residency and disaster recovery

Your findings, inventory, and graph data are stored in the region you select: ap-south-1 (Mumbai, all plans), eu-west-1 (Ireland, Enterprise), us-east-1 (N. Virginia, all plans), and us-gov-west-1 (Government/FedRAMP plans). Cross-region access is blocked by tenant policy and backups stay in-region. Recovery targets: RPO 15 minutes (backups every 15 minutes), RTO 2 hours, with quarterly DR tests reported publicly.

Frequently asked questions

Does the scanner modify any cloud resources? No. Every stage uses read-only IAM roles or API credentials. The platform never writes to, deletes from, or modifies your cloud environment. The IAM policy you grant explicitly excludes write actions — you can audit it before enabling.

How is my data isolated from other tenants? Three independent enforcement layers: the API gateway builds the auth context, the engine validates permissions, and every database query filters by tenant ID. There are no shared tables, no cross-tenant views, and no admin bypass.

How often does the platform scan? Default is once per day per cloud account. You can configure up to four scans per day on Pro plans, and run ad-hoc scans at any time from the console or the API.

What credentials does the platform need? A read-only IAM role (AWS, launched via CloudFormation with an ExternalId), service principal (Azure), service account (GCP), or equivalent per provider. Credential references are stored in AWS Secrets Manager, encrypted with KMS. We never store cloud account passwords.

What happens when a scan fails? The pipeline marks the failed stage and continues. Findings from successful stages are still surfaced, failures are logged with root-cause context, and you can re-trigger from the console without affecting the prior scan's data. The Pipeline Monitor engine streams live status throughout.

Can I export my data? Yes. Finding history and inventory export as JSON, CSV, or Parquet via the API; compliance reports export as PDF. You retain ownership of all data.

Is the platform SOC 2 / ISO 27001 certified? SOC 2 Type II, ISO 27001, ISO 27701, and PCI DSS v4 — all current. Pentest report and CAIQ are available under NDA.

Next steps

• The scan pipeline — end to end — triggers, DI phases, engine fan-out, graph build, and monitoring
• Platform data security and tenancy — what is stored, credential handling, and read-only enforcement
• Compliance framework coverage — 70+ frameworks, per-control scoring, audit-ready reports
• Book a demo — see the full pipeline run against a live demo account