0pt/SECURITY.md

Security Policy

0pt (SIAX Core Platform: Data OS) is proprietary software operated by SIAX Technology AB. This document explains how to report a suspected security vulnerability.

Reporting a vulnerability

Do not open a public GitHub issue for a suspected security problem.

Email: security@siax.io (fallback: simon@siax.io)

Include, if possible:

• A description of the issue and the impact you believe it has.
• Steps to reproduce, or a proof-of-concept request/response.
• The route, endpoint, or component affected.
• Whether the issue is already publicly known or exploited.

Response expectations

• Acknowledgement: within 2 business days.
• Initial triage and severity assessment: within 5 business days.
• Remediation timeline: communicated after triage, based on severity. Confirmed high/critical issues are prioritized ahead of other work.

We will keep you informed of progress until the report is resolved and, where appropriate, credit you in internal release notes (no public bug bounty program exists at this time).

Scope

In scope:

• The 0pt application and its API routes at 0pt.app.
• The 0pt engine/orchestrator services in this repository.
• Infrastructure-as-code and CI/CD configuration in this repository.

Out of scope:

• Third-party services and dependencies not maintained in this repository (report those to the respective vendor).
• Denial-of-service testing, spam, or social engineering against SIAX staff or customers.
• Automated scanning that generates excessive load against production systems without prior coordination.

Note: github.com/sax3l/0pt (this checkout's origin) and git.siax.io/sax3l/0pt (Gitea) are two diverged remotes that share part of this codebase's history — see README "Known issues" for what's known and what isn't about the relationship between them. Which one is deployed to 0pt.app is currently unconfirmed; if your finding is remote-specific, say which remote/branch you tested against.

Known, already-tracked gaps

The following are not news to us — they are open, named gaps as of this pass, not secrets, and reporting them again mainly helps confirm priority rather than surfacing something new:

• Zitadel bearer verification exists in code (fail-closed), but the deployed instance still answers /api/0pt/* anonymously (gap S1). src/auth/zitadel.ts
  • middleware.ts implement real JWKS-based verification with a fail-closed default (assertAuthConfigSafe() refuses AUTH_ENFORCE=false in production), yet a live probe (2026-08-10) got HTTP 200 without any token. Root cause is unconfirmed — do not treat the public instance as authenticated until an anonymous request receives 401. Additionally, no handler reads the verified tenant headers (x-0pt-verified-tenant): the P0 routes under /api/0pt/* (lakehouse/mappings, sources/rate-policies, sources/[sourceId]/query, documents/capture) accept tenant_id/project_id from the client-supplied request body or query string rather than from a server-bound session — a violation of this platform's own tenant-isolation rule (tenant_id must never be trusted from client input). This is an open, prioritized gap (BACKLOG P0-1/P0-2), not an intentional design.
• The non-/api/0pt API surface has no authentication at all. Orders, admin metrics, payments (including the escrow release that flips an order to delivered), subscriptions, uploads and DB-grant endpoints are unprotected in code (live-verified 200 anonymously on /api/orders and /api/admin/metrics).
• The WAF-bypass scraper stack is kept deliberately. services/scrapers/* (waf_bypass.py: FlareSolverr, Tor, cloudscraper, curl_cffi, proxy rotation, fake identities) and services/infra/docker-compose.data-stack.yml (flaresolverr/tor containers) contradict this repo's own compliance docs. A cleanup PR that surgically removed this stack (PR #7, verified clean, 128/128 tests) was closed unmerged by the account owner. The account owner, Simon Axelsson, was asked directly via an interactive decision prompt on 2026-08-11 whether to keep or remove this code, and explicitly chose to keep it. No business or legal justification beyond "keep it" was recorded — none is invented here. This is a narrow, scoped exception for the existing 0PT/0pt-motor sourcing engine; it does not change CLAUDE.md §1's general anti-evasion policy, which remains in force as written unless/until the account owner says otherwise. Out of scope for deletion — see docs/compliance/GOLDEN-STANDARD-REPORT.md control C6.
• Beyond those items, other authentication gaps on internal API routes may still exist and are tracked internally pending an intentional, reviewed fix; reporting any you find is still welcome and helps confirm priority.

Disclosure

Please give us a reasonable opportunity to investigate and remediate an issue before any public disclosure. We aim to coordinate disclosure timing with reporters wherever possible.