Quickstart

This guide takes you from nothing to your first triaged Critical finding in about 15 minutes: create an account, connect a cloud with a read-only role, run the first scan, read the dashboard, triage what it finds, and wire findings into the tool your team already watches.

Most of the steps are clicks. The longest wait is the first scan itself — and it streams findings as it runs, so you will usually be reading results before it finishes. A typical 40-service AWS account completes in around 15 minutes; very large accounts take longer.

Before you begin

• An Onam account invitation or sign-up link (your admin, or Book a demo to get one).
• Credentials for the cloud you're connecting — for AWS, permission to create a CloudFormation stack and an IAM role in the target account.
• 15 minutes. No agents to install, no network changes, no maintenance window.

Step 1: Create your account

1. Open the Onam console and sign up with your work email, or accept your organization's invite.
2. Verify your email and set a password — or use SSO if your organization has SAML configured.
3. On first login you land on the onboarding screen with zero connected accounts.

Step 2: Connect your first cloud

Each provider has a dedicated guide: AWS, Azure, Google Cloud, OCI, Alibaba Cloud, IBM Cloud, and Kubernetes. All of them follow the same pattern: create a read-only credential in your environment, hand Onam the reference, never share a long-lived admin key.

Here is the AWS flow end to end — it is the most common first connection:

1. In the console, go to Onboarding, choose Add cloud account, and select AWS.
2. Onam generates a CloudFormation quick-create link pre-filled with a unique ExternalId for your tenant.
3. Launch the stack in your AWS account. It creates one read-only IAM role whose trust policy only allows Onam's account to assume it — and only when the ExternalId matches.
4. Paste the created role ARN back into the console.
5. Onam validates the connection with a sts:AssumeRole call and stores the role reference in AWS Secrets Manager, encrypted with KMS. No keys ever leave your account.

The ExternalId is what prevents the confused-deputy attack — a third party can't trick Onam into assuming your role on their behalf. Don't edit it out of the template, and don't reuse a role created for another vendor. An access-key option exists for AWS, but the role is strongly recommended: it's revocable in one click and grants nothing writable.

Step 3: Run the first scan

The first scan starts automatically once validation passes (you can also trigger one from Scans). Under the hood it runs as an ordered pipeline:

1. Credential validation — the role is assumed and its permissions confirmed.
2. Discovery and Inventory (DI) — multi-phase enumeration of every resource in the account, written to asset_inventory with cross-resource links in asset_relationships.
3. Rule evaluation — the Check engine evaluates the inventory against the 10,000+ rule registry, producing PASS or FAIL per resource per rule.
4. Engine fan-out — the domain engines (CIEM, data security, network, container, vulnerability, and the rest) run in parallel against the same inventory.
5. Attack path build — assets, relationships, and findings are loaded into the security graph and traversed from entry points to crown jewels.
6. Compliance and risk — findings map onto 70+ framework control catalogs, then FAIR risk quantification converts Critical and High findings into dollar exposure.

Watch progress on the Scans page. Findings appear in real time as each stage completes — you don't have to wait for the pipeline to finish.

Step 4: Read the dashboard

When findings start landing, open Dashboard. Four things are worth reading in order:

1. Posture score — a 0–100 rollup of your pass rate, weighted by severity. Expect it to look worse than you'd like on day one; everyone's does.
2. Findings by severity — counts of Critical, High, Medium, Low, and Info. Only the first two columns should drive today's work.
3. Top risks and attack paths — the graph-ranked issues, which are usually a much shorter list than the raw finding count.
4. Compliance summary — your starting score per enabled framework.

Step 5: Triage your first Critical findings

1. Open Findings and filter to severity Critical.
2. Sort or group by rule — ten findings from one rule (say, unencrypted EBS volumes) are one decision, not ten.
3. Open a finding. The detail view shows the affected resource, the failed rule, the frameworks it violates, and step-by-step remediation — a CLI command, Terraform snippet, or console walkthrough.
4. Check Attack Paths before fixing in ID order: a Medium finding that sits on a path to a crown jewel usually outranks an isolated Critical. Choke points tell you which single fix severs the most paths.
5. Fix what's real, and use Suppressions (with a justification and optional expiry) for accepted risks — suppressed findings stay visible to the security team but leave the active queue.

Step 6: Set up an integration

Findings your team never sees don't get fixed. From Notifications and the Integration Catalog:

1. Connect Slack or email and route new Critical findings to your security channel.
2. Connect Jira to create tickets from findings — assignments and status sync back to the console.
3. If you have a SIEM, forward findings via the REST API or a webhook.

Start with one noise-proof route — Critical findings only, one channel. Widen the funnel after the first cleanup week, not before, or the channel gets muted by Friday.

Next steps

• Core Concepts — the mental model behind everything you just clicked through.
• Connect your remaining accounts — coverage gaps are where incidents live; connect all accounts, not just production.
• Attack Path — how path-based prioritization actually works.
• Framework Coverage — enable the frameworks your auditors care about.