Company

Security

DevLeep provisions real AWS infrastructure on your behalf. We take the security of that access seriously. This page describes how we handle credentials, what permissions we use, and how to report vulnerabilities.

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

AWS Access Model

DevLeep uses cross-account IAM role assumption — the same pattern used by AWS-native tools like CloudFormation StackSets and AWS Control Tower. We never ask for or store your AWS Access Key ID or Secret Access Key.

Cross-account role assumption

You create an IAM role in your account with a trust policy that allows only our platform account to assume it, and only when the correct external ID is provided. Without the external ID, the assume-role call fails even if someone knows the role ARN.

External ID

Every DevLeep account gets a unique external ID generated at registration time. This prevents confused deputy attacks — a third party that learns your role ARN cannot assume it without the external ID.

Temporary credentials only

When you start a lab, we call sts:AssumeRole to obtain a set of temporary credentials scoped to that session. Those credentials expire when the session ends (default: 4 hours maximum). We do not cache or reuse credentials between sessions.

Least-privilege permissions

The permissions policy we recommend grants access only to the services needed by lab terraform modules: EC2, VPC networking, and EKS for Kubernetes labs. We publish the exact policy in the setup guide so you can review it before attaching it.

Platform Security

  • ✓Passwords — Stored using bcrypt with a per-user salt. We never log or transmit plain-text passwords.
  • ✓Auth tokens — JWT tokens signed with a rotating secret. Tokens are short-lived and must be refreshed.
  • ✓Role ARNs — Stored encrypted at rest in the database. Decrypted only when needed to call sts:AssumeRole.
  • ✓Transport — All traffic between the client, our API, and AWS uses TLS 1.2 or later. We do not support unencrypted connections.
  • ✓Database — Credentials are never committed to source control. The database is not publicly accessible — only the application server can connect.
  • ✓Terminal sessions — Lab terminals connect directly via Cloudflare Tunnel to your EC2 instance. Terminal I/O does not pass through our servers.

What Is Your Responsibility

Because labs run in your AWS account, you control the blast radius of our access:

  • ›Use a dedicated AWS account for DevLeep, separate from production workloads
  • ›Apply the recommended permissions policy — do not grant AdministratorAccess
  • ›Set an AWS budget alert to notify you if lab costs exceed your expectations
  • ›Disconnect DevLeep from Settings when you are not actively using the platform

Vulnerability Disclosure

If you find a security vulnerability in DevLeep, please report it responsibly. We are a small team and take every report seriously.

EMAILsecurity@devleep.com
SUBJECT[SECURITY] Brief description of the issue
INCLUDESteps to reproduce, affected component, impact assessment, suggested fix if you have one
RESPONSEWe aim to acknowledge reports within 48 hours and provide a fix timeline within 7 days

Please do not publicly disclose the vulnerability until we have had a chance to investigate and release a fix. We will credit researchers who report valid issues.

Out of scope: DoS attacks, brute-force credential stuffing, social engineering, and issues in third-party dependencies that are already publicly known.