# Skylos security overview Last checked against the code: 15 October 2026. Live version: https://skylos.dev/trust/security-overview This is a self-assessment written for vendor-security questionnaires. It is not an audit report. Where something is not in place or not yet known, it says so. Status key: In place, Partial, Not in place, To be confirmed. ## Company and scope ### Scope Skylos Cloud (skylos.dev) and the open-source Skylos CLI. This is a self-assessment, not an audit report. ### Team One maintainer builds and runs Skylos. There is no separate security team and no second human reviewer for changes. ### Legal entity **Status:** To be confirmed To be confirmed. ### Security contact **Status:** In place 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. ## Hosting and data location ### Hosting **Status:** In place 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. ### Tenancy **Status:** In place 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. ### Data residency **Status:** Not in place 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. ## Data Skylos receives ### By default **Status:** In place 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. ### Categories 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. ### GitHub App permissions 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. ### AI model training **Status:** In place Skylos does not train AI models, on customer data or otherwise. ## Encryption ### In transit **Status:** In place 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. ### At rest **Status:** Partial 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. ### Key management **Status:** Partial Encryption keys are environment secrets in the Vercel project. There is no separate key-management service or hardware security module. ## Access control in your workspace ### Sign-in **Status:** In place 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. ### Two-factor and SSO enforcement **Status:** In place 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. ### Roles **Status:** In place Four roles (owner, admin, member, viewer) over 29 permissions. Spending credits, managing integrations, rotating keys and overriding gates are separate permissions. ### Audit log and access review **Status:** In place 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. ### Shared scan links **Status:** In place 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. ### SCIM provisioning **Status:** Not in place Not available. Self-serve identity provider setup is not available either. ## Access by Skylos ### Who has production access **Status:** In place 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. ### Two-factor on provider accounts **Status:** To be confirmed To be confirmed for each provider account. ### Privileged access logging and reviews **Status:** Not in place No process beyond the providers' own account logs. ## Logging and monitoring ### Logs **Status:** Partial 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. ### Uptime monitoring **Status:** Not in place There is no external uptime monitor or hosted status page. skylos.dev/status only confirms that the status endpoint answered. ## Vulnerability management and development ### Automated checks **Status:** In place 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 scanner **Status:** In place 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. ### Penetration testing and bug bounty **Status:** Not in place No third-party penetration test has been done, and there is no paid bug bounty. ## Incident response ### Reporting and response targets **Status:** In place 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. ### Written plan **Status:** Not in place There is no written incident response plan or on-call rotation; the one maintainer handles incidents. ### Customer notification **Status:** Partial 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 and continuity ### Database backups **Status:** To be confirmed 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. ### Business continuity **Status:** Partial 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. ## Retention and deletion ### Scan retention **Status:** In place 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. ### Workspace deletion **Status:** In place 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. ### Hosted-scan code **Status:** In place 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 features ### Whose model key **Status:** In place 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. ### Deep-scan key handling **Status:** In place 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. ### Retention **Status:** Partial 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. ## Certifications and legal ### Certifications **Status:** Not in place 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. ### Data Processing Agreement **Status:** Partial 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. ### Subprocessors **Status:** In place Listed at https://skylos.dev/trust/subprocessors, with the data each one receives and its location. ## What leaves your machine | Path | Trigger | What Skylos receives | Kept out | |:--|:--|:--|:--| | Local CLI scan | `skylos .` and other local commands, without `--upload` | Nothing from your code or findings goes to Skylos. If a Skylos token is present, a scan downloads your project's custom rules from Skylos Cloud, sending only the token. Dependency checks (`--sca`, `-a`) send package names and versions to OSV, package-existence checks send package names to public registries (PyPI, npm, the Go proxy), and `skylos agent` commands send code to the model provider you configure. None of these pass through Skylos. | CLI 4.49 and earlier: `skylos agent scan`, `agent verify` and `agent remediate` also send Skylos Cloud a run summary whenever a token is present, even without `--upload`: counts, the model name, commit, branch and the CI or commit author name. No code, file paths or findings. To avoid it, run agent commands without a saved login or `SKYLOS_TOKEN`. | | Scan upload | `skylos . --upload`, `skylos upload`, or the CI workflow `skylos cicd init` writes (its upload job runs on pushes to the default branch) | The scan report: for each finding the rule ID, severity, message (up to 500 characters), file path, line number, a code snippet of up to 240 characters and the git-blame author email of that line; plus commit, branch, the CI actor or commit author name, CI run details, the Skylos version and summary counts. Optional sections: AI provenance, defense, technical debt and a symbol index (names and locations) for dead-code review. | Your source files. Findings for secrets are sent without a snippet. `skylos ingest claude-security` also uploads by default (`--no-upload` keeps it local), and `--verify` sends the scan's findings to Skylos Cloud for checking. | | Cloud scan (GitHub App) | A member picks a repository with Scan this repo, or installs the GitHub App from Scan a repository (which scans straight away if the installation covers exactly one repository). Each push to the default branch then re-scans it until an owner or admin turns it off | Skylos mints a read-only token for that one repository, clones one commit into a fresh, non-persistent Vercel Sandbox that can reach only github.com, revokes the token, limits the network to api.osv.dev, runs the pinned open-source scanner without running your code (its dependency check sends package names, ecosystems and versions to OSV), and keeps the findings report. The sandbox is stopped after the scan (at most 215 seconds). | Commit author emails and CI details (Cloud scans read no git history). The repository copy is not kept. | | Other GitHub App use | A repository with the App installed | Repository metadata; the one file involved when someone opens a finding's code view or clicks Fix in PR (read on demand, not saved to the database); and the pull request comments, check runs and pull requests you ask for (workflow setup, fixes, cleanups). | | | Public scanner | Pasting a public GitHub repository address into skylos.dev/scan | The same throwaway sandbox clones the public repository and scans it. The result is returned to your browser and not saved to any workspace; Skylos keeps only a rate-limit counter keyed by repository name. | | | AI triage and Fix in PR | A signed-in member requests AI triage, or an owner or admin clicks Fix in PR (both charge credits) | Skylos sends OpenAI, on Skylos's own key, the issue's rule, title, file paths, one code snippet and taint-flow locations for triage, or the whole source file (up to 64 KiB) and the finding for a fix. A triage answer is stored with the issue; a fix is pushed to a new branch and opened as a pull request for you to review. | | | Deep scan (VulnHunter) | An owner or admin saves the workspace's own Anthropic API key, then someone starts a deep scan with a spending limit | The commit is cloned into a non-persistent Vercel Sandbox whose network then reaches only api.anthropic.com, where the sandbox firewall adds your key, and Skylos's results address. Code from the repository goes to Anthropic under your account. Skylos stores the findings, with snippets of up to 2,000 characters. | Your key never enters the sandbox: it is not in its environment, command line or files. Skylos shows only its last four characters. | ## Subprocessors | Provider | Service | Customer data | Location | When | |:--|:--|:--|:--|:--| | Vercel | Hosting for the web app, API and scheduled jobs; runtime error logs | Everything sent to or shown by Skylos Cloud passes through it: account details, uploaded scan reports (findings, file paths, code snippets, commit author emails) and the tokens in API requests | United States: functions run in Vercel's pdx1 region (Portland, Oregon); static pages are served from Vercel's global edge network | Always | | Vercel Sandbox (Vercel) | Temporary, isolated virtual machines for hosted scans: Cloud scans of connected repositories, the public /scan page and deep scans | A full copy of the scanned repository at one commit, for the length of one scan. Each sandbox is created non-persistent and stopped when the scan ends | United States: Vercel's default Sandbox region, iad1 (Washington, D.C.). Skylos's code sets no other region; to be confirmed against the project's settings | Only for hosted scans you start or turn on | | Supabase | Postgres database, sign-in (Auth) and file storage | Everything Skylos Cloud stores: accounts (GitHub user ID, name, email, avatar), workspaces and roles, scan reports and findings, audit logs, encrypted integration credentials and hashed API keys; report files while an upload is in progress | United States: AWS us-west-2 (Oregon) | Always | | GitHub | Sign-in, the Skylos GitHub App and tokenless CI uploads (GitHub Actions OIDC) | Sign-in reads only your public profile and email addresses. Through the App, Skylos reads repository metadata and single files on demand, and writes the pull request comments, check runs and pull requests you ask for, which contain findings or code changes | GitHub's own hosting (to be confirmed per your GitHub plan) | Sign-in always; the App only on repositories where you install it | | Lemon Squeezy | Merchant of record: checkout, payments, invoices and sales tax | Your email address and a checkout reference from Skylos. Card and billing details you enter on Lemon Squeezy's checkout never reach Skylos | To be confirmed | Only when you buy a plan or credits | | OpenAI | AI triage and Fix in PR, on Skylos's own OpenAI API key | AI triage: the rule, title, file paths, one code snippet and taint-flow locations of an issue. Fix in PR: the whole source file (up to 64 KiB) and the finding | To be confirmed | Only when a signed-in member requests AI triage, or an owner or admin clicks Fix in PR | | Anthropic | Deep scans (VulnHunter), on your workspace's own Anthropic API key | Source code from the scanned commit, as the model reads it. This runs under your Anthropic account and terms, and Anthropic bills you for it. When the key is saved, Skylos checks it once by listing one model, which sends no code | Set by your Anthropic account | Only after an owner or admin saves a key and someone starts a deep scan | | Resend | Transactional email: invitations, workspace deletion notices, weekly digest and reminders | Recipient email address, workspace and project names and, in the weekly digest, the rule IDs, file paths and line numbers of new issues | To be confirmed | Only when email is turned on. It is not turned on yet; Resend is listed in advance | | Cloudflare | DNS for skylos.dev and forwarding of email sent to founder@skylos.dev | Email you send to founder@skylos.dev. Website and API traffic does not pass through Cloudflare | To be confirmed | DNS always; email only when you write to us | | Google (Gmail) | The maintainer's mailbox, which receives forwarded founder@skylos.dev email | Support, privacy, DPA and security email you send to founder@skylos.dev | To be confirmed | Only when you write to us | Services a workspace connects itself (data goes only where you point it): - Slack and Discord: Gate results and exception reminders, sent to the incoming-webhook URL a workspace saves - Outbound webhooks: Signed event payloads sent to the HTTPS address a workspace sets - Jira Cloud: Tickets a member creates from a Skylos issue, in the Jira site an owner or admin connects - GitLab.com: Review discussions on changed lines of merge requests, for connected GitLab projects - Bitbucket Cloud and Azure DevOps: Pull request comments, statuses and annotations for connected repositories Not used: - No third-party error tracking (such as Sentry), session replay, product-analytics SDK, advertising network or data broker. Application errors go to Vercel's runtime logs. - Vercel Web Analytics counts page views on public marketing pages only, with the address stripped to its path (no query string). Dashboard pages are not tracked. Other outbound lookups: - GitHub's OIDC signing keys (token.actions.githubusercontent.com), to verify tokenless CI uploads. Nothing is sent. - PyPI (pypi.org): the package name a repository declares, checked before Skylos opens a weekly cleanup pull request. - OSV (api.osv.dev): during a Cloud scan, the package names, ecosystems and versions the repository's manifests and lockfiles declare, to look up known vulnerabilities. No code or file contents. Request the DPA or ask a question: founder@skylos.dev.