Falsiflow is a local-first evidence workflow tool. It does not execute arbitrary project-config code, but it does read project files, evidence CSVs, source-file references, bundle archives, and generated reports. Treat those inputs as untrusted unless they come from a source you control.

Please avoid posting exploit details in public issues. Use the repository's private security advisory channel when available. If no private channel exists, contact the maintainers through the least-public project channel available and include only enough detail to reproduce the issue safely.

Treat a vulnerability in path handling, bundle or template-pack verification, source provenance, or packaging as security-sensitive even when it does not involve network access.

Useful reports include:

• a short impact summary
• affected Falsiflow version or commit
• operating system and Python version
• a minimal reproduction bundle, project config, or command
• whether source files, zip archives, or generated reports are involved

Security-relevant issues include:

• unsafe bundle zip extraction or path traversal
• incorrect SHA-256 or byte-size verification
• unsafe template-pack zip extraction or template substitution
• source-file provenance bypasses
• unexpected file writes outside requested output directories
• command behavior that marks blocked evidence as ready
• packaging issues that omit required templates or release documentation

Run falsiflow verify-bundle before trusting a received bundle. Do not treat a bundle as trustworthy just because it opens successfully; verification must check paths, hashes, byte sizes, copied source records, and unmanifested files.

Run falsiflow verify-template-pack before trusting a received starter template. Prefer falsiflow template-install for adoption: it verifies the zip, reruns template-check, and writes falsiflow_template_index.json before a template is reused. For repeatable adoption, generate a registry with falsiflow template-registry, lock an entry with falsiflow template-lock, and install from falsiflow_template_lock.json so the source zip byte count and SHA-256 are pinned. Treat registry source_url values as untrusted until the lock and install steps re-check their hashes. For distributed locks, run falsiflow template-attest and falsiflow verify-template-attestation; a template_attestation_verified report means the lockfile bytes and optional HMAC signature matched the expected subject. Use template-install --attestation ... --require-attestation when adopting templates from a signed lock. For team allowlists, create falsiflow template-policy, verify it with falsiflow verify-template-policy, and install with template-install --policy. For distribution to another team or machine, prefer falsiflow template-release, verify it with falsiflow verify-template-release, and install with template-install --release so the pack, registry, lock, attestation, and policy are checked together. Treat a release as untrusted if verification reports unsafe artifact paths, duplicate artifact paths, unmanifested files, hash mismatches, or a registry SHA-256 mismatch against the lockfile. Use verify-template-release --report-out to keep a Markdown review record alongside the machine-readable JSON report.

The active development version is checked by falsiflow release-check. Until the project has multiple maintained release lines, security fixes target the current release line.