01
You create a read-only IAM role
In your AWS account, you create a tiny IAM role whose trust policy names the trueno principal and the external ID you generated in the dashboard.
Security
Security by design. Read-only by default.
trueno uses read-only AWS access, short-lived STS sessions, and server-side scanning so your cloud data stays isolated and your write path stays untouched.
01 · AWS access model
Read-only, external-ID gated, revocable in one step.
trueno never asks for AWS access keys. Every scan opens a short-lived session that you can cut off from the AWS console at any time.
02
You attach four AWS-managed read-only policies
SecurityAudit, ViewOnlyAccess (job-function), AWSBillingReadOnlyAccess, and ComputeOptimizerReadOnlyAccess, plus a small grouped inline policy that covers newer services AWS lags on (Inspector, Macie, Shield, WAF, Network Firewall, Glue, Athena, MSK, OpenSearch, Step Functions, Backup, FSx, Global Accelerator). Every action is list/describe/get of configuration metadata. No write actions. The onboarding flow generates the exact JSON for you.
03
trueno assumes the role via STS
On each scan, the platform calls sts:AssumeRole with your external ID. STS returns short-lived credentials. Nothing is persisted server-side beyond the role ARN and the external ID hash.
04
AWS API calls run server-side
All AWS SDK calls originate from server-side code marked import "server-only". SDK packages never ship in the client bundle.
02 · Account security
Your account, behind a second factor.
The AWS connection is read-only, but the workspace it reports into is still an account worth protecting. trueno ships MFA, OAuth, step-up verification, and role-based access out of the box.
Multi-factor authentication
Turn on TOTP from any authenticator app, backed by one-time recovery codes so a lost device never locks you out. MFA is enforced on every subsequent sign-in once enabled.
Password and OAuth sign-in
Sign in with email and password or with Google or GitHub OAuth. Every request re-validates the session against Supabase Auth on the server, never trusting a cookie blindly.
Step-up verification
Sensitive actions (like connecting an AWS account) re-challenge for your second factor even inside an already-authenticated session, so a hijacked tab can't escalate.
Role-based workspace access
Members are viewer, operator, or admin. The role is enforced on the server across both the dashboard and the public API, not just hidden in the UI.
03 · Workspace isolation
One workspace cannot see another.
Isolation is enforced at the database, the trust boundary, and the AWS layer, not just in the application.
Row-level security on every workspace table
Findings, resources, scans, recommendations, comments: every row carries an organization_id, and every read is gated by an RLS policy. A workspace cannot read another workspace's rows even if the application code regressed.
Service-role writes are scoped to system paths
Only the async processor and scan runners use the Supabase service-role key. User-facing routes always use the request-scoped user client. The boundary is enforced at the repo layer.
No cross-tenant aggregation
We don’t pool findings across workspaces. There is no "benchmark vs. your peers" feature. There is no training data extracted from your environment.
External-ID gated trust
Your workspace generates a unique external ID. The IAM trust policy you write in AWS includes that external ID as a sts:ExternalId condition. This defeats the confused-deputy pattern at the AWS layer, not just in our application.
04 · Revocation
You revoke from AWS, not from us.
The IAM role you created is the single point of access. Delete it and the relationship ends. There is nothing else to wind down.
01
02
03
05 · Current trust posture
Honest about where the trust program is today.
trueno is currently early-stage and transparent about its trust program. We do not claim SOC 2, ISO 27001, HIPAA, or PCI-DSS certification today. Third-party penetration testing and formal compliance audits will be added as customer requirements justify them.
Formal certifications
trueno is early-stage and transparent about its trust program. We do not claim SOC 2, ISO 27001, HIPAA, or PCI-DSS certification today. Third-party audits will be added as customer requirements justify them.
Responsible disclosure
Responsible-disclosure reports are read, acknowledged, and triaged directly by the engineering team. A formal bug bounty program will be added when usage and customer demand justify it.
Third-party penetration testing
trueno relies on Next.js, Supabase, and Vercel hardened defaults plus the AWS read-only access model. A scheduled third-party penetration test will be added before any enterprise compliance program ships.
Backups
Workspace data lives in managed Supabase Postgres. Backups follow Supabase's published policy. A dedicated backup pipeline will be added when customer requirements justify the cost.
06 · Reporting a concern
Real engineers respond.
Email security@trueno.io with the workspace id, the affected behavior, and any reproduction steps you have.
Need to disclose a vulnerability?
Reach out by email or open the support page. We do not run a paid bug bounty today, but responsible-disclosure reports are read, acknowledged, and triaged by the engineering team directly.