Responsible Disclosure

Our application handles SSH credentials, private keys, and access to production infrastructure. We take any vulnerability seriously. If you have discovered a security issue, please follow the process below.

Disclosure Policy

We ask that you follow responsible disclosure practices:

• Report privately first. Email security@termique.app with a clear description of the vulnerability, steps to reproduce, and potential impact. Do not disclose publicly until we have had a reasonable opportunity to address it.
• Give us time to respond. We aim to acknowledge reports within 48 hours and resolve critical issues within 14 days. We will keep you informed of our progress.
• Act in good faith. Only test against accounts and systems you own or have explicit permission to access. Avoid actions that could compromise user data, disrupt the service, or cause harm to others.

Scope

The following are in scope for this program:

• The Termique desktop application (macOS, Windows, Linux)
• The landing page at termique.app
• Credential encryption and key derivation implementation
• Authentication and session management

Out of Scope

The following activities are explicitly excluded:

• Distributed denial-of-service (DDoS) or volumetric attacks
• Spamming or brute-force attacks
• Social engineering targeting Termique team members
• Physical attacks against infrastructure
• Vulnerabilities in third-party dependencies that are not exploitable in the context of Termique - report those upstream
• Issues that require physical access to a user's unlocked device

What to Include in Your Report

A good report helps us triage faster. Please include:

• A clear description of the vulnerability and affected component
• Step-by-step reproduction instructions
• The potential impact or attack scenario
• App version, OS, and any relevant environment details
• Proof-of-concept code or screenshots where appropriate

Our Commitments

• We will acknowledge your report within 48 hours
• We will not pursue legal action against researchers acting in good faith
• We will keep you informed of remediation progress
• We will credit researchers in release notes if they wish - let us know your preference
• Critical vulnerabilities will be prioritised and resolved within 14 days

Encryption Architecture

For context when researching: Termique encrypts SSH credentials and private keys client-side using AES-GCMwith a key derived from the user's master password via PBKDF2. Encrypted blobs are stored in the OS keychain. The server never receives plaintext credentials or the master password. The key derivation salt is stored in user_metadata on the server.

Shared host credentials work differently and are not end-to-end encrypted. Sharing re-encrypts the credential under a random per-share AES-256-GCM key, and that key is stored encrypted at rest under a server-held secret. The server can therefore decrypt any shared credential - that is what allows a share to reach its recipient without the owner being online, and it is a deliberate trade-off rather than an oversight.

Revoking a share removes the recipient's access through Termique within 30 seconds, on their next sync. It does not reach a credential they have already accepted: that is stored on their own device, encrypted under their own master password. Termique is not a proxy, so an SSH session already open is also not terminated. If someone should lose access to a server, rotate the credential.

Changes to This Policy

We may revise these guidelines periodically. The current version is always available at termique.app/responsible-disclosure.

Contact