Security Policy

Relevant source files

The following files were used as context for generating this wiki page:

• SECURITY.md
• VISION.md
• AGENTS.md
• README.md
• CONTRIBUTING.md
• crates/sploosh-parser/src/lib.rs
• scripts/check_prompt_budget.py

Sploosh is an AI-native programming language project currently in a pre-1.0 and spec-first phase. As there is no shipped language runtime or released compiler toolchain yet, the security policy focuses on the language specification, compiler bootstrap crates, and repository automation. The primary goal is to ensure that the design avoids "on-chain footguns" and that the early implementation of the lexer and parser remains robust against memory safety and injection issues.

The security model is integrated directly into the language design, prioritizing explicit behavior to minimize ambiguity for both human developers and AI coding agents. This includes built-in reentrancy guards and the strict isolation of actors to prevent shared-state bugs.
Sources: SECURITY.md:3-10, VISION.md:7-14, README.md:1-5

Language Security Architecture

Sploosh implements security through strict syntactic and semantic constraints. By limiting the ways operations can be expressed, the language reduces the surface area for common vulnerabilities.

Key Security Features

Feature	Implementation	Security Benefit
Reentrancy Guard	Default runtime flag for pub functions	Prevents unauthorized re-entry into contract state.
Actor Isolation	No shared mutable state; message passing	Eliminates data races and shared-state side effects.
Explicit Errors	Result<T, E> for all fallible operations	Prevents silent failures and unhandled exceptions.
On-chain Prohibitions	onchain mod compile-time checks	Rejects non-deterministic IO and floating-point math.
Checked Arithmetic	Default checked operations	Prevents integer overflow/underflow vulnerabilities.

Sources: VISION.md:83-98, README.md:30-45, SECURITY.md:70-75

On-Chain vs Off-Chain Security

The compiler enforces a boundary between native execution and blockchain targets. The onchain mod directive triggers a specialized validation pipeline.

The diagram shows how the compilation pipeline branches based on the module type to enforce environment-specific security rules.
Sources: VISION.md:53-58, README.md:46-50, crates/sploosh-parser/src/lib.rs:343-365

Vulnerability Reporting

The Sploosh project requires private disclosure for security-relevant issues. Public GitHub issues must not be used for reporting vulnerabilities.

Scope of Reports

• Compiler Crates: Memory safety, sandbox escapes, or injection in crates/.
• Language Spec: Unsound rules, silent data loss, or undefined behavior in docs/.
• Web3 Design: On-chain flaws like privilege confusion or storage layout issues.
• Supply Chain: Unsafe GitHub Actions, secrets exposure, or malicious dependencies.

Out of Scope: Feature requests, style nits, or parser bugs that do not have security consequences.
Sources: SECURITY.md:16-33

Disclosure Process

1. Contact: Email revenantpulse@gmail.com with the subject [SECURITY] sploosh.
2. Content: Include affected paths, impact assessment, and reproduction steps (PoC).
3. Alternative: Open a draft GitHub Security Advisory on the StreamDemon/sploosh repository.

Response Timeline

Step	Target Timeline
Acknowledgment	≤ 72 hours
Initial Triage	≤ 7 days
Fix / Mitigation	≤ 30 days (High/Critical)
Public Disclosure	Post-fix or by agreement

Sources: SECURITY.md:35-46, SECURITY.md:53-65

Technical Safety Enforcements

Input Validation and Parsing

The sploosh-parser implements strict validation for syntactic constructs that could lead to logic errors. For example, the "block-head restriction" prevents struct literals from being misinterpreted in control flow positions, reducing the risk of unintended code execution.

// crates/sploosh-parser/src/lib.rs:885-895
fn cond_expr(&mut self) -> Option<Expr> {
    let prev = self.no_struct_literal;
    self.no_struct_literal = true; // Restriction active for if/while conditions
    let result = self.expr(0);
    self.no_struct_literal = prev;
    result
}

Sources: crates/sploosh-parser/src/lib.rs:885-892, crates/sploosh-parser/src/lib.rs:1155-1175

CI/CD and Prompt Budget Security

Sploosh uses CI to enforce "Prompt Portability." This ensures the language remains simple enough for AI agents to reason about securely, preventing "hidden complexity" vulnerabilities.

• Core Budget: ≤ 5,600 tokens (cl100k_base).
• Web3 Budget: ≤ 1,500 tokens.

Sources: scripts/check_prompt_budget.py:15-20, CONTRIBUTING.md:79-85

Summary

The Sploosh Security Policy transitions the project from a spec-first design to a robust implementation by enforcing private vulnerability disclosure and prioritizing "safety-by-default" features like reentrancy guards and actor isolation. As the compiler matures (Phases 1-8), security focus will shift from specification soundness to implementation correctness across the four targets: Native, WASM, EVM, and SVM.
Sources: README.md:78-90, SECURITY.md:68-80