Onam Security Reviews and Details

Questions & Answers

1. What makes Onam Security unique?

   One security graph, not a suite. Most "unified" platforms are acquisitions stitched behind a single login — separate data models, separate consoles, findings that never meet. Onam was built from one inventory and one rule model, so connecting a single cloud account activates every capability at once: posture, attack paths, identity, data, containers, SaaS and detection. That design produces things a stitched suite structurally cannot. SaaS posture sits on the same graph as cloud posture, so a Google Workspace admin without MFA and an over-permissive IAM role can be scored as hops on one attack path. And coverage goes deep where others go wide — 11,346 posture rules across 549 services on seven clouds, including OCI, Alibaba Cloud and IBM Cloud, which most competitors treat as a checkbox.

2. Why should a person choose Onam Security over its competitors?

   Three reasons. First, consolidation that is real: one agentless connection replaces six tools and five dashboards, and there is nothing to install — read-only credentials, no sidecars, no daemons on your nodes. Second, prioritisation you can act on. Attack-path analysis cuts thousands of findings to the handful an attacker could actually chain, each mapped to MITRE ATT&CK with hops-to-breach and blast radius, and risk is expressed in dollars via the FAIR model rather than another severity label. Third, breadth without shallowness: 78 compliance frameworks from a single control set, 7 clouds and 8 SaaS platforms on one graph, and rules defined in versioned YAML rather than hardcoded — so coverage is auditable and extensible instead of a marketing number.

3. How would you describe the primary audience of Onam Security?

   Small and mid-sized security teams carrying enterprise-sized cloud estates. The typical user is a cloud security engineer, security architect or head of security at an organisation running two or more clouds plus a heavy SaaS footprint, responsible for thousands of assets with a team of two to twenty people. They are the teams for whom the six-product approach never worked — not because they could not buy the tools, but because nobody had the headcount to wire them together and triage five queues. Compliance leads are a strong secondary audience, particularly at organisations under multiple overlapping regimes that need one control set to answer to all of them.

4. What's the story behind Onam Security?

   Onam was built by people who have run incident response, threat hunts and cloud architecture reviews — not by a marketing team that later hired security. The frustration that started it was specific: paying for six products, wiring five dashboards, and still missing the finding that mattered. The conclusion was that fragmentation is not a UI problem to be solved with another dashboard; it is a data-model problem. Findings cannot be correlated if each product holds its own inventory in its own schema. So Onam started at the other end — one inventory, one rule model, one graph — and built the capabilities on top of that rather than bolting them together afterwards.

5. Which are the primary technologies used for building Onam Security?

   Python and FastAPI power the backend, with a single backend-for-frontend gateway exposing roughly 166 endpoints across 60 routers, plus Pydantic for validation and SQLAlchemy over PostgreSQL for the inventory and findings data model. Attack-path analysis runs on a Neo4j property graph, per tenant, with roughly 25 catalog-driven edge derivers. All 11,346 posture rules are defined in human-readable YAML and versioned in a catalog — the platform loads and evaluates rules, never hardcodes them. Cloud collection uses provider SDKs and read-only APIs: the AWS SDK, Azure Management API, GCP Cloud Asset API and equivalents. The console is TypeScript, React and Next.js with Tailwind CSS. The platform runs as multi-tenant SaaS.