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 these permissions: repository contents (read and write), checks (write), pull requests (write), issues (read), repository metadata (read), and read access to the email address of the GitHub account that signs in. It subscribes to the check run, issue comment, pull request and push events. Pull request and checks write access are used to post reviews, comments and check runs. Contents write access exists for one optional feature: when you turn on Docs sync, Aletheore pushes the generated docs to a dedicated aletheore/docs-update branch and opens a pull request from it. It never pushes to your default branch, and an installation that has not turned Docs sync on never uses that access. The App does not request organization-wide admin permissions, 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
In scope: the Aletheore GitHub App, our API backend, the CLI, the dashboard, and this website. Out of scope: GitHub, Paddle, or our LLM providers themselves (report those to the vendor directly), and testing that risks other customers' data or availability: no denial-of-service testing, no social engineering against our team or customers, no automated scanner output with no demonstrated real impact.
How to report: email support@aletheore.com with "security" in the subject line and the steps to reproduce. We'll acknowledge within 2 business days and keep you updated as we work on it.
Disclosure timing: we ask for 90 days, or until a fix is live, whichever is sooner, before any public disclosure, so a real issue isn't exposed to other customers while it's still open. In return, every verified report gets a dated entry in our changelog once the fix ships, including how long it took us, whether the report came from a customer, a researcher, or our own audits.
Safe harbor: we won't take legal action against good-faith, non-destructive testing aimed at reporting a vulnerability to us, scoped to the assets listed above. We don't currently offer a paid bounty.