Security Policy

On this page

• The Basics
• What We Can and Can't Access
• IAM Permissions
• Data Handling
• Infrastructure
• Best Practices for Customers
• Reporting Vulnerabilities
• Incidents
• Questions

The Basics

OpsCurb uses a tiered AWS access model. New accounts start with a required Core scan role, and more sensitive workflows such as Deep Inspect, CloudWatch Logs diagnostics, S3 inventory, IAM hygiene, and tag inventory are separate opt-in roles. OpsCurb does not create, modify, or delete resources in your AWS account.

What We Can and Can't Access

Can access:

• EC2 instance metadata (IDs, types, states)
• EBS volume info (size, attachment status)
• RDS instance config (not the database contents)
• CloudWatch metrics and Cost Explorer billing data
• ECS service/task-definition metadata needed to evaluate Fargate waste
• optional S3 bucket metadata when the S3 inventory role is connected
• optional CloudWatch Logs Insights results when the Advanced log diagnostics role is connected
• optional IAM and tag metadata when those optional roles are connected

Cannot access:

• S3 object contents
• RDS/database data
• Secrets Manager or Parameter Store values
• EC2 instance filesystems or shell access

IAM Permissions

OpsCurb no longer documents one broad onboarding role as the default trust story. Review these public artifacts instead:

• Permissions Matrix for action-by-action mapping
• IAM Policy Changelog for intentional permission changes
• the onboarding wizard or Terraform module for the current role definitions
• the legacy broad-access policy only if you are migrating an older account

Data Handling

Scan results and account metadata are stored in Supabase (PostgreSQL). Traffic to managed providers is encrypted in transit, and row-level security (RLS) is enforced at the database layer for customer-facing access. OpsCurb does not store AWS access keys or long-lived AWS session tokens. It does store connection metadata such as role ARNs and external IDs so scans can run again later. See Data Handling for the plain-English version.

Infrastructure

Best Practices for Customers

1. Always use the External ID when setting up IAM roles
2. Rotate External IDs on a schedule that fits your internal security process
3. Enable MFA on your OpsCurb account
4. Monitor IAM role usage via AWS CloudTrail
5. Only grant the permissions in the generated role file you intend to use — nothing more

Reporting Vulnerabilities

Email security@opscurb.com with a description, steps to reproduce, and potential impact. We'll acknowledge within 24 hours and respond in detail within 72 hours. We credit researchers in our acknowledgments if desired.

No formal bug bounty yet — we may offer rewards on a case-by-case basis.

Incidents

Affected customers are notified within 24 hours via email and in-app notification.

Questions

• Security issues: security@opscurb.com
• General support: support@opscurb.com

---

Last Updated: 2026-03-12