YAZA Security Threat Model

Version: 1.2 Reviewed against repository state: 2026-10-28
Scope: YAZA compiler and CLI, generated native programs, the API runtime, PostgreSQL client, local build/test workflow, and declared target status.

This document records the current security boundary and the work still required before YAZA can make production-safety claims. A control is considered present only for the code path and platform named here; a test on macOS is not evidence for Linux, Windows, WebAssembly, or mobile.

For the proposed risk register, current security trends, and phased security work plan, see the YAZA Security Assurance Proposal. The proposal does not replace this evidence-based threat model.

2026-10-28 review note: The updated proposal incorporates the supplied source-review candidates, current JWT/Host policy, source traceability, and a trend/future-risk horizon. The Linux epoll listener event is a high-priority source-level candidate with a source fix and regression assertion, not a reproduced exploit; Linux API end-to-end behavior remains unverified. No claim of zero vulnerabilities or CVE-free status is made.

2026-10-28 verification note: Fatal UBSan is now enabled in both fuzz build modes and is checked with a signed-overflow probe. The local deterministic macOS sanitizer fuzz run passed 10,000 mutations over the six-seed corpus; hosted Ubuntu/libFuzzer remains unverified. The current general web-risk mapping is OWASP Top 10:2025, with API risks mapped separately to 2023.

2026-10-28 child-process update: process_env, process_timeout_env, and process_capture_env now provide explicit child-environment APIs with dynamic-loader variable rejection and absolute, traversal-free explicit PATH values. The process test and runnable example pass on macOS arm64. Legacy process APIs still inherit ambient environment, and child execution is not sandboxed; the new variants reduce environment leakage but do not make untrusted code safe to run.

Security goals and assets

Actors and trust boundaries

flowchart LR
    Client[Untrusted HTTP client] --> Parser[Bounded HTTP and JSON parser]
    Parser --> App[Generated API and YAZA runtime]
    App -->|Bound parameters; verified TLS for remote peers| DB[(PostgreSQL)]
    Source[Project source and manifests] --> Compiler[YAZA compiler and generated C]
    Compiler --> Build[Clang and native build tools]
    Build --> Program[Native executable]
    Env[Environment and local files] --> Program
    CI[CI and release identity] -. provenance/signing not implemented .-> Build

The compiler, generated C, runtime helpers, Clang, and the host OS form one native execution boundary. Neither yaza check nor yaza test is a sandbox for hostile projects. The API parser and typed validation are separate boundaries from controller code; database parameter binding protects only the APIs that use the bound-parameter path.

Abuse cases and current mitigations

Target and release status

Release gates and maintenance

Do not describe YAZA as memory-safe, production-ready, or supported on a target based on this threat model. Before a stable release, the project still needs at least source-level ownership and broader safety evidence, a maintained dependency/provenance process, hosted native CI for every claimed target, successful remote TLS integration tests, a real vulnerability-reporting contact and response process, and independent security review. The detailed gates remain in Appendix H and RFC 0007.

Re-review this model whenever the compiler/runtime boundary, HTTP/database behavior, dependency mechanism, release process, or supported target set changes; also review it before each stable release and at least annually. Update the abuse-case table with test links when controls change. If evidence is absent or platform-specific, retain the limitation instead of generalizing the claim.

← Kembali ke semua dokumentasiVersi dan status rilis →