YAZA Security Assurance Proposal

Status: Integrated proposal; implementation and operational commitments are tracked separately
Baseline review: 2026-10-28
Scope: YAZA compiler and CLI, generated C and native programs, API runtime, PostgreSQL clients, standard library, templates, editor tooling, CI, release artifacts, and supported targets.

Executive summary

YAZA has useful security controls in its current prototype: bounded HTTP and JSON parsing, request and connection limits, checked database parameter binding, explicit route authentication modes, safe error envelopes, filesystem-root APIs, secret types with explicit zeroization, compiler hardening flags, sanitizer harnesses, parser fuzzing, and a tested macOS API path. These controls protect particular code paths and configurations. They do not make the language, compiler, generated native binaries, or applications memory-safe or production-secure.

The source tree still emits C. Arbitrary YAZA programs run with the host user's privileges, and yaza test is not an operating-system sandbox. API object and tenant authorization, inbound TLS, Linux end-to-end evidence, a unified PostgreSQL security policy, package provenance, and a private vulnerability-reporting process are incomplete. Generated API route handlers and database calls execute on a bounded worker pool; the event loop owns sockets, health, metrics, and response writes. Blocking calls occupy workers until they return, cancellation is cooperative, and language-level async tasks and multi-worker scheduling remain unimplemented. If a handler remains active after the configured shutdown grace, the API process exits with failure rather than forcibly cancelling its thread. On macOS, the .env loader hardening and reduced child environment for Clang now pass focused checks within the local self-host bootstrap; the ordinary process, process_capture, and timeout APIs still inherit the parent environment unless callers choose an allowlist API.

The attached additions are incorporated below, with findings reclassified against the newer source and status files. Several claims in the attachment are stale or require reproduction. For example, the response writer now queues ordinary API responses and the scheduler already has deterministic tests; the reported 1,024-byte response-header limit is now 4,096 bytes. The Linux epoll listener-event mismatch has a source fix and a regression assertion in the native readiness harness. The harness passed locally on macOS under ASan/UBSan, but that exercises kqueue; Linux epoll and end-to-end API behavior remain unverified until the Ubuntu workflow and a Linux API smoke pass.

No finding in the attached additions is a confirmed CVE or a reproduced remote-code-execution exploit. This review did not run a penetration test or the Linux/API/PostgreSQL test matrix. A CVE is a public identifier for a disclosed vulnerability, not a certification that a product passed security testing. No process can guarantee that software has zero vulnerabilities. YAZA can instead define a bounded assurance profile and require repeatable evidence before making a claim or release.

2026-10-28 implementation evidence update: The complete macOS arm64 bootstrap now passes after environment hardening, including three self-hosted compiler stages, the 45-test YAZA language suite, sanitizer harnesses, 10,000 deterministic ASan/UBSan fuzz cases, API authentication and dotenv smokes, and the remaining local API checks. process_env, process_timeout_env, and process_capture_env now start children with only explicitly supplied entries; the process test confirms exact captured variables, no ambient secret leakage, timeout termination, rejection of dynamic-loader and unsafe PATH entries, and bounds on argument/environment list sizes. JSON diagnostic checks confirm that explicitly allowlisted diagnostic metadata still works. Legacy process APIs still inherit the parent environment. For the shared-token overlap change, the API route-auth smoke was additionally run normally and under ASan/UBSan. These results apply to this macOS checkout and toolchain only. Hosted Linux CI, remote TLS, sandbox escape tests, and independent review remain open.

2026-10-28 repository audit scan: I reran ./dist/yaza audit --security --format json from the repository root for this update. The latest run scanned 358 relevant files and returned 15 heuristic findings (five possible-secret matches and ten TLS-verification matches); candidate values were omitted, and exit status 1 means findings were reported. Context review confirmed that the compiler/native_cli.yz candidate is the analyzer's own SARIF rule description, not a credential. The remaining possible-secret matches are synthetic test credentials; the TLS matches are in test fixtures or local-development .env.example files. They do not establish a production secret or production TLS downgrade. Keep test credentials synthetic and local plaintext examples explicitly loopback-only. The analyzer has no dependency-advisory, taint, or runtime analysis and can miss or misclassify findings. Fifteen is not a CVE count, and this scan cannot establish that the repository is clean. This workspace has no Git HEAD commit and the YAZA tree is uncommitted/untracked, so the result is tied to this workspace snapshot rather than an immutable release revision. No smoke, sanitizer, fuzz, or API suites were run for this documentation/status update.

2026-10-28 security status snapshot: Appendix H records 2 of 18 sections as implemented, 11 as partial, 4 as not implemented, and H.18 as an accepted design direction whose implementation is pending. These are section labels, not a weighted security score. The candidate register contains 13 P1-ranked follow-ups; that count includes incomplete evidence and product gaps, not 13 confirmed vulnerabilities. This review has not reproduced an RCE or confirmed a P0 issue, which does not establish that none exists. The latest recorded macOS evidence includes stricter .env handling, explicit child-process environments, exact Host allowlisting, stronger shared-token defaults and a token generator, fatal UBSan fuzzing, and HTTP 405 Allow headers. The most consequential release gaps remain the absence of an OS sandbox for untrusted projects, incomplete memory-safety and secret-lifetime guarantees, missing object/tenant authorization and inbound TLS, synchronous route/database work, incomplete Linux end-to-end evidence, supply-chain provenance, and an active private vulnerability-reporting process. The audit was rerun for this snapshot; no test suites were rerun in this documentation update, and earlier test/platform limits remain authoritative. The current workspace does not have an immutable Git commit, so this status cannot yet be treated as release evidence.

1. Scope, assumptions, and evidence

1.1 Scope and exclusions

The assessment covers the YAZA implementation and its documented release path. Application-specific authorization rules, the host operating system, PostgreSQL deployment, reverse proxy, cloud account, and operator configuration remain part of the security boundary.

This proposal is not a source audit by an independent security firm, cryptographic review, penetration test, certification, or legal assessment. Existing test results cited here are repository records; they were not all rerun for this document. Source observations must not be represented as reproduced vulnerabilities.

1.2 Evidence labels

A closure record must include the finding ID, affected and fixed versions, source revision, OS and architecture, compiler/tool versions, reproduction or test command, test output or CI URL, remaining limitations, reviewer, and closure date. Release-specific evidence expires when the relevant source, dependency, toolchain, or target changes.

1.3 Risk priorities

These are engineering priorities, not CVSS scores.

No P0 is confirmed by this review. That means only that the current review did not confirm one; it does not establish that none exists.

1.4 Review of the supplied security additions

The supplied yaza-security-proposal-additions.md is a useful source-review checklist. Its author labels the candidates as unreproduced, and this proposal preserves that distinction. The current repository and recorded test evidence change several of its conclusions:

Other source observations in the additions remain candidates or design risks unless a test or controlled reproduction is linked. In particular, synchronous route/database work, absent object/tenant authorization, incomplete memory-safety semantics, lack of an OS sandbox for untrusted projects, absent inbound TLS, PostgreSQL policy drift, and missing release provenance/private vulnerability intake remain substantial gaps. The full candidate register below is the maintained record; this reconciliation does not promote an unverified observation to a confirmed vulnerability.

2. Threat model

2.1 Assets

• YAZA source, compiler, generated C, native executables, and release artifacts.
• Application records, PostgreSQL credentials, API tokens, signing/provenance material, and personal data.
• Developer and CI files, environment variables, build tools, and process privileges.
• API availability, integrity of HTTP/database operations, and correctness of generated API documentation.
• Package identity, lock data, dependency versions, editor extension, and update path.

2.2 Actors

2.3 Trust boundaries

1. .yz source and project metadata enter the compiler, C generator, and native build tools.
2. An HTTP peer's bytes pass through framing, parsing, authentication, route policy, application handlers, and database access.
3. YAZA programs access host files, environment, network, and child processes through native runtime calls.
4. PostgreSQL credentials and data cross a client, network, TLS provider, server, migration, and backup boundary.
5. Dependencies and build artifacts cross the local checkout, CI identity, release pipeline, installer, and user's machine.
6. macOS evidence does not establish Linux, Windows, WASI, browser, edge, Android, or iOS security.

3. Existing controls and their limits

The following inventory summarizes controls documented in the current source/status files. It is not a fresh test report.

3.1 Source review traceability

These are direct source observations, not exploit confirmations. They identify the boundaries that the test record must cover and the limits that should remain visible in product claims.

No source-only row above is a confirmed remotely exploitable vulnerability. A finding becomes confirmed only after a controlled reproduction or a narrowly scoped test establishes the claimed behavior and impact.

4. Candidate finding register

Findings below retain IDs from the supplied additions. Statuses are deliberately conservative: source review is not a vulnerability reproduction. “Confirmed behavior” means a code/configuration fact, not a confirmed exploit.

4.1 HTTP runtime and availability

4.2 Memory, secrets, environment, and child processes

4.3 Cryptography and authentication helpers

4.4 Compiler, build, and supply chain

4.5 PostgreSQL and data protection

4.6 Fuzzing, CI, scheduler, and templates

4.7 Current trend and future risk horizon (reviewed 2026-10-28)

The trend assessment combines YAZA's actual boundaries with current OWASP, CISA, and NIST guidance. “Future” rows are conditional projections, not current vulnerabilities. The OWASP Top 10 is risk-awareness guidance, and its data necessarily lags some newly emerging attack patterns.

These risks should be re-ranked whenever YAZA adds a package manager, remote build service, outbound HTTP client, autonomous agent, extension distribution channel, multi-worker server, or new target. A trend report does not establish that a particular exploit exists in YAZA.

5. OWASP API Security Top 10 mapping

The API mapping is a separate reference from OWASP's general web application Top 10. The current general baseline is OWASP Top 10:2025 mapping; the API-specific baseline remains OWASP API Security Top 10:2023 mapping. The 2021 mapping is retained as a historical record. These categories are review prompts, not a claim of OWASP certification.

6. Security architecture requirements

These are proposed implementation requirements for the accepted YAZA RFC direction.

1. Language and native boundary: Define checked arithmetic, bounds, nullability, initialization, ownership, lifetimes, destructors, unsafe, and FFI contracts before making memory-safety claims. Audit generated C and runtime C as part of the trusted computing base.
2. Failure handling: Recover only typed, defined failures at request/task boundaries. A request panic must release request memory and leases and return a generic 500 while the server continues. Never continue after allocator corruption, a native signal, or unknown process state.
3. HTTP and async execution: Keep all I/O and queues bounded. Finish the YAZA-owned async scheduler with cancellation, deadlines, fairness budgets, and a bounded blocking pool. Database, DNS, filesystem, and user handlers must not stall the event loop.
4. Authentication and authorization: Keep public access explicit. Use principals and policy checks at function, object, tenant, and property levels. Shared secrets are bootstrap/service credentials, not an authorization model. Provide secure generation, overlap rotation, revocation, and audit-safe use.
5. Transport security: The API runtime remains behind a verified TLS reverse proxy until inbound TLS is fully reviewed. Trust forwarding headers only from explicitly configured proxy peers. Remote database TLS must fail closed on invalid CA or hostname.
6. Database safety: Bind every external value; raw SQL must be static trusted source. Use least-privileged application roles, separate migration roles, statement/lock/idle limits, bounded pools, and cancellation-safe transactions.
7. Secret handling: Minimize secret copies and lifetime; never expose credentials in errors, logs, command lines, OpenAPI, Postman, or diagnostics. Do not invent cryptographic primitives. Use reviewed OS/provider implementations and test every platform.
8. Filesystem and process capabilities: Treat source projects as executable programs. Keep path APIs rooted and no-follow. Child processes use explicit executable paths, bounded arguments/output/time, and allowlisted environments.
9. Build isolation: Running untrusted source or tests requires a per-job OS sandbox. A temporary working directory alone is not a sandbox. Deny network and host secrets by default; mount only required inputs and outputs.
10. Supply chain: Pin dependencies and CI actions, produce an SBOM and provenance for each release, verify artifact integrity, monitor advisories, and keep release credentials separate from build/test jobs.
11. Observability and privacy: Emit bounded structured events with request IDs, not request bodies or tokens. Provide explicit classification/retention controls; log redaction is a secondary defense.
12. Target-specific claims: A target is supported only after compiler, runtime, crypto/TLS, API, sandbox, and release evidence passes on that OS/architecture. Never inherit macOS results as Linux/mobile/WASM proof.

7. Secure deployment baseline

Until the runtime enforces these controls itself, deployment guidance and templates should require:

8. Verification and release gates

Every result must be tied to a source revision, build toolchain, platform, and configuration.

Proposed assurance baselines: Use the stable OWASP ASVS 5.0.0 as a version-pinned checklist for the YAZA API release profile, targeting applicable Level 2 requirements and documenting every exclusion. This is a verification target, not an ASVS certification or a claim that the current API meets Level 2. Use NIST SSDF SP 800-218 v1.1 to organize secure development, build protection, verification, and vulnerability response. For build provenance, evaluate the SLSA v1.2 specification and select a build track/level only after the release pipeline emits and verifies the required attestations. These frameworks complement one another; none substitutes for source review, adversarial tests, platform-specific evidence, or incident readiness.

8.1 RCE and vulnerability-assurance objective

The engineering objective is to reduce the likelihood and impact of remote-code-execution and other vulnerabilities through independent controls at each trust boundary. It is not a promise that YAZA will pass every future security review or remain free of CVEs. A release may claim only the exact platform/profile for which current evidence exists.

Before making a production security claim, the release evidence must show all of the following for the claimed profile:

1. Compiler boundary: adversarially test lexer/parser inputs, identifiers, route metadata, string literals, and generated C; use a safe C-literal encoder; compile generated output with warnings and sanitizers; and retain minimized regressions for every confirmed failure.
2. Build and test boundary: never treat a temporary directory as isolation. Run untrusted builds/tests in an OS-enforced sandbox with no host secrets, default-deny network, read-only inputs, bounded writable output, and CPU, memory, process, and time limits. Until this exists, compiling or running untrusted YAZA projects is explicitly unsafe.
3. Runtime/API boundary: require bounded parsing and queues, request deadlines, denial-by-default authentication/authorization tests, SQL parameter binding, verified TLS at the documented boundary, and saturation/recovery tests. One HTTP parser smoke or one sanitizer run is not sufficient.
4. Native and dependency boundary: review C runtime and FFI as trusted computing base; run memory/undefined-behavior instrumentation and fuzzing; inventory native and source dependencies; monitor advisories; and produce a verifiable SBOM and build provenance for each release.
5. Response boundary: maintain a private, monitored vulnerability-reporting route; assign triage ownership; reproduce and prioritize reports; issue fixes/advisories for confirmed vulnerabilities; and exercise credential and release-key incident playbooks.

An open P0 or P1 finding blocks the affected release profile unless the feature is disabled or an explicitly approved containment is documented. Passing these gates is evidence of due diligence for the tested revision and configuration; it is not proof that no unknown vulnerability exists. CVE assignment is handled only after a vulnerability is confirmed and follows the applicable CNA/advisory process.

The configured Linux runtime-security workflow currently covers C runtime sanitizers and narrow parser fuzzing. Both fuzz modes now fail on UBSan findings, and the regression pipeline tests that behavior; a local 10,000-case deterministic ASan/UBSan run passed. It is valuable but is not the full Linux compiler/API release gate. Hosted execution and branch protection must be verified before calling those gates enforced.

9. Vulnerability disclosure, CVEs, and incident response

9.1 Intake and coordinated disclosure

Before public distribution, establish a working private report channel: enable private vulnerability reporting for the public repository or publish a monitored security contact. A SECURITY.md file without an active contact or enabled private route is not sufficient. Assign a triage owner and backup, track private reports, preserve evidence, and avoid public issue filing before a fix is coordinated.

Proposed service targets, not yet commitments:

These targets must not be published as an operational promise until the owner, channel, and release process are staffed and exercised.

9.2 CVE and advisory handling

For a confirmed issue, identify affected versions and configurations, assign impact and severity, create a regression test, coordinate a fix and disclosure date, publish patched versions and upgrade guidance, and preserve a machine-readable advisory. Request a CVE ID through an eligible CNA or supported advisory platform when the issue meets that process. A CVE ID identifies a vulnerability; it does not mean YAZA has passed a security audit. Do not label an unverified source-review candidate as a CVE.

9.3 Incident playbooks

• API/database credential exposure: revoke or rotate, inspect access logs without disclosing the secret, identify affected records, notify the application owner, and deploy the replacement through a secret manager.
• Release key or CI compromise: disable publishing, revoke affected credentials, identify artifacts by provenance/SBOM, replace them, and publish an advisory.
• Dependency compromise: locate affected releases from the SBOM, pin/upgrade, rebuild in a clean environment, and publish affected version ranges.
• Compiler/runtime vulnerability: reproduce on a supported target, create a minimized regression, assess generated native programs and downstream applications, patch/backport, and coordinate disclosure.
• Data incident: contain access, preserve evidence, assess retention/backups, and follow the application owner's legal notification obligations.

9.4 Privacy

YAZA should provide mechanisms for application owners to classify fields, minimize collection, redact logs by construction, set retention/deletion policies, and protect backups. The application owner remains responsible for applicable privacy law and user notices; this proposal is not legal advice.

10. Implementation order

The product priority remains API first. Security work should proceed alongside API delivery and act as gates on claims and releases.

Recommended project decisions

These defaults resolve the open questions in the additions without claiming implementation:

• Use the YAZA-owned structured scheduler and a bounded blocking pool; retain synchronous APIs only as explicitly blocking operations.
• Treat request-level typed failures as recoverable; fail the process for corruption or unknown native faults.
• Make pure-YAZA std/pg the intended PostgreSQL path after TLS and live-server conformance; keep any compatibility client behind the same tests until it can be removed.
• Keep API bind loopback by default. Require a strong generated credential and explicit route policy for non-loopback exposure; use a verified TLS proxy until inbound TLS is release-ready.
• Do not trust forwarded client-IP/host headers without explicit proxy/host allowlists.
• Keep the macOS package unsigned if that remains the distribution choice, but provide checksum and provenance; never describe those as Apple publisher signing or notarization.
• Do not run untrusted compiler/test input without OS-level isolation.

11. Release claim criteria

Before a YAZA profile is described as production-ready or secure for sensitive data:

1. The exact profile, OS/architecture, compiler/runtime version, and deployment boundary are named.
2. No open P0/P1 issue affects that profile without a documented, approved containment measure.
3. Compiler/runtime memory and unsafe boundaries have an implementation contract and independent review; sanitizer/fuzz results are current.
4. API authentication and object/tenant authorization tests pass; TLS, database cancellation, and resource-exhaustion tests pass on the claimed target.
5. Untrusted builds/tests run in a verified OS sandbox.
6. Dependencies, SBOM, provenance, and release artifacts are reviewable and verifiable.
7. A private vulnerability channel and incident response process are active.
8. Limitations and residual risks are published. No claim says “zero CVEs,” “unhackable,” or “guaranteed secure.”

12. References

Repository evidence

• Appendix H security implementation status
• Appendix G implementation status
• YAZA threat model
• OWASP Top 10:2025 mapping
• Historical OWASP Top 10:2021 mapping
• OWASP API Security Top 10:2023 mapping
• API completion roadmap
• RFC 0002 — memory ownership and unsafe
• RFC 0003 — modules, packages, and supply chain
• RFC 0005 — structured concurrency and HTTP runtime
• RFC 0006 — secure standard library and crypto
• RFC 0007 — diagnostics, testing, and release evidence
• RFC 0008 — cross-targets

External references

• OWASP API Security Top 10:2023
• OWASP Top 10:2025
• OWASP Top 10 for Agentic Applications:2026
• OWASP Top 10 for LLM Applications:2026
• CISA Secure by Design Alert — Eliminating Buffer Overflow Vulnerabilities
• NIST Post-Quantum Cryptography
• OpenSSF Compiler Options Hardening Guide for C and C++
• NIST Secure Software Development Framework, SP 800-218
• OWASP Application Security Verification Standard 5.0.0
• SLSA specification v1.2
• CISA Vulnerability Disclosure Policy template
• GitHub private vulnerability reporting
• GitHub coordinated disclosure
• CVE Program overview
• CVE Program CNA rules
• RFC 9110 — HTTP Semantics
• RFC 9112 — HTTP/1.1
• RFC 7677 — SCRAM-SHA-256

← Kembali ke semua dokumentasiVersi dan status rilis →