not an add-on.
Network segmentation, least privilege, and audit logging are built into every range boundary.
Our posture in plain language
Cynchor is an early-stage cybersecurity training platform and does not hold independent compliance attestations (such as SOC 2 or ISO 27001).
Every control marked "In place" on this page is implemented directly in our production repository and verified by automated tests in our build pipeline.
Unimplemented capabilities are cataloged transparently on our roadmap so security reviewers and evaluating organizations have a clear, truthful baseline.
In-Place Controls (Verified with Evidence)
12 activePasswords are protected using cryptographic key derivation (scrypt) with individual salts and verified using constant-time timingSafeEqual comparisons to eliminate timing attack vectors.
Session tokens are signed with HMAC-SHA256, delivered with HttpOnly, SameSite=Lax, and Secure cookie flags, and validated against session versioning for immediate server-side revocation on logout.
Access invitations use CSPRNG 256-bit entropy, stored strictly as SHA-256 hashes in the invites table, with 7-day expiration and single-use consumption.
Authentication endpoints and public access request routes enforce sliding-window rate limiting with exponential lockout backoff to protect against automated credential attacks.
All incoming request payloads are strictly parsed and sanitized against Zod schemas. Database queries use prepared statements with parameter binding to prevent injection.
Every HTTP response delivers strict security headers including frame-ancestors none CSP, HSTS, nosniff, and cross-origin write blocking to prevent clickjacking and state manipulation.
Administrative and operational capabilities require server-verified operator privileges. Requests lacking operator credentials receive immediate 401/403 responses.
Security actions (authentication, access approval, invite provisioning) are recorded with one-way SHA-256 hashed IP addresses and protected against modification by database triggers.
Public self-registration is disabled. Access to interactive ranges requires an invitation issued by an operator or manual provisioning through administrative routes.
The platform collects only operational name and email for waitlist and access requests. No unnecessary personal, financial, or tracking data is gathered.
Security researchers can report potential vulnerabilities directly to our engineering team via security@cynchor.com.
Automated vulnerability scanning of dependencies in continuous integration pipelines on every push and pull request via npm audit.
On Our Roadmap (Not Yet In Place)
5 plannedTime-based one-time password (TOTP) or WebAuthn hardware key multi-factor authentication for administrative accounts.
Persistent volume and database file encryption depends on deployment host disk encryption; not enforced by the application today.
Independent third-party penetration testing and vulnerability assessment across web application and simulation boundaries.
Documented incident response classification, escalation matrix, and customer notification SLA commitments.
Automated retention and purge schedules for expired invite tokens, inactive demo accounts, and audit log records.
Compliance Status
Independent third-party certifications and regulatory compliance tracking.
| Framework | Status | Evidence / Current Reality |
|---|---|---|
| SOC 2 (Security / Confidentiality) AICPA Service Organization Control standard for cloud service providers. | Not certified | Pre-certification startup. Continuous compliance and independent audit planned post-launch. |
| ISO/IEC 27001 International standard for Information Security Management Systems (ISMS). | Not certified | Formal ISMS governance framework planned for future growth stage. |
| HIPAA Security Rule Standards for protecting sensitive patient health information (PHI). | Not certified | Not applicable to current operations; Cynchor never ingests or stores protected health information. |
| PCI-DSS Payment Card Industry Data Security Standard. | Not certified | No payment card processing in the platform today. |
| FedRAMP Federal Risk and Authorization Management Program for US government agencies. | Not certified | Architecture roadmap targeting future evaluation; no agency sponsorship or assessment underway. |
| GDPR / CCPA European General Data Protection Regulation and California Consumer Privacy Act. | Not formally assessed; see Data we collect | Data minimization is practiced in code, but no formal legal assessment has been conducted. |
We publish no compliance badges or third-party seals. Formal audit status is shown only when backed by an independent auditor report.
Application Security & SDLC
Software development lifecycle practices, testing standards, and static controls.
Enforced SDLC Practices (Live Codebase)
All incoming HTTP request payloads are strictly validated against strongly-typed Zod schemas with length limits and format constraints.
All database queries use SQLite prepared statements with parameter binding, preventing SQL injection vulnerabilities.
Continuous testing executed via npm test covering password hashing, session revocation, single-use invites, audit immutability, and rate limits.
Automated CI workflow in .github/workflows/ci.yml runs npm audit on every push and pull request to identify vulnerable dependencies.
Full TypeScript coverage across the server runtime, frontend components, and simulation engines to catch type errors at build time.
Session signing keys and cryptographic salts are injected exclusively via runtime environment variables; no secrets exist in the git repository.
Automated static analysis and dynamic runtime scanning integrated into pull request pipelines.
Mandatory branch protection requiring dual-operator code reviews and signed commits.
Infrastructure & Data Protection Baseline
Transport layer security, defense-in-depth headers, and session boundaries.
TLS expected on production ingress with HTTP Strict Transport Security (HSTS, max-age=31536000, includeSubDomains, preload).
Strict Content-Security-Policy with frame-ancestors none, X-Content-Type-Options nosniff, and strict Referrer-Policy.
Salted cryptographic scrypt key derivation with timing-safe comparisons and sliding-window lockout backoff.
HMAC-SHA256 signed tokens delivered in HttpOnly, SameSite=Lax, Secure cookies with server-side version invalidation.
Simulated lab environments operate strictly under fintechcorp.local private addressing without access to production logic.
Data We Collect
Exhaustive data inventory derived directly from the application database schema.
| Table / Entity | Fields Stored | Purpose | Hashing / Protection |
|---|---|---|---|
| users | id, email, password_hash, name, role, experience_level, is_operator, created_at | Operator authentication and role assignment for cyber range administration. | Passwords stored as salted scrypt hashes. User IDs and names are stored in plaintext. |
| access_requests | id, name, email, source, status, created_at, approved_at | Waitlist review and operator evaluation for pilot range admission. | Plaintext operational contact fields (name, email). Minimal data collection. |
| disclaimers | id, accepted_at, user_identifier, ip_address, version | Audit record of participant acknowledgment before interactive sessions. | IP address is stored as a one-way SHA-256 hash. user_identifier is a truncated user-agent string. |
| audit_logs | id, user_id, action, details, ip_hash, created_at | Append-only audit trail capturing logins, provisioning, and administrative actions. | Client IP addresses are stored exclusively as one-way SHA-256 hashes with cryptographic salt. |
| teams & matchmaking | team_id, name, side, leader_id, user_id, mode, status, created_at | Cohort formation, queue dispatching, and multiplayer simulation state. | Internal simulation UUIDs and squad names; no external personal data. |
The disclaimer record stores a hashed IP and a truncated user-agent; access requests store name and email; passwords are stored only as scrypt hashes.
Third Parties & Subprocessors
External services contacted by the platform runtime based on code inspection.
| Provider / Service | Purpose | Data Shared | Status |
|---|---|---|---|
| Google Fonts | Typography assets (Inter & Lexend) for web interface styling. | Browser IP address and User-Agent upon client asset fetch. | Active Web Dependency |
| Cloud Infrastructure Provider | Target cloud-hosted architecture for V2 multi-region training infrastructure. | None currently. | Planned (V2); not yet integrated |
Access Control & Operator Identity
Administrative authentication, authorization boundaries, and session lifecycles.
Public self-registration is disabled. Operator accounts require an invitation or manual provisioning by an active administrator.
All administrative routes and API endpoints verify the operator flag on the server for each request; client assertions are untrusted.
Administrative actions (invite generation, account creation, access approvals) are written to an append-only log with database trigger guards.
Logout and administrative revocation instantly invalidate user sessions server-side by advancing the session version counter.
Incident Response & Vulnerability Disclosure
Coordinated vulnerability disclosure guidelines and reporting channels.
- Do not disrupt live range environments or degrade service availability for other participants.
- Do not access, download, or attempt to modify data belonging to other accounts.
- Allow reasonable time for our engineering team to review and resolve reported findings before public disclosure.
- Report vulnerabilities directly to our coordinated disclosure inbox.
Architecture & Trust Boundaries
Config-driven zone isolation model rendering only verified system layers.
Layered Defense-in-Depth Trust Zones
Strict directional boundaries. Training range is isolated from application logic with verified controls only.
Isolated virtual lab running synthetic targets (fintechcorp.local) and non-functional simulation scenarios.
- 100% synthetic enterprise topology (fintechcorp.local)
- RFC 1918 private IP addressing only
- Non-functional conceptual payloads and script logs
- Real customer or production data ingestion
- External routing or real domain communication
- Execution of functional exploit payloads
Security Questionnaire Quick Answers
Direct answers to the 14 most common security assessment questions.
ctrl-encryption-at-restDocuments & Verification Requests
Public security artifacts, printable posture summaries, and questionnaire requests.
Printable Trust Center Summary
Live V1 Lab Architecture Inspection
Need a custom security review or vendor assessment?
Direct your vendor evaluation questionnaire to our security team.