Security at Onam

Onam’s product maps your findings to 78 compliance frameworks. That is a product feature, not a statement about Onam’s own certification.

You grant access with a template we provide, run in your own account, so you can read every permission before you deploy it.

Posture scanning is read-only. It uses read permissions only.

Agentless workload scanning runs inside your account. If you enable it (AWS, Azure, Google Cloud), the template also creates resources in your account: a scan workflow, short-lived scan machines built from disk snapshots, and a storage bucket for results. Those resources hold the permissions needed to create and delete snapshots and scan machines; Onam’s own role can only start that workflow, not create or delete resources itself. Leftover scan resources are removed automatically after a set number of hours.

What Onam reads. AWS’s ReadOnlyAccess policy and Azure’s Storage Blob Data Reader role are broad enough to read stored objects, not only configuration. Onam requests them so data security posture management can locate where sensitive data lives. Posture scanning and data classification read configuration and metadata; they do not read the contents of your files, objects or database rows.

• Hosting: Onam runs on AWS, in the region agreed with you — US, Europe, India or other regions — so you can meet your own compliance requirements.
• What we store: configuration and metadata from your clouds, findings, the asset and attack-path graph, and your users’ account details, in PostgreSQL and a graph database (Neo4j).
• Your cloud credentials: where a cloud needs a stored credential (for example an OCI API key or an Alibaba Cloud access key), it is kept in AWS Secrets Manager, which encrypts it with AWS KMS. For AWS we store no secret — Onam assumes your role.
• Your source code (AI Code Fix only): when you run a fix, the repository is cloned for that run and the clone is deleted when it finishes. The Git token is used for that request only and is never stored or logged. See AI Code Fix.
• Retention and deletion: customer data is kept for 30 days after a customer deactivates, then deleted.

• At rest: customer data is encrypted at rest. Stored credentials are encrypted by AWS KMS through Secrets Manager.
• In transit: data is encrypted in transit for all customer-facing and service-to-service traffic, with one internal job being moved to TLS. Browser-to-Onam traffic uses HTTPS.

• Single sign-on: SAML 2.0 (set up per organisation), OpenID Connect, Google and Microsoft sign-in.
• Multi-factor authentication: use your identity provider’s MFA through single sign-on. Built-in MFA for password sign-in is not available yet.
• Session cookies are HttpOnly, Secure in production, and SameSite=Lax.
• Roles: users are invited into an organisation and can be limited to specific cloud accounts. Read-only roles cannot start scans or fixes.

Every customer’s data carries a tenant identifier. In our main databases, PostgreSQL row-level security policies make the database itself refuse to return another tenant’s rows.

• Reads of the product’s data views are written to an audit log: who, what, when, from where, and the result.
• Databases are backed up with AWS Backup.

The third parties that process customer data on our behalf today:

We will update this list before adding a new sub-processor.

Found a security issue in Onam? Email security@onamsecurity.com. Please give us enough detail to reproduce it, and a reasonable time to fix it before telling others.

Safe harbor. We will not take legal action against research done in good faith that avoids privacy violations, data destruction and service disruption, and that tests only accounts you own.

Our machine-readable contact file is at /.well-known/security.txt.

We thank the researchers who report issues to us. None have been reported yet.