Cloud Integrations

Trace's cloud integrations connect your cloud accounts so the platform can inventory what you've deployed, map relationships between resources, and surface security exposures that don't show up in source-code scans — public buckets, internet-exposed services, and other misconfigurations.

Today, Trace supports AWS and Vercel integrations. Support for GCP and Azure is on the roadmap.

AWS

Trace connects to AWS using a cross-account IAM role with read-only permissions. Nothing in your AWS account changes; Trace only reads.

How it works

1. From Settings → Integrations → AWS in the dashboard, generate the onboarding artifacts. Trace produces an external ID unique to your organization and a CloudFormation template that creates a read-only role.
2. Deploy the CloudFormation stack in your AWS account. The template creates an IAM role scoped to the external ID, so only Trace can assume it.
3. Paste the role ARN back into the dashboard. Trace verifies access through AWS STS and starts the initial sync.
4. Trace inventories your account on a recurring basis: accounts, regions, key resource types, and the relationships between them. Public-facing resources are tagged so you can spot them at a glance.

What Trace sees

Trace's IAM role grants read-only access. We can list and describe your cloud resources; we cannot create, modify, or delete anything. The CloudFormation template is published with your onboarding artifacts so you can audit every permission before deploying.

When you disconnect, Trace retains your inventory for a fixed grace period (visible on the integration page) so you don't lose context if you reconnect, then deletes it.

Vercel

Trace connects to Vercel through Vercel's native integration framework. You install Trace from your Vercel team and grant the integration read access to your account.

How it works

1. From Settings → Integrations → Vercel in the dashboard, click Connect Vercel. You'll be redirected to Vercel's install flow.
2. Choose the Vercel team / account you want to connect and approve the requested scopes (read-only to integration configuration, projects, domains, and deployments).
3. After redirect, Trace verifies the install and begins syncing inventory: active projects, domains, and deployments.
4. The integration page shows current inventory counts and the last sync time. You can connect multiple Vercel installations to a single Trace organization.

What Trace sees

Trace requests read-only scopes from Vercel:

• read:integration-configuration — confirms the integration is installed
• read:project — lists your Vercel projects
• read:domain — lists domains attached to those projects
• read:deployment — lists deployments per project

We do not request write scopes for project, domain, or deployment data. Disconnecting from Trace or uninstalling from Vercel revokes access immediately.

What this enables

A modern application is more than its source code — it's the cloud resources that host it, the data stores behind it, and the network paths that can reach it. Connecting your cloud accounts lets Trace reason about that surrounding context, which sharpens both scanning and penetration testing.

For scanning

Source-code analysis can tell you a bucket was created with public access or a service binds to 0.0.0.0; it can't tell you whether that resource is actually reachable from the internet in your live environment. Cloud inventory closes that gap:

• Exposure detection. Trace flags resources reachable from outside your network — internet-facing HTTP services, public IPs and open ports, publicly-reachable databases, open storage buckets, serverless function URLs, and exposed management or orchestrator endpoints. These issues live in configuration and deployment state, so they never show up in a source-code scan.
• Context for code findings. The same code-level weakness carries very different risk depending on where it runs. A SQL injection on a service behind a private subnet is not the same as one fronted by a public load balancer. Knowing your deployment topology lets Trace tell what's genuinely exposed apart from what's only theoretically vulnerable.

For penetration testing

When Trace runs a penetration test, the read-only access you've granted lets the engagement work from your real deployment rather than an assumption about it. Using your live topology — which services are public, which paths connect to them, where a data store actually sits — Trace traces attack paths through your real infrastructure to confirm whether a weakness is genuinely reachable and exploitable, instead of stopping at what static analysis can infer. All cloud access during an engagement stays read-only and short-lived; Trace never modifies your cloud.

What's coming

• GCP — workload identity federation, similar read-only model to AWS.
• Azure — service principal with reader-scoped role.
• Kubernetes — cluster inventory and workload analysis.

Reach out to the Trace team if you'd like early access to any of these.