# 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.