Skip to main content

Enterprise Trust

Skylos is built as a local-first scanner with optional Cloud governance. The CLI runs analysis locally or in CI. Skylos Cloud stores scan results, project policy, suppressions, audit history, and team workflow state.

Use this page when a security team asks:

  • what data Skylos Cloud receives
  • how uploads are attributed
  • what actions are audited
  • what access controls exist
  • what is available today vs what is still on the enterprise roadmap

Current Posture

Skylos Cloud is ready for a security-team pilot and controlled enterprise evaluation.

It is not yet positioned as a completed regulated-procurement package for teams that require SSO, SCIM, a completed SOC 2 report, DPA automation, status-page commitments, SIEM streaming, and formal SLA paperwork before a pilot can start.

AreaCurrent status
Local-first scanningAvailable
Cloud project governanceAvailable
Project API keysAvailable
GitHub Actions OIDC uploadAvailable
Role-based access controlAvailable
Audit event coverage for mutating routesAvailable
Audit export foundationsAvailable
Upload attributionAvailable
SSO / SAMLRoadmap
SCIM provisioningRoadmap
SOC 2 reportRoadmap
DPA and subprocessor portalRoadmap
Public status page / SLARoadmap
SIEM streamingRoadmap

Local-First Data Model

Skylos analysis runs in the CLI, not in the browser dashboard.

When you run:

skylos . --upload

the CLI sends analysis results and scan metadata to Skylos Cloud. It does not upload the full repository as source blobs.

Sent to CloudNot sent as part of normal scan upload
finding detailsfull repository contents
file pathsraw source tree
line numbers.env files as raw uploads
rule ids and severitygit history as source blobs
branch and commit metadatalocal dependency caches
upload identity metadataarbitrary local files outside the scan result
gate and summary data

Some features can include contextual evidence, snippets, or metadata where needed to explain a finding. Treat uploaded scan results as sensitive security data.

Upload Attribution

Skylos Cloud records server-side attribution for uploaded scans.

Supported upload paths:

Upload pathAttribution source
Browser-linked CLI uploadlinked user and project credential
Project API key uploadresolved project key identity
GitHub Actions OIDC uploadverified GitHub OIDC claims and matched project binding

If two people upload to the same project from different machines, Skylos Cloud records the authenticated upload path and project identity instead of trusting a user-provided name alone.

This is important for enterprise review because the audit trail should answer:

  • which project accepted the upload
  • which auth path was used
  • which repo or project root was resolved
  • which branch and commit were associated with the scan
  • when the upload happened

Access Control

Skylos Cloud uses workspace membership and role-based permissions for team workflows.

Current roles:

RoleTypical use
Ownerworkspace ownership, billing, team governance
Adminproject and integration administration
Membernormal project usage and issue workflow
Viewerread-only review access

Protected actions require the relevant permission before the mutation runs. Examples include project changes, suppression changes, scan sharing, integrations, policy updates, billing checkout, and member governance.

Audit Events

Skylos Cloud records audit activity for mutating governance workflows.

Current audited areas include:

  • project creation, update, deletion, and bulk deletion
  • project repository and GitHub configuration changes
  • GitHub App installation binding
  • Slack and Discord integration changes
  • scan sharing, override, and deletion
  • finding and issue suppression workflows
  • issue assignment and comment changes
  • AI triage requests
  • report uploads
  • credit deduction and credit recovery events
  • billing checkout requests
  • compliance report requests
  • team invite and member governance
  • project API key lifecycle events
  • active organization switching
  • agent run ingestion
  • internal Judge admin import, seed, and suggestion promotion

Audit writes are designed to fail closed for governance-sensitive mutations: if Skylos cannot write the required audit event, the mutation should not silently proceed.

Export and Review

Audit export foundations are available for customer review workflows.

Supported export shapes include:

  • JSON envelope
  • newline-delimited JSON
  • CSV

These exports are intended for security review, procurement evidence, and incident investigation. SIEM streaming is still roadmap, so customers that require live Splunk, Datadog, or Sentinel forwarding should treat that as a procurement requirement rather than an already-shipped feature.

Cloud Providers and Shared Responsibility

Skylos Cloud currently runs on hosted cloud infrastructure and managed services, including Vercel and Supabase.

That means enterprise customers should evaluate Skylos using a shared-responsibility model:

Skylos responsibilityCustomer responsibility
application access controlschoosing who belongs in the workspace
audit event capturereviewing and exporting audit history
project key lifecycle supportrotating keys and limiting secret exposure
upload attribution and policy enforcementconfiguring repo/project bindings correctly
secure handling of scan resultsdeciding which repos and branches upload findings
incident response processreporting suspected security issues quickly

What To Say In Enterprise Evaluations

Use precise language:

Skylos is ready for a security-team pilot. It is local-first, has Cloud governance, project-key attribution, RBAC, audit coverage for mutating governance workflows, and export foundations. For full regulated procurement, SSO, SCIM, SOC 2, DPA automation, public status/SLA, and SIEM streaming are on the enterprise roadmap.

Do not claim that Skylos is SOC 2 certified, SAML-ready, SCIM-ready, or SIEM-streaming-ready until those controls are implemented and verified.

Roadmap Controls

The highest-value enterprise controls still to add are:

  1. SAML SSO with enforced workspace login.
  2. SCIM deprovisioning and group mapping.
  3. Formal SOC 2 readiness program and report.
  4. DPA, subprocessor list, and security contact workflow.
  5. Public status page and incident communication process.
  6. SIEM audit log streaming.
  7. Enterprise support and SLA terms.