Please report vulnerabilities privately through GitHub Security Advisories ("Report a vulnerability" on the repository's Security tab). Do not open a public issue. If that is not possible, write to info@afkzonagroup.lt with "SECURITY" in the subject.

We confirm receipt within 3 working days and aim to fix confirmed issues within 30 days. We credit reporters who want to be credited.

Supported versions: the latest minor release.

1. Incident records: descriptions, impact, indicators of compromise, timelines, answers about losses and affected persons. Confidential; may include personal data and information an attacker could use.
2. Integrity of the record: what was reported, when, and why (submission snapshots, the audit log). Needed as evidence towards the authority.
3. Keys: the store key or passphrase, export passphrases, webhook URLs and HMAC secrets.
4. Deadlines: correct computation; a wrong date can cause a missed legal deadline.

• The operator (legitimate user) on their own machine or server.
• A local attacker with read access to the disk or backups but not the key (stolen laptop, backup leak, other user on a shared host).
• A web attacker: a page the operator visits while the UI runs (CSRF, DNS rebinding, clickjacking).
• A network attacker on the path of outgoing webhooks, or controlling DNS for a webhook host.
• A hostile input source: imported incident-tool exports, edited configuration, crafted store or export files.
• A hostile contributor submitting code.

• Rekey is all or nothing. Up to the rename, the file on disk is the old one and only the old secret opens it; after the rename, only the new one does. A crash can leave a temporary file next to the store; if it is complete, it is the new store, encrypted under the new secret. Every record gets a new nonce and the file a new salt, so nothing in the new file is linked to the old ciphertexts.
• Rotation does not reach copies. Backups, exports and .bak files made before a rotation still open with the keys they were made with. Rekey itself keeps no copy under the old key, because that would undo a rotation done after a leak. If the old key leaked, take a new backup and destroy the old copies.
• Open sessions. A running tocsin ui holds the old data key. After a rotation it refuses to write (the key header changed) instead of writing under the old key. Stop it before rotating.
• Restore is a rollback on purpose. A restored store holds what the backup holds; entries made after the backup are not in it. The replaced file is kept byte for byte as <store>.<UTC time>.bak (mode 0600, created exclusively, never following a planted link), and the store.restored entry names it. --replace is required; a symlink, a directory or an oversized file at the store path is refused, not replaced. Anyone who can run import --replace can already write the store directory, so the flag guards against mistakes, not attackers.
• Backups are only as private as their key. An export is sealed under its own key or passphrase; anyone with the file and that key reads every incident. Keep backup keys apart from the backup files.
• Format versions. A file with a newer format version is refused before any key work, and never rewritten. Migration steps must authenticate the old file before using it; the runner then verifies the result as a current store before writing. The original is kept as a .bak.

• Whole-file rollback: someone with write access to the disk can replace the store with an older complete copy. An open UI or CLI session notices a revision going backwards; a fresh start cannot. Write down the audit head hash (tocsin audit --verify) after important steps if you need proof against this.
• Metadata: the store reveals record ids (incident numbers and years), the number of audit entries and record sizes, but no contents.
• Key holder: anyone with the key can read and rewrite everything, including the audit chain.
• Memory: data is decrypted in process memory while Tocsin runs. JavaScript strings cannot be wiped.
• Actor names in the audit log come from TOCSIN_ACTOR or the operating-system user. They are self-declared, not authenticated.
• Login link: tocsin ui prints a one-time login link on standard error. Anyone who reads it before you use it (for example in docker logs) can log in once. Use it promptly; restart the UI to get a new one.
• Debug output: TOCSIN_DEBUG=1 prints stack traces of unexpected errors to the local terminal. The web UI never shows them.
• Plain HTTP UI: the UI uses plain HTTP on loopback. If you expose it beyond the machine (for example in a container), put it behind TLS and an authenticating proxy, and pass the proxy host with --allowed-host.
• Lock files: a crashed process can leave <store>.lock. Tocsin removes it after two minutes when the recorded process no longer exists; otherwise delete it by hand. A writer releases the lock only after checking, through one handle opened without following symlinks, that the file still has its inode and its random token. The final removal is by path (POSIX has no unlink-by-handle), so a process that replaces the lock file in the instant between that check and the removal could still lose its lock; this needs a local process with write access to the store directory, which can already modify the store.
• Time: deadlines depend on a correct system clock and on the IANA time-zone data in your Node.js runtime.

Nothing leaves the machine unless you configure webhooks and run tocsin notify. There is no telemetry, no update check, no remote font or script. The UI loads only its own stylesheet.