Skip to content

Security controls and pilot status

OROTOV security controls and their release status.

Review controls implemented in the repository, deployment verification requirements, and open pre-GA requirements. OROTOV does not claim a security certification.

  • Certification

    None claimed

    This page is a control summary. No audit report is held or implied.

  • Release stage

    Private pilot

    Pre-GA. The gates below are open and are listed rather than glossed.

  • Connector access

    Read only

    GitHub observation reads signed events. Nothing is written back.

  • Actor evidence

    Claimed only

    People and agents write L0. Connectors and reconcilers write above it.

Workspace data

What OROTOV stores and what it excludes.

The lists describe the current repository controls and data-handling boundaries. Deployed status is shown in the control list below.

What we store

  • Workspace recordsStories, issues, decisions, and the links between them.
  • References and identifiersCommit identifiers, pull request numbers, check outcomes, and run references.
  • Evidence entries with provenanceWhat was claimed, what was observed, by which source, and when.
  • Engineering eventsThe append-only event stream a reconciler can replay.
  • Key hashes and prefixesEnough to identify and revoke a workspace key, never enough to reuse it.

What we never store

  • Raw workspace keysThe key is returned once at creation and only its hash is retained.
  • Provider secrets in the repositoryThe GitHub App credential and webhook secret are operator-supplied configuration.
  • Payment detailsCheckout is not enabled, so no payment data is collected or persisted.
  • Unverified claims presented as proofAn actor claim stays labelled Claimed until an independent source observes it.
  • Anything used to train modelsWorkspace content is not used for model training.

Implemented controls

Repository controls and production checks

Verification status: these controls are implemented in the repository. Their presence in code does not establish that the current deployment has been verified; operators must validate the deployed configuration.

The production proxy configuration terminates HTTPS and sends strict transport and browser security headers.

Secured routes require an authenticated account session or another explicitly allowed principal.

Workspace keys bind to one workspace; secured routes apply shared read and write route classes and policy checks.

Secured route policies and data queries bind work to the resolved workspace.

GitHub deliveries require a configured secret and a valid request signature before events are processed.

Raw workspace keys are returned once; only a hash and a short identifying prefix are retained.

Password reset increments the account session version so previously issued sessions stop authenticating.

Email-code requests and verification, password login and reset, key creation, and failed webhook verification use bounded purpose-specific limits for the single-backend pilot.

Sources explicitly identified as human or agent are limited to Claimed (L0) evidence by current service checks. The constitution reserves higher-confidence evidence for trusted connector and reconciler paths.

The repository includes authentication controls for protected issue and story endpoints. Confirm that the deployed backend rejects unauthenticated requests before relying on those controls in production.

The repository includes transactional email delivery and password reset handling. An operator must configure the provider and verify that a real reset email reaches its recipient in the deployed environment.

Deployment operations

What the operator must maintain

Operators configure and maintain the hosted or self-hosted deployment, monitor it, and respond to incidents.

  1. Rotate signing keys, provider credentials, and workspace keys on a documented schedule and after suspected exposure.

  2. Apply least privilege to infrastructure, GitHub App installations, workspace roles, and service accounts.

  3. Maintain DNS, certificate renewal, proxy configuration, and public ingress rules.

  4. Run encrypted backups and retain restore material outside the application checkout.

  5. Configure and verify email and payment providers only for workflows that are enabled.

  6. Monitor service health, authentication failures, webhook failures, capacity, and dependency advisories.

  7. Own an incident-response path with escalation, containment, customer communication, and post-incident review.

Pre-GA requirements

Open before general availability

These requirements remain open. Documentation and a frontend release do not satisfy them.

  1. Move managed PostgreSQL transport from sslmode=require to sslmode=verify-full, then verify certificate and hostname validation.

  2. Harden the trusted-evidence-source allowlist before broadening which connector and reconciler paths may write higher-confidence evidence.

  3. Configure and verify a live payment provider before enabling real checkout. Payment processing remains mock-enabled today, and checkout must use the published workspace formula before it is offered.

  4. Complete a backup restore drill and record recovery time and data-loss results.

  5. Enable monitoring and actionable alerting for availability, authentication, webhook processing, queues, storage, and certificate expiry.

  6. Complete owner and legal review of public terms, privacy, retention, subprocessors, and disclosure handling.

  7. Resolve applicable dependency advisories and record any accepted risk.

  8. Commission an independent security review and track remediation to evidence-backed closure.

  9. Verify public ingress, DNS, certificates, and failover independently.

Access model

Workspace access is scoped and revocable.

A workspace key is shown once and grants access to one workspace. Revoke it to stop that tool from authenticating. The audit trail retains earlier activity.

  • Workspace keyScoped to a single workspace, hashed at rest, revocable at any time.
  • Account sessionVersioned, so a password reset invalidates every session issued before it.
  • GitHub App credentialOperator-supplied, never a user credential, and required before any event is accepted.
  • Webhook signatureChecked on every delivery. An agent key does not stand in for it.

Deployment options

  • Hosted pilot

    Private pilot

    A single hosted backend with workspace-scoped access. Operator prerequisites, including the GitHub App, are configured per deployment.

  • Self-hosted with Compose

    Available

    The production Compose files, proxy configuration, and deploy runbook are in the repository. The stack runs entirely inside your own network.

  • Local CLI

    Release candidate

    The published CLI operates a local stack on your machine for evaluation. It is not a stable Python release.

Self-hosted deployments run the same backend image and the same reconcilers. No outbound connection to us is required for the stack to run.

  • Report a vulnerability

    No public channel yet

    An owner-approved public reporting address is a pre-GA gate and is listed as open above. Until it is published, do not send credentials, private repository content, or exploit detail through an unapproved channel.

  • Security review pack

    This page, plus the repository

    The control list, the operator responsibilities and the open gates are all on this page. The deploy runbook, the proxy configuration and the Compose files live in the repository rather than behind a form.

  • Incident commitment

    Named in the pre-GA list

    An incident-response path with escalation, containment, customer communication and post-incident review is an operator responsibility today. It is stated as one rather than implied to be staffed.

Responsible disclosure

A public security reporting address is still required.

No owner-approved public security reporting address is currently documented. Do not send credentials, access keys, private repository content, or exploit details through unapproved channels.

Read the docs