Security policy

How to report a vulnerability in Countersign privately, what to expect afterwards, and which versions receive security fixes. The security model itself (threats, controls, known limitations) is described in docs/security.md.

Reporting a vulnerability

Please do not report security problems in public issues, discussions or pull requests.

Send your report by e-mail to:

security@<your-domain>

Maintainers: this address is a placeholder. Replace it with a monitored mailbox before publishing the repository, and, if the hosting platform offers private vulnerability reporting, enable it and mention it here.

Include as much of the following as you can:

• the version ("version" in /api/health, or the commit) and how it is run: storage, sign-in method, behind which proxy;
• what the problem is and what an attacker could achieve;
• steps to reproduce, or a proof of concept, against a test installation with synthetic data;
• whether the problem is already known to others.

Do not include real records, credentials or personal data. If you need to send something sensitive, say so and ask for an encrypted channel first.

What to expect

These are targets of a volunteer-maintained open-source project, not a service-level agreement. Reporters are credited in the advisory unless they prefer otherwise.

Please give the maintainers a reasonable time to release a fix before you publish details, and do not test against installations you do not own or operate.

Supported versions

Fixes are released as a new patch version of the latest minor version. Because every organisation qualifies the version it runs, release notes of security releases state exactly what changed, whether stored audit trails are affected, and which tests cover the fix, so that the change can be assessed under your change control.

In scope

• The engine and its rules: anything that lets a record change without an identified author and a different approver, or bypasses a permission.
• The audit trail: anything that lets an entry be altered, removed, reordered or fabricated without verify detecting it, beyond the limits documented in docs/security.md and docs/architecture.md.
• Sign-in and sessions: forging or hijacking an identity, bypassing the re-authentication for approvals.
• The HTTP API: cross-site request forgery, injection, access without sign-in to endpoints that need it.
• The command-line tool and the storage adapters.

Not vulnerabilities

These are documented properties of the design. Reports about them are welcome as feature requests, in public:

• Every signed-in person can read all records and the whole audit trail.
• /api/health and /api/bootstrap answer without sign-in.
• A database superuser can rewrite the audit trail; this is detected only against an externally anchored head hash.
• The demo (COUNTERSIGN_STORAGE unset) and the demo sign-in (COUNTERSIGN_AUTH=demo) authenticate nobody.
• The command-line tool records the identity its operator states.
• Sessions cannot be revoked individually before they expire.
• Missing rate limiting and security headers that the documentation assigns to the reverse proxy.

Problems in dependencies should be reported to their maintainers; tell us as well if Countersign's use of the dependency makes it exploitable.

For operators

If you run Countersign and suspect that your installation was attacked or its audit trail manipulated, that is an incident in your organisation, not a vulnerability report: follow docs/operations.md and your own procedures. If the investigation points to a flaw in the software, report it as above.