Security readiness: publish a reporting policy and threat model, then track an independent review

[AminChirazi]

needs-human — this sets the security bar for a stable release and requires external coordination.

Readiness gap

Flowproof is an assurance tool: users rely on its containment, secret handling, forbidden-tool assertions and audit output when deciding whether an agent may touch production systems.

The repository has strong security-focused tests, but it does not currently publish a SECURITY.md, a supported-version/disclosure policy, or a consolidated threat model. There is also no independently scoped security assessment to distinguish self-tested claims from externally reviewed ones.

For a trust product, these are part of the product surface rather than administrative polish.

Threat model scope

At minimum, document:

• the local model proxy and upstream credential boundary;
• untrusted cassette content and deterministic re-emission;
• MCP stdio and HTTP stand-ins, including what is and is not prevented from executing;
• Linux seccomp egress containment and the non-contained behavior on other platforms;
• secret references, screenshots, reports and debug artifacts;
• flowproof capture, which deliberately binds an unauthenticated endpoint;
• HTML/report rendering of untrusted application and model content;
• subprocesses, child processes, timeouts and process-tree escape;
• package publication, binary provenance and dependency/supply-chain assumptions;
• customer-owned flows and evidence archives.

Acceptance criteria

• Add SECURITY.md with a private reporting route, supported versions, expected acknowledgement/remediation windows and advisory policy.
• Add a versioned threat model describing assets, actors, trust boundaries, abuse cases, mitigations, residual risks and explicitly unsupported guarantees.
• Map every public “it can’t” claim to its enforcing mechanism and test; map every “it didn’t” claim to its evidence boundary.
• Include safe-use guidance for capture endpoints, traces, reports and customer secrets.
• Define the minimum independent review scope required before v1.0 and select a reviewer outside the primary implementation path.
• Track findings to disposition; block v1.0 on unresolved critical/high findings unless a named human accepts and documents the residual risk.
• Publish a non-sensitive review summary and link any resulting advisories or fixes.