Do not open a public issue for a security report. Vulnerability reports go privately to:

📧 qwerfunch@gmail.com

Expect an acknowledgement within 7 days. If the report is reproducible and in-scope, the maintainer will work with you on a coordinated disclosure timeline. If it is out-of-scope or duplicate, you will hear back with an explanation.

The kinds of reports that belong here:

• A reproducible way to bypass the anti-self-cert guard so that LLM- or tool-authored evidence alone clears Iron Law stage_4. This is the project's structural integrity invariant; circumventing it is treated as the highest-priority class of report.
• A reproducible way to corrupt the audit log (.cladding/audit.log.jsonl) or events log such that an external auditor cannot reconstruct the lifecycle of a feature.
• A way to make a drift detector silently miss a real spec/code/test mismatch (false-negative). False-positives are bugs; false-negatives are security-adjacent because they erode the falsifiability claim.
• Credential or secret exposure in the toolchain (e.g. src/stages/secret.ts failing to redact a known secret pattern).
• Arbitrary code execution through any CLI verb (clad init, clad work, clad drive, clad sync, clad check, clad serve, …) against an untrusted spec or workspace.

clad serve exposes cladding as an MCP server (v0.2.24+). The following are structural invariants, not preferences — a regression on any of these is a security issue and belongs in a private report:

• No arbitrary shell execution from MCP tools. Every tool registered on src/serve/server.ts delegates to a typed cladding function (loadSpec, runDrift, readEvidence, log readers). None of them shells out, spawn a process, or compile arbitrary user-supplied code. A future tool that needs to execute anything must do it through a constrained, audited interface — never via child_process.exec of client-supplied strings.
• Read-only by default. v0.2.24 ships four read-only tools (clad_list_features, clad_get_feature, clad_run_check, clad_get_events). A future write-capable tool MUST require an explicit mutating: true flag in its registration metadata and MUST land a human-pass audit entry in .cladding/audit.log.jsonl for every invocation.
• Sampling responses pass through anti-self-cert. When the drive loop dispatches through McpSamplingTransport (v0.2.25+), the reviewer-vs-author identity barrier (F-049 AC-086) still applies — a host whose client returns the same identity for specialist and reviewer dispatches MUST halt with HUMAN_REQUIRED. The MCP boundary is not a bypass.
• Audit notifications are advisory. notifications/resources/updated for cladding://audit (v0.2.25+) is a client-cache-refresh hint, not a substitute for the file-level audit log. The audit log on disk remains the authoritative chain even if every notification is lost.

• Drift findings that surface a legitimate spec/code mismatch (these are the tool working as designed — open a regular issue).
• Bugs in third-party toolchain binaries (tsc, eslint, vitest, madge, secretlint, language toolchains). Report those upstream.
• Hardening requests not tied to a concrete vulnerability (open a regular feature request).

While in 0.x, only the latest minor release receives security fixes. Once 1.0.0 ships, the supported window will be codified in GOVERNANCE.md.