Security

Security at CYNAPSE

CYNAPSE helps critical infrastructure operators make defensible security decisions, so we apply the same discipline to our own platform. This page describes the protections in place today and how to report a vulnerability to us.

Effective 12 October 2026 Last updated 12 October 2026 support@cynapse.app

1. Account and access security

  • Multi-factor authentication with authenticator-app codes, and a short-lived emailed recovery link if the device is lost.
  • Passwords are stored only as salted, slow hashes and must meet complexity rules.
  • Repeated failed sign-ins lock the account temporarily, and sign-in responses do not reveal whether an email address is registered.
  • Idle sessions expire, session cookies are Secure, HttpOnly, and SameSite, and every state-changing request carries a CSRF token.
  • Role-based access inside each workspace, with owner-controlled invitations for team members.

2. Tenant isolation

Every organization is a separate tenant. Project, asset, risk, and report requests are checked against the requesting user’s organization and project membership on the server, not only in the interface.

3. Transport and browser security

  • HTTPS only, TLS 1.2 and 1.3, with HTTP Strict Transport Security across all subdomains.
  • A Content Security Policy, frame protection, MIME-sniffing protection, a strict referrer policy, cross-origin isolation headers, and a restrictive permissions policy on every response.

4. Abuse and automation controls

Sign-in, password recovery, registration, contact forms, uploads, and APIs are rate-limited per client and globally. Public forms include automated-submission checks, and outbound email is budgeted so the platform cannot be used to send mail on someone else’s behalf.

5. Audit trail

Changes to projects, risks, controls, approvals, and accounts are recorded in an activity log that workspace owners can review. Retention depends on the plan; see pricing.

6. AI-assisted features

Navai Assistant and AI-assisted reviews send the prompt and the minimum project context needed to answer it to our AI inference provider. Providers process it only to return a response and may not use it to train models. AI output is advisory and should be reviewed by a qualified person. See the Privacy Policy for details.

7. Scanner downloads

Verify the Exposure Engine collector before you run it. It is a readable PowerShell script, so you can review exactly what it collects; its SHA-256 checksum is published on the Exposure Engine page and at /downloads/cynapse-discovery.ps1.sha256. In PowerShell, run Get-FileHash .\cynapse-discovery.ps1 and compare the result. Command-line passwords and tokens are redacted on the host before anything is written. Only run the collector on systems you own or are authorized in writing to assess.

8. Vulnerability disclosure policy

We welcome reports from security researchers. If you believe you have found a vulnerability in cynapse.app or the CYNAPSE platform, email support@cynapse.app with “Security disclosure” in the subject.

Please include

  • The affected URL or component, and the steps to reproduce.
  • The impact you observed, and any proof-of-concept limited to your own data.
  • How we can reach you for follow-up questions.

Rules of engagement

  • Test only against accounts you created. Do not access, change, or delete other users’ data; if you reach it by accident, stop and tell us.
  • No denial-of-service, load testing, spam, social engineering, or physical attacks.
  • Do not run automated scanners at a rate that degrades the service.
  • Give us reasonable time to fix the issue before any public disclosure.

Our commitments

  • We acknowledge reports within three business days and keep you informed while we fix them.
  • We will not pursue legal action against good-faith research that follows this policy.
  • With your permission, we credit researchers once the issue is resolved.

9. Contact

Security reports: support@cynapse.app. Machine-readable contact details are published in security.txt.