Security & Trust

Connecting your AWS account to a third-party service requires real trust. Here is the current trust model in plain English: what the Core Scan Role can access, what optional roles unlock, what gets stored, and how the product is reviewed.

Core Scan Role FirstOptional Add-OnsManaged Encryption at RestTLS in TransitPublic Permissions MatrixData Never Sold

Where is your data stored?

Core customer data stays in managed, encrypted services.

Supabase — PostgreSQL

Primary database for all structured scan data.

  • Scan results & cost findings
  • AWS account metadata (IDs, role ARNs, external IDs)
  • User profiles & notification settings
  • Managed provider encryption at rest and managed backups
US-East (default)Managed cloud platformEncrypted backups

Application & report services

Managed infrastructure used to run the app and store generated report artifacts when needed.

  • Generated exports and report artifacts only
  • Server-side services run on managed providers including AWS and Vercel
  • Encryption at rest is handled by managed provider controls
  • Scan-result retention follows your subscribed plan
Managed providersPlan-based scan retention

What can we see?

The Core Scan Role stays narrow. More sensitive data sources are separate opt-in capabilities.

What we CAN access

  • EC2 instance types, states, and IDs
  • EBS volume sizes and attachment status
  • RDS instance configurations (not DB contents)
  • CloudWatch aggregated metrics
  • Cost Explorer billing data
  • Optional S3 bucket metadata when the S3 inventory role is connected
  • Optional CloudWatch Logs Insights results when the logs-diagnostics role is connected
  • Optional IAM and tag metadata when those optional roles are connected

What we CANNOT access

  • S3 object contents (your files)
  • RDS / database row data
  • EC2 instance memory or disk contents
  • Secrets Manager or Parameter Store secret values
  • AWS access keys or long-lived AWS credentials from your account
  • Arbitrary data inside your resources

Default minimal AWS access

New accounts start with the Core Scan Role instead of one broad role up front.

  • The required Core Scan Role handles the first scan and default baseline findings
  • Cross-account access is via roles you create and can revoke at any time
  • S3, IAM, tag inventory, and CloudWatch Logs access are separate optional roles
  • External ID protection against confused-deputy attacks
  • Temporary STS session tokens are used for AWS API access and are not stored long-term
  • We store connection metadata such as role ARNs and external IDs so scans can run again later
  • You maintain full control and can disconnect at any moment

Encryption & access controls

Your data is protected at every layer.

At Rest

  • Managed provider encryption for primary database and storage services
  • Encrypted backups for core data stores
  • Generated reports stored only in managed services when enabled
  • No long-lived AWS access keys stored

In Transit

  • TLS on web and API traffic
  • HSTS enforced
  • Secure cookies for authenticated sessions
  • Origin checks on public forms and callbacks

Access Controls

  • Row-Level Security on customer data tables
  • Short-lived auth tokens
  • TOTP MFA available for users
  • Privileged server-side access for backend operations

Your data is isolated from other customers

Row-Level Security is enforced at the database level — not just in application code.

Every database query is automatically filtered by your customer_id. This is enforced at the PostgreSQL level — meaning even if there were a bug in our application code, the database itself would prevent your data from being returned to another customer's session.

CREATE POLICY "Users can view own scans" ON scans FOR SELECT
USING(customer_id = auth.uid());

Security review posture

How OpsCurb supports procurement, legal, and security review.

OpsCurb formal certifications

Not claimed

OpsCurb does not currently claim formal compliance certifications.

Payment security

Processor-managed

Payments are handled by DodoPayments; OpsCurb does not store card details.

Privacy requests

Supported

Data access/export/deletion requests are handled via support@opscurb.com.

Data residency

US-East default

Enterprise requests for custom residency may be available.

Public trust docs

The same access manifest drives the onboarding wizard, generated policy files, and published permissions matrix.

Our data promise

  • We never sell your data to third parties
  • We only share data with required subprocessors
  • You can request full data export at any time
  • You can request data deletion at any time
  • We notify you within 24 hours of any security incident
  • Aggregated anonymous metrics only for product improvement
  • Questions? Contact us at security@opscurb.com. Full details in our Security Policy and Data Handling documentation, plus the public Permissions Matrix and AI Assurance documentation.