adminandClaude Sonnet 5
2902a26bac
* docs: full accuracy overhaul, grounded claim-by-claim in real code Every doc in this repo (CLAUDE.md, README.md, SECURITY.md, docs/*.md) was audited and rewritten by a multi-pass process: independent rewrite per cluster, adversarial re-verification of that rewrite against the actual code, then a final cross-doc consistency pass — each stage re-checking claims against the repo directly rather than trusting the previous stage. Two corrections matter most: 1. docs/ICEBERG_WRITE_BOUNDARY.md, docs/11-lakehouse-write-plan.md, and docs/P0_QUERY_SOURCE_FLOW.md asserted src/services/quality-check-service.ts, quality-report-service.ts, src/data-platform/services/catalog-service.ts, and sql/002_p0_dataset_quality.sql/sql/003_*.sql as real, tested code. git log --all across every branch shows zero commits for any of these paths, ever. 0pt's data-quality/QA enforcement does not exist in code. Corrected everywhere, with a new docs/P0_DATASET_QUALITY_FLOW.md added as an explicit target-spec (not-yet-built) replacement. 2. github.com/sax3l/0pt (this repo) and git.siax.io/sax3l/0pt (Gitea) are two diverged remotes sharing part of the same history (services/api/ workers/adaptive_router.py is byte-identical between them). Gitea's main independently accumulated a WAF-bypass/proxy-rotation scraper stack in three 2026-07-13 commits, since removed via a Gitea PR; GitHub's main never had it. Which remote is canonical/deployed is unresolved — flagged consistently across the corpus, not decided here. Also newly and consistently documented: the tenant_id/project_id-read-from- client-body gap on the P0 lakehouse/rate-policy/source-query routes (no auth/session system exists anywhere in this repo yet); that every CL0UD/ N0D/AUD0/ST0RE platform client is real but mock-only (zero process.env reads for any of their *_URL vars); that two P0 mutation routes (lakehouse/mappings, sources/rate-policies) always fail over HTTP today because their prerequisite entity can never be created via any route; a schema bug in sql/004 (FK references to opt_datasets/opt_sources, which don't exist); and that 0pt.app's live deployment was independently confirmed (curled this pass) to be running this exact codebase with DATABASE_URL/REDIS_URL unset in production. New file: docs/12-edge-capability-api.md — the edge-native P0 TypeScript capability contract (app/api/0pt/*, /api/screen, /api/ai/parse), previously undocumented and distinct from docs/04-api.md's FastAPI-engine-only scope. Verified before commit: tsc --noEmit clean; vitest run 88 passed, 1 todo, 0 failures (13 files) — docs-only change, no source touched. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * docs: reflect PR #5's lakehouse-mapping-registry + status-code fixes Follow-up to keep docs/12-edge-capability-api.md accurate once both PRs land: fix/0pt-full-bug-hunt (#5) fixed the shared-instance bug in the lakehouse mapping routes and added proper status-code mapping to the document extraction route. This doc was written against the pre-fix state in the same pass that added it, so it needs the same correction. Does not claim the lakehouse write path fully works now -- the deeper dataset-registration gap (no route ever calls DatasetService.registerDataset) is unchanged and still blocks it end-to-end; only the shared-instance half of the bug is fixed. --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
3.6 KiB
3.6 KiB
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:
- No authentication or tenant-isolation system exists in this repo yet.
The only gate in front of any route is a
DEV_LOGIN_KEYdev-login scaffold (app/api/auth/login/route.ts) — there is no session-to-tenant binding.app/api/orders/route.ts'sGEThandler carries the literal comment// GET /api/orders — list (org scoping added with auth)., confirming this directly. As a consequence, the P0 data-platform routes under/api/0pt/*(lakehouse/mappings,sources/rate-policies,sources/[sourceId]/query) andsrc/services/document-capture-service.tsaccepttenant_id/project_idfrom 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 pending real auth (Phase 3,docs/09-build-plan.md), not an intentional design. Do not treat this repo as tenant-isolated until that lands. - Beyond that specific item, 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.