Security

This page is the public security policy for Termin: what the project defends against, what it does not, how to report a vulnerability, and the status of independent audits.

The SECURITY.md file in the compiler repository is the primary reference for the disclosure process. This page summarises it and adds the threat model and audit status.

# Reporting a vulnerability

Primary channel: SECURITY.md in the compiler repository.

Email: security@termin.dev.

What to include: a reproducible test case where possible, the affected version, the platform, and a description of the impact. Email is acceptable in plaintext for initial contact. If the report contains sensitive details, request an encrypted channel in your initial message and we will coordinate.

What to expect:

• Acknowledgment within 3 business days. A human response confirming receipt and opening a tracking channel.
• Triage within 10 business days. An initial assessment of severity and scope.
• Coordinated disclosure. A default 90-day window from acknowledgment to public disclosure, with earlier disclosure if a fix lands sooner and later disclosure by mutual agreement if the fix is complex.
• Credit in the changelog unless you request anonymity. A CVE is requested by the project once a fix is available.

Do not file a GitHub Issue for a suspected vulnerability. Use the private channels above.

# Threat model

Termin treats the application as a boundary. The scope of the runtime's defenses is bounded by what the runtime can see — requests arriving over HTTP, WebSocket messages, package files on disk — and the trust relationships the language declares.

# In scope

• Untrusted packages. Every .termin.pkg is untrusted input. The runtime validates the manifest, verifies SHA-256 checksums, validates the IR (intermediate representation — the compiled JSON artifact inside the package) against the published schema, and refuses to start on malformed packages.
• Untrusted user input. Identifiers flowing into queries are validated at every SQL boundary. Parameterized queries are used throughout — the language has no construct for assembling queries as strings.
• Cross-boundary data flow. Data moves between Boundaries only through declared Channels. Side channels, shared memory, and undeclared exports are not reachable from application code.
• Scope bypass attempts. Every operation is scope-checked; there is no code path in the reference runtime that reaches storage, state, Compute, Channel, or Presentation without passing through the access-control layer.
• Audit log integrity. Every modifying action is logged. Field values are not logged at the default audit level, so confidential data is not leaked through logs.

# Out of scope

• Attacks by the operator of the runtime. An administrator with filesystem access to the runtime's SQLite database can read and modify records directly. Termin enforces guarantees for applications running on the runtime; it does not prevent abuse by those who control the runtime. Defense against administrator abuse is a deployment concern — disk encryption, access control on the host, auditing of privileged access.
• Availability. The runtime does not guarantee any service level. Overload, crash, and deployment failures are deployment concerns.
• Compromised dependencies. A vulnerability in a library the runtime depends on is inherited by the runtime. Dependencies should be monitored and updated per normal security practice.
• Correctness of scope assignments. Termin enforces that scopes are checked. It does not enforce that your scope assignments are appropriate for your organization's policy.
• Correctness of business logic. An application can be structurally safe and still have incorrect business logic. Termin does not defend against requirements errors.
• Tier 3 custom provider code. Custom providers can do anything Termin does not structurally prevent. Review them as you would any external dependency.

The full enumeration of what Termin does not guarantee is on the guarantees page.

# Runtime hardening

The reference runtime is written in Python on top of FastAPI, SQLite (via aiosqlite), and Jinja2. Documented hardening:

• Parameterized queries throughout. No query string is concatenated from user input.
• Identifier validation at every SQL boundary. Table and column names derived from the IR are validated against the schema before they reach the database.
• No shell-outs. The runtime does not invoke subprocesses in any code path.
• No eval, no untrusted pickle. CEL expressions (Common Expression Language — the small expression sublanguage Termin uses for conditions and computed values) are evaluated by cel-python in a sandboxed interpreter. No Python eval or pickle.loads on untrusted input.
• Content Security Policy headers on HTML responses. Restrict script sources to the runtime's own origin.
• WebSocket channel names are not client-trusted. Subscription targets are derived from the IR, not from the client-provided channel name alone.

Passing the conformance suite is not the same as a code audit — see Audit status below.

# Audit status

No third-party security audit has been completed. A third-party audit is on the roadmap but has not been scheduled. Funding is an open question given the non-commercial posture of the project; candidate paths include grants, sponsored audits from security firms with pro-bono OSS practices, and community-funded campaigns.

When an audit happens, the scope, the firm, the findings, and the remediation status will be published on this page.

The conformance suite is the current evidence for Tier 1 behavioral claims. It tests the runtime's externally-observable behavior against the declared guarantees; it does not test the runtime's implementation code for memory-safety bugs, parser vulnerabilities, denial-of-service paths, or cryptographic implementation flaws. A runtime could pass every conformance test and still have a buffer overflow in its HTTP parser.

# SBOM (Software Bill of Materials)

An SBOM (Software Bill of Materials — a document enumerating every dependency, its version, and its license) in CycloneDX format is published for each tagged release of the compiler and reference runtime. It is included in the release artifacts on GitHub under termin-compiler/releases.

The .termin.pkg format itself includes a manifest with SHA-256 checksums for every file in the package — a per-application integrity manifest, distinct from the runtime's dependency SBOM.

# Well-known URIs

• /.well-known/security.txt — machine-readable pointer to this page and to security@termin.dev.

# Scope of this policy

This policy covers:

• The Termin compiler (repository termin-compiler).
• The reference runtime (included in the compiler repository under termin_runtime/).
• The conformance suite (repository termin-conformance).

It does not cover third-party runtimes, third-party providers, or applications built on Termin. Report vulnerabilities in those to the relevant maintainer.