Security Policy

1. Reporting a vulnerability

Do not open a public issue. Security reports must stay private until a fix ships.

Machine-readable contact details, including the official security@ address and policy expiration, are published at /.well-known/security.txt per RFC 9116.

1. Email security@opensatchel.dev with:
   • A description of the vulnerability and its impact.
   • Steps to reproduce, including any test PDF or fixture file.
   • The version (or commit SHA) you tested against.
2. You will receive an acknowledgement within 72 hours.
3. We will provide a fix timeline within 7 calendar days of triage.
4. Critical vulnerabilities (remote code execution, data exfiltration, signature bypass) are targeted for a patch within 14 calendar days. Non-critical issues are scheduled for the next release.
5. Once the fix ships, we will credit you in the release notes — unless you prefer to remain anonymous.

2. Supported versions

Only the latest release receives security fixes. We do not back-port patches to older minor versions.

3. Scope

The following are in scope for security reports:

• The Open Satchel desktop application (Tauri shell + WebView frontend)
• The Rust PDF engine
• Cryptographic operations: AES-256 encryption, RSA/ECDSA signing, PKCS#11 hardware-token integration, LTV embedding
• The MCP test server (developer-machine only — relevant if it exposes a local attack surface)

Out of scope:

• Third-party dependencies with their own security policies (pdfjs, pdf-lib, Tesseract.js, Fabric.js, lopdf, etc.). Report those upstream; we update our pinned version once a fix is available.
• The marketing site or documentation content.
• Denial-of-service via malformed PDFs that cause high CPU or memory usage but no code execution — tracked as bugs, not security issues.

4. Disclosure policy

We follow coordinated disclosure:

• Reporters may publish details 90 days after the initial report, or once a fix is released — whichever comes first.
• We will not pursue legal action against researchers acting in good faith under this policy.
• We ask that you do not access, modify, or delete data belonging to other users during testing.

5. Security architecture

Open Satchel is a local-first desktop app. The primary security properties:

• No network egress by default. The only opt-in network calls are RFC 3161 TSA timestamping and OCSP/CRL lookups during PDF signing, both routed through an allow-listed Rust HTTP client. See Privacy for the complete network table.
• No telemetry, analytics, or update server.
• No accounts or authentication server. The app inherits the OS user identity.
• Source available for audit. Buyers can build from source and verify the binary matches the audited code.
• AES-256 (PDF 2.0 R=6) encryption for document protection.
• PKCS#11 hardware-token signing for non-exportable private keys.
• True content-stream redaction — redacted text is removed from the PDF, not painted over.
• Ed25519 commercial license signing. Commercial license keys are JWTs signed with an Ed25519 private key held outside both the desktop and site repos. The public verification key is embedded in the desktop binary, so license validity is checked entirely offline — Open Satchel never phones home to confirm a license.
• Reproducible supply chain. The Rust engine pins all crates by exact version and verifies checksums against Cargo.lock. Desktop builds are produced from tagged Git commits on hosted CI. An SBOM (CycloneDX) is generated per release; procurement teams may request it at security@opensatchel.dev.

6. Compliance posture

We aim for honest disclosure rather than checkbox claims. Open Satchel does not currently claim:

• HIPAA compliance (we are not a Covered Entity or Business Associate, do not sign BAAs as a standard term, and do not store PHI on our infrastructure)
• SOC 2 Type I or II
• FedRAMP / StateRAMP authorization
• FIPS 140-2/3 validation of the bundled cryptographic primitives
• PCI DSS scope reduction — payment data is collected and tokenized by Paddle (our Merchant of Record); we never receive cardholder data
• ISO 27001 / ISO 27701 certification

What we do provide for buyers in regulated industries: the local-first architecture above (no cloud egress, no telemetry, no account server), the published Privacy and docs/THREATMODEL.md, the SBOM, and an honest KNOWN-LIMITATIONS.md. Custom paperwork (BAAs, DPAs, security questionnaires, calls) is handled under the Enterprise / Source / OEM lane on the Licensing page; standard app tiers do not include it.

7. Known limitations

We publish an honest catalogue of current capability gaps in docs/KNOWN-LIMITATIONS.md in the project repository, including AES-256 R=5/R=6 decryption and CJK/RTL editing fidelity. Procurement teams are welcome to request the latest copy.

8. PGP key

A PGP signing key for security advisories will be published here before public 1.0. Until then, security correspondence travels over standard TLS-secured email. Commercial-license JWTs are signed with an Ed25519 key (see §5); that key is unrelated to the future advisory PGP key.