Application controls in the current code

• HTTPS production transport with HSTS, frame denial, MIME-sniffing protection, a restrictive referrer policy, and browser permissions restrictions.
• HttpOnly security sessions, origin validation, CSRF controls on protected workflows, bounded JSON bodies, field validation, and durable purpose-scoped rate limits.
• Parameterized database operations and server-only credentials supplied through the deployment environment.
• Public comments enter moderation state before display; private email fields are not returned by public comment APIs.
• Consented analytics uses allowlisted events, query-free page paths, coarse categories, short-lived or rotating hashes, and automated expiry for the declared analytics records.
• Unexpected API failures return generic messages and request identifiers while technical details remain in server-side logs.
• The staged Content Security Policy starts in report-only mode. A nonce-bound compatible baseline is enforced only after the documented observation and browser-verification gate; the report-only candidate is stricter about inline styles.
• Liveness and database-readiness endpoints separate application response from dependency availability.
• Repository checks cover type safety, linting, dependency advisories, source boundaries, API contracts, browser privacy flows, accessibility, links, metadata, and performance budgets.

Assurance gaps that are not hidden

• CSP enforcement is not claimed before the observation gate and explicit production cutover. The compatible baseline uses nonces for scripts but temporarily permits inline styles; removing that style allowance requires reviewed stylesheet migration evidence.
• Source-defined health checks, synthetic monitoring, and alert workflows do not prove production activation, historical availability, or human response until external runs are verified.
• Individual enterprise identity, customer SSO, SCIM, and customer accounts are not features of the current public website.
• Independent penetration testing, formal certification, and a published third-party audit report are not claimed.
• Provider backup, point-in-time recovery, region, alerting, and restore evidence require current account-level verification.
• Repository-defined checks do not prove that external branch protection, provider alerts, or production approvals are configured until those settings are separately verified.

Report a vulnerability privately

Do not publish exploit details, credentials, personal information, or customer data in an issue or pull request. Email info@kaizenstrategic.ai with the subject Private security report and ask for a secure exchange channel before sending sensitive evidence.

Kaizen targets acknowledgement of a complete report within three business days and an initial disposition within five business days. These are coordination targets, not a bug bounty or contractual SLA.

Machine-readable reporting information is available at /.well-known/security.txt.

Email transport and domain controls

The domain currently receives mail through Google Workspace. SPF and DMARC records exist, but DMARC is currently monitoring-only and the published SPF record should be simplified. No active MTA-STS or TLS-reporting DNS record was observed during the review.

A standards-formatted MTA-STS policy file is prepared in testing mode at /.well-known/mta-sts.txt. That file alone does not activate MTA-STS: the required mta-sts hostname, certificate, DNS TXT record, reporting mailbox, and Google Workspace validation must still be configured and verified.

See the MTA-STS standard and Google Workspace activation guidance.

Related assurance