Security
Our Security Posture
We built a compliance platform. The last thing we can afford is to have bad security ourselves. Here’s exactly what we do to protect your data.
Infrastructure Security
Hosted on AWS (us-east-1)
All Sprala services run on AWS infrastructure in the US East region. Compute runs on ECS Fargate — no persistent EC2 instances to patch or manage. Our architecture follows AWS Well-Architected principles.
Private network architecture
Application services run inside private subnets with no direct internet exposure. All inbound traffic flows through an Application Load Balancer and WAF. Database and cache nodes are unreachable from the public internet.
Encryption at rest and in transit
All data at rest is encrypted using AWS-managed keys (AES-256). All data in transit is encrypted via TLS 1.2 or higher — there are no unencrypted HTTP endpoints in production. RDS and S3 storage are encrypted at the volume and object level.
Infrastructure as code
Our entire AWS environment is managed with Terraform. All infrastructure changes go through version-controlled pull requests and automated pipelines, not manual console clicks.
Application Security
Authentication via Clerk
User authentication is handled by Clerk, a purpose-built auth platform. We do not store passwords. Session management, MFA support, and brute-force protections are delegated to Clerk.
No plaintext credential storage
Integration credentials (AWS keys, OAuth tokens, API tokens) are encrypted at the application layer using Fernet symmetric encryption before being stored in the database. Keys are never logged.
JWT verification on every request
Every API request is authenticated by verifying a short-lived JWT against Clerk's public keys. There are no long-lived session cookies or static API keys used for customer-facing endpoints.
Tenant isolation
Sprala is multi-tenant. Every database query is scoped to the requesting workspace at the API layer. There is no path for one customer to access another customer's data.
Role-based access control
Workspace access is governed by roles (Owner, Contributor, Viewer, Auditor). Permissions are enforced at the API level, not just the UI. Auditors receive read-only access via time-limited invitation tokens.
Secrets management
Application secrets (database credentials, third-party API keys, encryption keys) are stored in AWS Secrets Manager and injected into containers at runtime. They are never baked into container images or committed to source control.
Secure Development Practices
CI/CD pipelines with automated testing
Every commit to the main branch goes through automated test suites before deployment. Our CI/CD pipelines run on AWS CodePipeline and CodeBuild, with separate test, build, and deploy stages.
Dependency management
Python and Node.js dependencies are pinned to specific versions and reviewed before updates. We monitor for known vulnerabilities in the dependency tree.
Least privilege IAM
ECS task roles follow least-privilege principles. Each service has its own IAM role scoped to the minimum permissions required to function. There are no admin-level credentials in application code.
Audit logging
Application events — user logins, integration connections, scan runs, evidence uploads — are logged with timestamps and actor identity. CloudTrail captures all AWS API activity.
Data Practices
What we store
Sprala stores compliance check results, evidence files you upload, and metadata about your connected integrations (account IDs, org names). We do not store the underlying contents of your code repositories, emails, or internal communications.
Evidence file storage
Evidence files uploaded to Sprala are stored in a private S3 bucket with server-side encryption. Files are accessed via short-lived pre-signed URLs — there are no permanently public file URLs.
Data isolation
All customer data is logically isolated by workspace ID at every layer of the stack. We do not commingle customer data in shared storage objects.
Our Own Compliance Journey
Practicing what we preach
Everything described on this page is live in production — not aspirational, not planned. We architected Sprala from day one under the same principles we help our customers implement. We are actively working toward formal certification, and the controls, documentation, and evidence collection that certification requires are already in place. When our auditors arrive, they will find a prepared team.
Security questions or concerns?
If you’ve found a potential security issue or have questions about our security practices, please contact us directly. We take every report seriously.