Security

Last updated: August 2026

Aletheore audits other people's code, so we hold ourselves to the same evidence-grounded standard we ask of you. This page describes what we actually do, not what a template says a security page should claim. Where we fall short of something you'd expect, we say so directly rather than leave it unstated.

Your source code

When the GitHub App runs a scan, your repository is cloned into a scan worker and analyzed. For a repository we scan only once, that clone is discarded afterward. For one we scan repeatedly, a working copy is kept on the scan worker between scans so a later scan can process only what changed - it is deleted on uninstall or a data-deletion request, and never otherwise retained. Only derived evidence, findings like secrets matches, dependency graphs, and endpoint health rows, is written to our database. What reaches our LLM provider depends on the feature: Flash review (automated PR review, Flash tier and up) sends the pull request's diff itself - your actual source code, for the changed lines - while managed audits and AIRview (AIR) send only derived evidence, never raw source files. See our Privacy Policy for the full data-handling breakdown.

GitHub App permissions

The GitHub App requests the minimum scopes needed to clone a repo, read pull request and push events, and post check results and PR comments: repository contents (read), pull requests (read/write for comments and checks), and webhook delivery for the events we act on. It does not request organization-wide admin scopes, and it cannot see or modify repository settings, other installed apps, or billing on your GitHub account.

Authentication and webhooks

Dashboard sign-in uses GitHub OAuth; we never see or store a GitHub password. Both inbound webhook sources we depend on, GitHub and Paddle, are verified against an HMAC signature before we act on the payload, and unsigned or mismatched deliveries are rejected outright. Authentication endpoints are rate-limited per source IP to slow credential-stuffing and session-fixation attempts.

Infrastructure

Traffic to the app is served over TLS. Application data lives in a Postgres database that is not exposed to the public internet; it's only reachable from our own backend services. Payment details are never handled by our servers, checkout and card data are processed entirely by our payment provider, Paddle, which is itself a Merchant of Record and PCI-DSS compliant. We do not see or store card numbers.

What we scan for, in ourselves

Every pull request and every push to master runs through the same class of checks we sell: container image scanning with Trivy, which blocks a merge outright on a HIGH or CRITICAL vulnerability with a known fix, CodeQL static analysis, and an SPDX software bill of materials generated for every service image. We also dogfood our own product: the Proof page shows Aletheore's own repo scanned by Aletheore's own CLI, and our status page is our own endpoint-health monitoring feature, pointed at ourselves.

Where we're honest about gaps

Aletheore is a small, early-stage team. We do not currently hold a SOC 2, ISO 27001, or similar third-party compliance certification, and we don't claim to. If that's a hard requirement for your organization, tell us, it's useful signal for what to prioritize next.

Reporting a vulnerability

If you find a security issue in Aletheore, the app, the CLI, or this site, email support@aletheore.com with "security" in the subject line. We'll acknowledge reports and won't take legal action against good-faith, non-destructive testing aimed at reporting a vulnerability to us.