Attestly

Trust & Security

Read-only by design. Customer code never leaves the scan job.

Attestly is a compliance product, so we hold ourselves to the same evidence bar we generate for you. This page is the source of truth for how the platform handles your repository and tenant data.

Principles

Four invariants the codebase enforces — not aspirations.

Read-only repository access

GitHub OAuth scopes are limited to repo read. Attestly never holds write, admin, or workflow scopes. We cannot push commits, open PRs, or modify settings on your repos.

Ephemeral scan environment

Each scan downloads a tarball of the requested ref into an isolated worker, runs static analysis, persists only structured findings (file paths and line numbers — not source), and discards the working copy.

Tenant isolation at the row level

Every row in the database is scoped by tenant_id. Server actions and API handlers resolve the caller's tenant from the verified Clerk session before any read or write.

No free-form LLM prose in published documents

All document generation uses strictly typed schemas. The model fills structured fields; the renderer produces deterministic Markdown. Prompt-injection in your repo cannot exfiltrate text into a published policy.

Data we store

The shortest list of data that lets the product function. Nothing more.

  • GitHub OAuth access token (encrypted at rest, scoped read-only)
  • Repository metadata (owner, name, default branch, last scanned commit)
  • Structured scan findings (kind, source path, line, optional snippet)
  • Generated document versions (typed JSON + rendered Markdown)
  • Tenant facts you provided in onboarding (legal entity, jurisdiction, contact email)
  • Stripe customer / subscription IDs (no card data — Stripe holds it)

Data we never store

If a fact is missing, generators emit “Customer-defined” rather than guess.

  • Cloned source code after a scan completes
  • Customer end-user PII from your application database
  • Production traffic, logs, or telemetry from your services
  • Any data outside the repositories you explicitly connect
  • Payment card numbers, CVCs, or bank credentials

Infrastructure

Database

Neon Postgres in a single primary region. Encryption at rest (AES-256). Daily automated backups with point-in-time recovery up to 7 days.

Secrets

Stored in the hosting provider's encrypted secret manager. No secrets in the repository. Rotated on personnel change.

Application

Next.js on a serverless edge runtime; background jobs on Inngest with signed event payloads. TLS 1.2+ end to end.

Sub-processors of Attestly

The third-party services Attestly itself uses to deliver the product. We notify Growth+ customers in writing before this list changes.

VendorPurposeRegion
VercelApplication hostingUS / EU
NeonPostgres databaseUS
ClerkAuthenticationUS
InngestBackground job orchestrationUS
OpenAIStructured document generationUS
StripeBillingUS
ResendTransactional emailUS / EU
GitHubSource code access (read-only)US

Reporting a vulnerability

Email security@attestly.dev with steps to reproduce. We acknowledge within one business day and aim to resolve critical issues within seven. We do not pursue legal action against good-faith research conducted under a coordinated disclosure timeline.

Out of scope: denial-of-service, social engineering of staff, physical access to offices.

Compliance roadmap

  • SOC 2 Type II — controls implemented; observation window in progress.
  • GDPR — DPA available on request for any paid plan.
  • EU AI Act — Attestly is a limited-risk provider; AIBOM and Annex IV mappings published in our own trust center.