How CoverOps touches your cloud
Written for the person who has to sign off on giving a vendor access to production. No badges and no seals, only the access model and its limits.
Current status: CoverOps is pre-launch and holds no third-party security certification. We are not SOC 2 or ISO 27001 certified, and we will not imply that we are. What follows describes how the product is built, which you can verify yourself during a trial.
The access model
CoverOps does not host your workloads. It operates on your infrastructure through a role you create inside your own AWS or Azure account, using your cloud provider's standard delegation mechanism: an IAM role with an external ID on AWS, or a service principal with a scoped role assignment on Azure.
We do not store long-lived access keys. Sessions are short-lived credentials issued by your provider when a job runs, and they expire on their own. There is no secret of yours sitting in our database waiting to be leaked, because the delegation is revocable from your side at any moment.
What the role is permitted to do
- Read your resource inventory and configuration, in order to plan changes
- Open pull requests against the infrastructure repository you nominate
- Apply Terraform that has been merged in that repository
- Read metrics, logs, and traces from the telemetry endpoints you point at it
- Execute the specific remediations you have explicitly enabled
What it is not permitted to do
- Hold root or owner credentials for your cloud account
- Apply infrastructure changes that have not been merged by someone on your team
- Read application data, database contents, or object storage payloads
- Create new identities or widen its own permissions
- Continue operating after you revoke the role
Visibility and audit
Because CoverOps acts through your provider's own API, every action it takes is recorded in your CloudTrail or Azure Activity Log alongside everything else. You do not have to trust our logs. The authoritative record is one you already own and already monitor.
On top of that, CoverOps keeps its own change history: what it proposed, who approved it, which policies were evaluated, and what the result was. That history exports as artefacts you can hand to an auditor as evidence for your own SOC 2 or HIPAA programme.
What data we hold
To do its job CoverOps stores infrastructure metadata: resource identifiers, configuration, plan output, policy results, and change history. It also stores the account details of the people on your team who use it.
It does not store your application data, your customer records, or the contents of your databases and buckets. Those are never read, and the role is not permitted to read them. Full detail is in the privacy policy.
Revoking access
Delete the role. That is the whole procedure, and it takes effect immediately because the permission lived in your account rather than ours.
Your infrastructure keeps running, your Terraform stays in your repository, and your pipelines continue to deploy. Nothing degrades because CoverOps stopped being able to reach it. See portability for why that is a design constraint rather than a courtesy.
Reporting a vulnerability
If you believe you have found a security issue in CoverOps, please email office@coverops.dev with enough detail to reproduce it. We will confirm receipt and keep you updated on what we find.
We do not currently run a paid bug bounty. We will credit you publicly if you would like us to, and we will not take legal action against good-faith research that respects user privacy and avoids service degradation.
Questions this page did not answer
Security reviews always have a question the vendor page missed. Send yours to our team and we will answer it directly, including when the answer is that we do not support something yet.