SoxDesk Security Overview

A one-pager for IT security review. SoxDesk is on-premise software: it runs entirely on your machines, stores data only in folders you control, and makes no outbound connection except to systems you configure yourself (your mail server, your webhook endpoint). There is no vendor-side data processing to assess.

Architecture

• Local application, no cloud backend. SoxDesk is a local Node.js server with a browser-based UI (React), packaged as a self-contained portable folder with a bundled runtime. Users run it on their own Windows workstation and use it at http://localhost:5179.
• Data = files in one folder. All data lives in a single "data store" folder chosen by the customer: an SQLite database file (soxdesk.db), evidence attachments (attachments\), and automatic backups (backups\). Teams share one audit file by pointing every install at the same folder on an internal file share (standard SMB permissions apply). No database server, no additional services.
• Nothing is written outside the store (plus a small local config file next to the app recording the store path).

Network behavior

• Binds to 127.0.0.1 by default. The server is not reachable from the network unless an administrator explicitly overrides the bind address via an environment variable (AF_HOST). Default port is 5179 (AF_PORT).
• No outbound connections, with two customer-controlled exceptions. (1) If the administrator configures SMTP, sign-in codes and notification emails are sent through the customer's own mail server. (2) If the administrator adds a webhook, SoxDesk POSTs event notifications to an endpoint you name — typically your own ServiceNow, Jira or SIEM. Webhooks are outbound only, HMAC-signed so your receiver can verify them, and carry references rather than records: ids, control refs, titles, statuses and severities, never narrative documentation, evidence or workpaper content. An optional hostname allowlist pins where they may point. There is no telemetry, no analytics, no update checks, no crash reporting, and no license "phone-home". A firewall rule blocking the app's process from the internet would break nothing except mail through your own relay and webhooks to your own endpoint.
• The integration API is inbound, and adds no outbound behavior. It is your systems calling your install. Tokens are issued and revoked by your administrator inside your own data store; there is no vendor-side registry, account or gateway, and enabling the API does not change the bind address. A token acts as a user you choose and inherits exactly that person's audit access — there is deliberately no service account that can see across audits.

Authentication and sessions

• Three sign-in modes, chosen per deployment (Admin page): local passwords (scrypt-hashed with per-user salt, minimum 8 characters, fully offline — no mail server needed); 6-digit one-time codes emailed to the user (10-minute expiry, maximum 5 attempts, single-use, 30-second resend throttle; codes stored hashed); or corporate directory (LDAP / Active Directory) — users authenticate with their existing AD credentials, verified by an LDAP bind to your directory server. In directory mode SoxDesk never stores the user's password, the login id is escaped before use in the LDAP filter (injection-safe), and only users you have pre-created in SoxDesk can sign in (no auto-provisioning). Default is email codes.
• Sessions: 7-day sessions carried in httpOnly cookies; session tokens are stored hashed in the database. All API routes except the authentication endpoints require a valid session, enforced server-side.
• Roles and segregation: admin vs. member application roles; per-audit lead / tester / reviewer roles. Segregation of duties (reviewer must differ from preparer), sign-off freezing, and workpaper checkout locking are enforced server-side, not just in the UI, and covered by an automated enforcement test suite run on every release.
• Auditability: an append-style activity log records who did what and when, viewable in the app and included in the archive export.

Data protection

• Evidence files are stored inside the data store under randomized file names and are served only through the authenticated API.
• Backups: the database is copied via SQLite's online backup API on startup and every 6 hours; the 14 most recent copies are kept in <store>\backups\. Backups stay on customer storage. Because the store is plain files, existing file-share backup and retention processes cover it without special handling.
• Licensing is fully offline: license keys are verified with an Ed25519 digital signature against a public key embedded in the app. No activation server exists. If the trial or license lapses, the app degrades to read-only — data remains viewable and exportable indefinitely.

Honest limitations (current version)

We would rather you read these here than discover them in testing:

• Directory sign-in is LDAP-bind only (no full SSO yet). LDAP / Active Directory credential sign-in is supported (users type their AD credentials, verified by bind), but zero-prompt Windows Integrated Auth (Kerberos/IWA) and SAML/OIDC federation are not yet available. Users are still provisioned in-app (the directory verifies the password; SoxDesk controls who has an account).
• No TLS on the local listener. The app serves plain HTTP. On the default localhost binding this traffic never leaves the machine. If AF_HOST is overridden to expose the app on a LAN, traffic (including session cookies) is unencrypted in transit. Our recommendation: keep the default localhost binding with one install per user, or place a TLS-terminating reverse proxy (IIS, nginx, Caddy) in front of a single instance that stays bound to 127.0.0.1.
• Data-at-rest encryption is inherited, not built in. The database and evidence files are not application-encrypted; use OS/volume encryption (e.g. BitLocker) and file-share ACLs, which most environments already have.
• Access control to the store folder matters. Anyone with direct file-system access to the data store can read the SQLite file, bypassing application roles. Scope the share's SMB permissions to the audit team.
• Availability: the shared store must be reachable while users work; an offline replica/sync mode is on the roadmap.

Summary for the reviewer

Questions from your security team are welcome: [email protected] — email, answered by the person who built it. Most questions get an answer within one business day; no response time is guaranteed.