Answers for your security questionnaire.

Skylos Cloud (skylos.dev) and the open-source Skylos CLI. This is a self-assessment, not an audit report.

One maintainer builds and runs Skylos. There is no separate security team and no second human reviewer for changes.

To be confirmed.

GitHub private vulnerability reporting (https://github.com/duriantaco/skylos/security/advisories/new) or founder@skylos.dev. Also published in https://skylos.dev/.well-known/security.txt.

Managed providers only: Vercel for the app (functions in pdx1, Portland, Oregon), Supabase for the database, sign-in and storage (AWS us-west-2, Oregon) and Vercel Sandbox for hosted scans (Vercel's default region iad1, to be confirmed).

Skylos runs no servers of its own.

Multi-tenant. Workspaces share one database and are separated by row-level security policies and by membership checks in the app. There is no dedicated tenancy or private networking.

Skylos stores customer data in the United States (Supabase, AWS us-west-2) and processes it in US regions of Vercel. There is no choice of region. Some providers' locations are still to be confirmed; see the subprocessor list.

Nothing. The CLI scans on your machine and needs no account. Data reaches Skylos only on the paths listed on the trust page: scan uploads, the GitHub App, hosted scans, the public scanner, AI actions and deep scans. One exception: in CLI 4.49 and earlier, skylos agent commands send a run summary (counts, model name, commit, branch, author name; no code) whenever a Skylos token is present.

Account data (GitHub user ID, name, email, avatar); workspace, role and billing metadata; scan findings with file paths, line numbers and short code snippets; commit author emails from git blame on uploaded findings; audit records; encrypted credentials for integrations you connect.

Full source code only inside a hosted-scan sandbox for the length of one scan, and in the requests sent to AI providers when someone uses an AI action or a deep scan.

Card and payment details stay with Lemon Squeezy.

The App asks for: Contents: read and write, to open the workflow, cleanup and fix pull requests; Workflows: read and write, to add .github/workflows/skylos.yml; Pull requests: read and write, to open pull requests and comment on them; Checks: read and write, to publish the Skylos check on each pull request; Actions: read, to read a pull request's workflow run to verify its upload; Administration: read, to read branch rules to confirm the check is required (write is not needed); Metadata: read, to list the repositories the App can see.

Hosted scans do not use those permissions directly: each scan mints a token limited to one repository with read-only contents access, and revokes it after the clone. A scan starts when someone picks a repository, or straight after the App is installed from the Scan a repository button if that installation covers exactly one repository.

Skylos does not train AI models, on customer data or otherwise.

HTTPS only, with HTTP Strict Transport Security (one year, including subdomains). Supabase states that its APIs accept only TLS 1.2 or 1.3. Hosted-scan sandboxes reach GitHub, OSV (Cloud scans) and Anthropic (deep scans) over HTTPS.

Supabase states that all customer data is encrypted at rest with AES-256; Skylos relies on that and has not verified it independently.

On top of that, Skylos encrypts third-party credentials with AES-256-GCM before storing them: deep-scan Anthropic keys, Jira, GitLab, Bitbucket and Azure DevOps tokens, and webhook signing secrets. Project API keys are stored only as SHA-256 hashes.

Slack and Discord webhook URLs are stored without that extra application-level encryption.

Encryption keys are environment secrets in the Vercel project. There is no separate key-management service or hardware security module.

GitHub sign-in, which asks only for your public profile and email addresses and gives no repository access. SAML single sign-on is set up on request.

Members can enrol an authenticator app. Owners can require two-factor or SSO for their workspace; it is enforced on dashboard pages, browser API routes and database row-level security for core tables. Owners stay exempt from the SSO requirement so they cannot be locked out. CLI, CI and API tokens are machine credentials and are not subject to these rules.

Four roles (owner, admin, member, viewer) over 29 permissions. Spending credits, managing integrations, rotating keys and overriding gates are separate permissions.

Workspace changes are recorded in an audit log on every plan. On the Workspace and Enterprise plans, members can view it and export it (CSV, JSON or NDJSON), read it through the /api/v1/audit-events API, and open an access review page that lists members, pending invitations, admin-managed keys and uploads not tied to a member.

Owners and admins can share one scan through a link, choosing whether code snippets and suppressed findings are included. Anyone with the link can view that scan until sharing is turned off. Sharing is recorded in the audit log.

Not available. Self-serve identity provider setup is not available either.

The one maintainer, through the Vercel, Supabase and GitHub App administration consoles. Server code uses Supabase's service role, which bypasses row-level security, for background jobs and system writes.

To be confirmed for each provider account.

No process beyond the providers' own account logs.

Application errors go to Vercel's runtime logs, kept for the period the Vercel plan allows. The email sender never logs the provider key or the message body.

There is no SIEM, log drain or third-party error tracker.

There is no external uptime monitor or hosted status page. skylos.dev/status only confirms that the status endpoint answered.

Every pull request and push to main in the Cloud repository runs a blocking npm audit of production dependencies (moderate and above), an advisory audit of all dependencies, lint, logic tests, route-authorization, row-level-security and audit-event contract checks, database regression tests and security probes against a production build.

The open-source CLI scans its own code with Skylos on every pull request.

Hosted scans run one pinned scanner version, and each new version is reviewed for new ways to run code or reach the network before the sandbox image is rebuilt.

No third-party penetration test has been done, and there is no paid bug bounty.

Reports go through GitHub private vulnerability reporting or email. Skylos aims to acknowledge a report within 2 business days and give a first triage update within 5.

There is no written incident response plan or on-call rotation; the one maintainer handles incidents.

If you sign the DPA, its security-incident notice terms apply (the Common Paper DPA sets 72 hours from when Skylos becomes aware). Without a DPA, no notification commitment is published.

Backups are those included in the Supabase plan in use, which is to be confirmed. No recovery point or recovery time objective is published, and no restore test is documented.

Skylos depends on one maintainer, which is a key-person risk.

The CLI is Apache-2.0 open source and works without Skylos Cloud, so scanning does not depend on the hosted service. On the Workspace and Enterprise plans, findings and the audit log can be exported as CSV or JSON and read through the /api/v1 API; the Free plan has no export.

Owners choose how long scan results are kept: 30, 90, 180 or 365 days on every plan, 730 or 1,095 days on paid plans, or no age limit. 30 days is the floor. A daily job deletes older scans and their findings, except each project's latest scan. Separately, each project keeps at most its newest 10 (Free), 500 (Workspace) or 10,000 (Enterprise) scans.

An owner can delete a workspace from Settings by retyping its name after a recent sign-in. After a 7-day grace period, in which any owner can cancel, keys, tokens and integration credentials are revoked first, then all workspace data is deleted. A receipt with only a hashed workspace ID and counts is kept as proof.

People's own Skylos accounts, Lemon Squeezy's invoices and the provider's database backups (until they roll off) are not removed by workspace deletion.

Repository copies exist only inside a non-persistent sandbox for the length of one scan. Staged upload files are removed from storage when the upload completes.

AI triage and Fix in PR use Skylos's own OpenAI key and run only when a person starts them. Deep scans use your workspace's own Anthropic key: Anthropic bills you, and your Anthropic terms apply. The CLI's AI commands use the provider you configure and never pass through Skylos.

Only owners and admins can save or delete the key. It is checked with Anthropic once, encrypted with AES-256-GCM, and decrypted only to start a deep scan, where the sandbox firewall adds it to requests for api.anthropic.com. It never enters the sandbox, and Skylos shows only its last four characters.

Skylos keeps AI results as findings or issue notes under the retention settings above. What OpenAI keeps follows OpenAI's API data terms for Skylos's account; what Anthropic keeps follows your Anthropic account's terms.

Skylos is not SOC 2 certified and holds no ISO/IEC 27001, CSA STAR or HIPAA attestation. Its providers' certifications do not extend to Skylos.

A Data Processing Agreement is available on request. We use the Common Paper DPA v1.1 standard terms (CC BY 4.0), with the subprocessor list on this site as its list of approved subprocessors.

Listed at https://skylos.dev/trust/subprocessors, with the data each one receives and its location.