| # | Applicable? | Assessment | Draft comment (1-3 sentences) | Primary evidence |
|---|---|---|---|---|
| 1 | Yes | Ready | Trust boundaries, components, and major data flows are documented in the threat model, including explicit TB1-TB8 boundary definitions. We update this model during security reviews when architecture changes. | docs/THREAT_MODEL.md |
| 2 | Yes | Ready | The client stack is modern Next.js/React and does not use deprecated plugin technologies like Flash, ActiveX, Silverlight, Java applets, or NaCl. Frontend assets are standard web bundles under /_next/static. | apps/web/package.json, docs/security/dast/2026-02-23-modern-web-application.md |
| 3 | Yes | Ready | Access control is enforced at trusted server enforcement points, including the web proxy and service middleware. Client-side checks are used for UX only and are not relied on for authorization decisions. | apps/web/proxy.ts, apps/agents/src/mastra/middleware/index.ts, apps/messaging/src/index.ts |
| 4 | Yes | Ready | Sensitive data is identified and classified into levels (Highly Sensitive, Sensitive, Internal, Public) with mapped data types and stores. Classification is documented and used as the basis for security controls. | docs/DATA_CLASSIFICATION.md |
| 5 | Yes | Ready | Protection requirements are tied to classification, including encryption expectations, access controls, and retention guidance. These controls are reflected in architecture and implementation documents. | docs/DATA_CLASSIFICATION.md, docs/THREAT_MODEL.md |
| 6 | Yes | Needs validation | Runtime code loading from untrusted sources is constrained through dependency governance, audit checks, and egress policy enforcement. If third-party browser scripts are introduced, add SRI or equivalent integrity evidence before approval. | docs/security/V10_MALICIOUS_CODE_VERIFICATION.md, security/approved-egress-domains.json, .github/workflows/ci.yml |
| 7 | Yes | Gap | This is applicable because the application depends on multiple domains/subdomains, but evidence today is mostly checklist-driven and manual. Add automated DNS/CNAME/expiry takeover monitoring before marking this fully complete. | scripts/deploy-checklist.md |
| 8 | Yes | Ready | Anti-automation controls are implemented via global and endpoint-specific rate limits, including auth and verification abuse protections. These controls address excessive calls and business-logic abuse scenarios. | apps/web/proxy.ts, apps/web/lib/rate-limit.ts, apps/web/lib/rate-limit-upstash.ts, docs/security/v11-business-logic-verification.md |
| 9 | Yes | Ready | Untrusted uploaded files are stored in Supabase Storage with scoped object policies rather than a web root directory. Upload path and file validation enforce per-user boundaries and limited permissions. | docs/security/phase-12-file-resources.md, supabase/migrations/20260218110000_profile_images_storage_policies.sql, apps/web/lib/supabase/storage-validation.ts |
| 10 | Yes | Gap | Antivirus scanning for untrusted uploads is explicitly deferred and currently not implemented. Compensating controls exist, but this control should remain marked as a gap until malware scanning is added. | docs/security/phase-12-file-resources.md |
| 11 | Yes | Ready | API URLs were hardened to avoid exposing secrets in query strings, including migration of metrics auth to header-based secret checks. Static audits enforce this policy in CI. | docs/security/v13-api-web-service-verification.md, scripts/security/v13-audit.ts, apps/web/app/api/oauth/metrics/route.ts |
| 12 | Yes | Ready | Authorization is enforced both at route/controller level and at resource level via ownership checks and Supabase RLS. This provides defense in depth against bypasses at either layer. | docs/security/v13-api-web-service-verification.md, supabase/migrations/00000000000000_baseline.sql |
| 13 | Yes | Ready | Enabled HTTP methods are restricted and validated for actor/action appropriateness, including denial of dangerous methods and service-side actor mismatch checks. Unauthorized method usage is blocked with non-success responses. | apps/web/proxy.ts, apps/agents/src/mastra/middleware/index.ts, docs/security/v13-api-web-service-verification.md |
| 14 | Yes | Ready | Build and deployment are repeatable through CI workflows and documented deployment steps. Security checks are automated and version-controlled as part of release readiness. | .github/workflows/ci.yml, .github/workflows/security-audit.yml, scripts/deploy-checklist.md |
| 15 | Yes | Needs validation | The system can be redeployed from source and migrations using documented runbooks, but backup/restore timing evidence should be explicitly attached for final attestation. Add RTO/RPO test records in the review packet. | scripts/deploy-checklist.md, supabase/migrations/ |
| 16 | Yes | Ready | Administrators can verify integrity of security-relevant configuration via policy-as-code scripts and CI checks that fail on drift. This provides practical tamper-detection coverage for critical controls. | scripts/security/v13-audit.ts, scripts/security/check-egress-allowlist.mjs, scripts/security/check-dependency-install-hooks.mjs, .github/workflows/ci.yml |
| 17 | Yes | Ready | Debug/developer features are restricted in production using NODE_ENV guards, dev-only route gating, and framework hardening settings. Production headers also reduce disclosure surface. | apps/web/next.config.mjs, apps/web/app/api/dev/reset-account/route.ts, docs/security/cwe-204-proxy-disclosure-remediation.md |
| 18 | Yes | Ready | Authentication and authorization do not rely on Origin header trust; server-side JWT/session checks, webhook signatures, and shared secret validation are used instead. Continue enforcing this pattern in code review. | apps/web/proxy.ts, apps/agents/src/mastra/middleware/index.ts, apps/web/app/api/webhooks/slack/route.ts |
19-29: Authentication and Session Controls
| # | Applicable? | Assessment | Draft comment (1-3 sentences) | Primary evidence |
|---|---|---|---|---|
| 19 | Yes | Ready | User-set passwords are enforced at a minimum of 12 characters server-side and in Supabase auth config. This is validated in signup, onboarding, reset, and change-password flows. | apps/web/lib/password-security-core.ts, supabase/config.toml, docs/security/v2-auth-verification.md |
| 20 | Yes | Ready | System-generated verification secrets are cryptographically random and short-lived, and are not reused as long-term passwords. Verification links/codes are used only for initial proof flows. | apps/web/app/api/phone/verify/initiate/route.ts, supabase/config.toml |
| 21 | Yes | Needs validation | Password storage is delegated to Supabase Auth, while application logic enforces password quality and breach checking before acceptance. Include provider attestation for hashing algorithm/salting details in the final packet. | docs/security/v2-auth-verification.md, apps/web/lib/password-security-core.ts |
| 22 | Yes | Ready | Shared/default accounts are not used for normal authentication, and admin capability is role-based (profiles.is_admin) with RLS protections. Dev reset utilities are environment-restricted and not available in production. | supabase/migrations/00000000000000_baseline.sql, apps/web/app/api/dev/reset-account/route.ts |
| 23 | Yes | Ready | Lookup secrets are single-use where implemented for authentication workflows, including atomic consume semantics for phone verification tokens. Replay attempts are rejected after first successful use. | apps/web/lib/phone-verification-core.ts, apps/web/app/api/phone/verify/confirm/route.ts |
| 24 | Yes | Gap | Phone verification out-of-band tokens meet the 10-minute expiry requirement, but email OTP is currently configured for 15 minutes. This should be marked partial/gap until all OOB auth tokens align to 10 minutes or less. | apps/web/app/api/phone/verify/initiate/route.ts, supabase/config.toml |
| 25 | Yes | Ready | Initial authentication/verification codes are generated with secure randomness and meet entropy expectations (6-digit OTP baseline and stronger random-token flows). Expiration and anti-replay controls are also present. | supabase/config.toml, apps/web/app/api/phone/verify/initiate/route.ts, apps/web/lib/phone-verification-core.ts |
| 26 | Yes | Ready | Logout and session expiration invalidate active sessions through sign-out flows plus configured session timebox/inactivity limits. This prevents simple session continuation after expiry/logout events. | apps/web/app/auth/signout/actions.ts, supabase/config.toml |
| 27 | Yes | Ready | The application supports invalidating all other active sessions after password reset/change by calling signOut({ scope: "others" }). This behavior is implemented in both recovery and authenticated password change paths. | apps/web/app/auth/update-password/actions.ts, apps/web/app/auth/change-password/actions.ts |
| 28 | Yes | Ready | End-user authentication uses sessions/JWTs rather than static API keys, while static shared secrets are limited to service-to-service trust boundaries. This aligns with session-token-first design for user access. | docs/THREAT_MODEL.md, apps/agents/src/mastra/middleware/index.ts, apps/web/proxy.ts |
| 29 | Yes | Ready | Sensitive account actions require valid authenticated sessions, with additional assurance controls such as secure password change and admin MFA gates. This prevents low-assurance session abuse on high-risk operations. | supabase/config.toml, apps/web/lib/admin/require-mfa.ts, docs/security/v2-auth-verification.md |
30-43: Authorization, Injection, and Input Controls
| # | Applicable? | Assessment | Draft comment (1-3 sentences) | Primary evidence |
|---|---|---|---|---|
| 30 | Yes | Ready | Access control rules are enforced on trusted service layers in web proxy and service middleware. Client-side controls do not grant access by themselves and can be bypassed safely. | apps/web/proxy.ts, apps/agents/src/mastra/middleware/index.ts, apps/messaging/src/index.ts |
| 31 | Yes | Ready | User/data attributes used by policy are server-validated and protected by RLS and request-context controls. Actor mismatches and unauthorized context manipulation are rejected server-side. | apps/agents/src/mastra/middleware/index.ts, supabase/migrations/00000000000000_baseline.sql |
| 32 | Yes | Ready | Least-privilege is enforced through role checks, ownership scoping, and extensive RLS policies. Users are constrained to authorized functions/resources only. | docs/THREAT_MODEL.md, docs/DATA_CLASSIFICATION.md, supabase/migrations/00000000000000_baseline.sql |
| 33 | Yes | Ready | Access-control failure paths are fail-closed, including exception cases in MFA/auth checks that return denial rather than permissive fallback. Generic error responses reduce risky ambiguity. | apps/web/lib/admin/require-mfa.ts, apps/web/lib/api-error.ts |
| 34 | Yes | Ready | IDOR protections are implemented via authenticated user scoping, artifact/token validation checks, and database-level ownership controls through RLS. Unauthorized cross-tenant record access is blocked. | docs/security/v13-api-web-service-verification.md, apps/web/app/api/calendar/token/route.ts, supabase/migrations/00000000000000_baseline.sql |
| 35 | Yes | Ready | Admin-sensitive endpoints enforce MFA assurance (AAL2) before access and are audit-logged for privileged masquerade actions. This materially reduces unauthorized admin interface use. | apps/web/lib/admin/require-mfa.ts, apps/web/app/api/dev/masquerade/start/route.ts |
| 36 | Yes | Needs validation | HTTP parameter pollution risk is applicable, but explicit HPP test evidence is not yet captured. Add dedicated tests for duplicate parameter handling across query/body/header sources before final closure. | docs/security/v13-api-web-service-verification.md, apps/web/proxy.ts |
| 37 | Yes | Needs validation | Mail flows use API-based integrations (AgentMail/Gmail APIs) instead of raw SMTP/IMAP command construction, reducing classic protocol injection vectors. Add explicit CRLF/header injection tests for all user-controlled email fields. | apps/web/app/api/artifacts/[id]/verify-email/route.ts, apps/messaging/src/channels/agentmail/client.ts |
| 38 | Yes | Ready | Static review found no usage of eval, new Function, or similar dynamic code execution patterns in application source. Runtime logic avoids direct code evaluation of user input. | Source search result (no matches), apps/, packages/ |
| 39 | Yes | Ready | SSRF protections are centralized in shared outbound URL validation and safe fetch wrappers with allowlists, DNS/IP checks, and redirect safety controls. Server fetch paths were migrated to these wrappers with lint/audit enforcement. | packages/shared/src/network/index.ts, docs/security/phase-12-file-resources.md, scripts/security/check-raw-fetch.mjs |
| 40 | Yes | Ready | User-uploaded SVG is blocked in profile image flow because only JPEG/PNG/WebP/GIF signatures are accepted. This prevents scriptable SVG payloads from entering that upload surface. | apps/web/lib/supabase/storage-validation.ts, docs/security/phase-12-file-resources.md |
| 41 | Yes | Ready | Output encoding is primarily handled by React escaping, and explicit sanitization is used where raw HTML rendering is required (e.g., DOMPurify). Continue contextual review of any dangerouslySetInnerHTML usage. | apps/web/app/a/[shortId]/_components/templates/default-template.tsx, source search for dangerouslySetInnerHTML |
| 42 | Yes | Ready | JSON handling uses parser-based processing and strict media-type enforcement, with no JSON eval/expression execution patterns. This reduces JSON injection and parser-confusion risk. | apps/web/proxy.ts, apps/agents/src/mastra/middleware/index.ts, apps/messaging/src/index.ts |
| 43 | No | N/A | LDAP injection is not applicable because the application does not use LDAP services, bind operations, or LDAP query composition. Reassess only if LDAP integration is introduced later. | Source search (no LDAP runtime usage) |
44-54: Data Protection, Crypto, Logging, and Transport
| # | Applicable? | Assessment | Draft comment (1-3 sentences) | Primary evidence |
|---|---|---|---|---|
| 44 | Yes | Needs validation | Sensitive data controls include AES-256-GCM encryption for OAuth tokens and managed hosted storage controls for data at rest. Include Supabase/Turso platform encryption attestations for regulated-data final sign-off. | packages/shared/src/encryption.ts, docs/DATA_CLASSIFICATION.md |
| 45 | Yes | Needs validation | Timing-safe comparisons are implemented for secret validation to reduce timing leak risk. Extend validation to ensure all future cryptographic equality checks follow the same pattern. | apps/web/lib/timing-safe.ts, apps/agents/src/mastra/middleware/index.ts, apps/messaging/src/index.ts |
| 46 | Yes | Ready | Random identifiers and request IDs are generated via CSPRNG-backed APIs (crypto.randomUUID, crypto.randomBytes) rather than predictable PRNG functions. This aligns with GUID unpredictability requirements. | apps/web/app/api/dev/masquerade/start/route.ts, apps/messaging/src/channels/agentmail/webhook.ts, apps/web/app/api/phone/verify/initiate/route.ts |
| 47 | Yes | Gap | Key material is currently available to application runtimes through environment variables and not isolated in a vault/HSM-backed cryptographic boundary. Mark as gap until vault-managed key operations are implemented. | docs/DATA_CLASSIFICATION.md, packages/shared/src/encryption.ts |
| 48 | Yes | Needs validation | Logging controls include generic client-safe error responses and metadata redaction in messaging, and payment card data is not stored by the app. Perform periodic log-scrub validation to confirm no credentials or session tokens leak in plaintext. | apps/messaging/src/index.ts, apps/web/lib/api-error.ts, docs/DATA_CLASSIFICATION.md |
| 49 | Yes | Ready | Sensitive responses are protected from intermediary caching with centralized no-store/private cache policies and route-based exceptions only for intended public assets. Automated cache/UA audits verify expected behavior. | apps/web/lib/http/cache-policy.ts, docs/security/v14-http-cache-ua-verification.md, scripts/security/http-cache-ua-audit.mjs |
| 50 | Yes | Ready | Browser storage is used for non-sensitive UX state and not for auth credentials or secret tokens. Authentication remains cookie/session-based with secure server validation. | apps/web/hooks/use-chat-memory.ts, apps/web/app/start/page.tsx, apps/web/components/login-form.tsx, docs/DATA_CLASSIFICATION.md |
| 51 | Yes | Gap | Most sensitive data uses headers/body transport, but tokenized verification/share flows still place signed tokens in query parameters for link-based use cases. Mark as partial/gap and document compensating controls (short expiry, signature, scoped validation). | apps/web/app/api/phone/verify/confirm/route.ts, apps/web/app/api/artifacts/[id]/route.ts, apps/web/app/api/artifacts/[id]/verify-email/route.ts |
| 52 | Yes | Ready | Access to sensitive or privileged operations is auditable through action logs and admin masquerade audit logs, while sensitive payloads are intended to remain redacted/minimized. Audit logs are available for post-incident review and compliance reporting. | apps/agents/src/mastra/services/action-logger.ts, apps/web/app/api/dev/masquerade/start/route.ts, supabase/migrations/00000000000000_baseline.sql |
| 53 | Yes | Needs validation | TLS is enforced for production transport with HSTS and HTTPS-only service URL expectations. Collect hosting provider certificate trust documentation as explicit evidence for final audit closure. | apps/web/next.config.mjs, apps/messaging/src/index.ts, docs/THREAT_MODEL.md |
| 54 | Yes | Needs validation | OCSP stapling and certificate revocation handling are primarily platform-managed in hosted infrastructure and are not configured directly in application code. Attach provider-level revocation/PKI documentation before marking this fully complete. | Hosting provider docs (Vercel, Railway, Supabase), docs/SECURITY.md |