If you believe you have found a security vulnerability in Basira, please do not open a public GitHub issue. Instead:

1. Use the contact page on the vision platform to reach the maintainer privately.
2. Provide:
   • A description of the vulnerability
   • Steps to reproduce
   • The version (commit SHA) you are testing against
   • Any proof-of-concept or evidence
3. You will receive an acknowledgement within 72 hours.
4. We will work with you on a coordinated disclosure timeline. Standard targets:
   • Critical: patch within 7 days
   • High: patch within 30 days
   • Medium / Low: patch within 90 days
5. With your consent, you will be credited in the release notes when the patch ships.

Please do not disclose the vulnerability publicly until a fix is available and you have coordinated with us.

Until Basira reaches its first stable release (V1.0), only the main branch is supported. After V1.0:

Basira is designed with the following security properties as load-bearing, not aspirational:

The program has no network egress capability. The Tauri shell is configured with a Content Security Policy that allows only:

• 'self' — for local frontend assets bundled at build time
• http://127.0.0.1:* — for the loopback sidecar (if enabled)

No outbound HTTP, no telemetry, no auto-update. Updates are delivered as signed MSI bundles that the entity's IT operations install through standard Windows update mechanisms.

• User identity: Each user holds an Ed25519 keypair. The private key is stored encrypted under a key derived from the user's password via Argon2id.
• Audit chain: Every operation (query write, data clean, report generate) is signed by the user's Ed25519 key and chained into a SHA-256 Merkle log. The chain is append-only — modifying any past entry invalidates all subsequent hashes.
• Data at rest: SQLite database is encrypted with AES-256-GCM. The encryption key is derived from a master password held only in entity memory.

Operations are gated by tiered authorisation levels:

Tier escalation requires manager sign-off on critical outputs — see docs/security/authorization.md.

Before any output (query result, report, exported file) leaves the analyst's workspace, the PII Guard scans for:

• Saudi National IDs (Luhn checksum verified)
• Saudi IBANs (ISO 13616 mod-97 verified)
• Medical Record Numbers (MRNs)
• Saudi phone numbers
• Vehicle plate numbers

Detected items are masked by default. Unmasking requires explicit user confirmation and is recorded in the audit chain.

Each release is reproducibly buildable from source. The build pipeline:

• Locks all dependencies (Cargo.lock + pnpm-lock.yaml)
• Uses pinned compiler toolchain (.toolchain/rust-toolchain.toml)
• Produces a SHA-256 digest of the final MSI, published in the release notes

Entities can independently rebuild and verify the bytewise identical output.

Basira's threat model is published at docs/security/threat-model.md. Briefly:

All cryptography is via well-audited libraries:

We do not roll our own crypto. Every primitive call goes through these libraries.