{ "questionnaire": "CAIQ", "version": "v4-2026", "framework": "CSA Cloud Controls Matrix v4", "vendor": "CMDash, Inc.", "vendorUrl": "https://cmdash.com", "contact": "security@cmdash.com", "dateCompleted": "2026-10-09", "completedBy": "security@cmdash.com", "scope": "CMDash multi-tenant SaaS platform on AWS us-east-1. Many DCS (Datacenter Security) controls are inherited from AWS — CMDash operates no datacenters. See https://aws.amazon.com/compliance/.", "answerLegend": { "Yes": "Control is fully implemented with shipped evidence.", "No": "Control is not implemented; remediation plan documented in notes.", "NA": "Not applicable — typically because CMDash is a pure SaaS on AWS and the control belongs to the underlying IaaS.", "Compensating Control": "An alternative control achieves the equivalent assurance objective; documented in notes." }, "sections": [ { "id": "A&A", "title": "Audit & Assurance", "questions": [ { "id": "A&A-01", "question": "Are audit and assurance policies and procedures established, documented, approved, communicated, applied, evaluated, and maintained?", "answer": "Yes", "evidence": "/docs/compliance/soc2-type-ii-controls-mapping.md (SOC 2 mapping) + /trust/soc2 public summary + this CAIQ." }, { "id": "A&A-02", "question": "Are independent audits and assessments conducted at least annually?", "answer": "No", "notes": "No SOC 2 report and no auditor engaged yet. No audit period has started, and no start date is set — see /trust/soc2." }, { "id": "A&A-03", "question": "Are risk-based audit plans developed and reviewed?", "answer": "Yes", "evidence": "Risk-treatment plans recorded in /docs/improvement-catalog.md and architecture/09-known-debt.md, reviewed each sprint." }, { "id": "A&A-04", "question": "Are external audit reports made available to customers under NDA?", "answer": "No", "notes": "No external attestation report exists yet (see A&A-02). No report issuance date is committed. Once available, it will be shared with customers under NDA via security@cmdash.com.", "evidence": "No SOC 2 report and no auditor engaged yet. No audit period has started, and no start date is set (see /trust/soc2). No report issuance date is committed." }, { "id": "A&A-05", "question": "Are internal audit findings tracked to remediation?", "answer": "Yes", "evidence": "Findings flow into /docs/improvement-catalog.md with owner + target sprint; debt ledger captures any accepted residual risk." }, { "id": "A&A-06", "question": "Is the cloud service provider's audit posture (e.g. AWS SOC 2) inherited and documented?", "answer": "Yes", "evidence": "AWS SOC 2 + ISO 27001 attestations referenced; physical and IaaS controls inherited per shared-responsibility. See https://aws.amazon.com/compliance/." }, { "id": "A&A-07", "question": "Are audit logs retained for a defined period sufficient for forensic review?", "answer": "Partial", "evidence": "The application's audit_logs table has a retention setting per organization, 365 days by default (DataRetentionPolicy.auditLogDays, apps/api/prisma/schema.prisma); a daily purge at 02:00 UTC deletes older entries for each organization that has saved a retention policy (apps/api/src/data-retention/data-retention.service.ts). There is no cold or immutable archive and no S3 object lock. No AWS CloudTrail is deployed for AWS-management-plane logs." } ] }, { "id": "AIS", "title": "Application & Interface Security", "questions": [ { "id": "AIS-01", "question": "Is application security baked into the SDLC with documented requirements?", "answer": "Yes", "evidence": "Automated gates (lint, typecheck, test, secret scan, dependency audit) run in the maintainer's local pre-push and release gate and in GitHub CI where enabled; /docs/security/* policies; /architecture/ ADRs include threat-model sections." }, { "id": "AIS-02", "question": "Are SAST and SCA executed on every code change?", "answer": "Yes", "evidence": "GitHub CodeQL on push + PR; Renovate + Dependabot for SCA; CycloneDX SBOM produced on every release. /docs/developers/dependency-updates.md." }, { "id": "AIS-03", "question": "Are container images scanned and signed before deployment?", "answer": "Partial", "evidence": "Release images are scanned (Trivy) and signed by digest with a Cosign release key pair, and the SBOM is attached as a Cosign attestation (docs/security/supply-chain.md). Signatures are verified by the release script before the release tag is published, not at deployment time: there is no admission controller (production runs on Lightsail, not Kubernetes), and no SLSA provenance attestation is produced." }, { "id": "AIS-04", "question": "Are application APIs authenticated, authorized, and rate-limited?", "answer": "Yes", "evidence": "JWT + RBAC + per-tenant RLS at apps/api/src/auth/* and apps/api/prisma/migrations/*rls*; API rate-limiting via NestJS ThrottlerGuard, global plus tighter per-endpoint limits (apps/api/src/auth/auth.controller.ts). No WAF is deployed in production today. /trust/security." }, { "id": "AIS-05", "question": "Is input validation enforced server-side for all API endpoints?", "answer": "Partial", "evidence": "Many controllers parse request bodies with zod schemas and a structural body guard rejects malformed or oversized JSON, but not every write handler has a schema yet. class-validator is not used." }, { "id": "AIS-06", "question": "Are mutating operations idempotent?", "answer": "Yes", "evidence": "/docs/developers/idempotency.md — S39 idempotency-key middleware on all mutating endpoints." }, { "id": "AIS-07", "question": "Are HTTP security headers configured per OWASP guidance?", "answer": "Partial", "evidence": "/docs/security/http-headers.md — headers are set by the Next.js applications and by helmet in the API (Caddy is the edge proxy); CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy are set on the dashboard, marketing site and API. The policy portal sets only X-Content-Type-Options, X-Frame-Options and Referrer-Policy, and the staff admin app's CSP still allows unsafe-inline and unsafe-eval." }, { "id": "AIS-08", "question": "Is DAST or third-party penetration testing performed at least annually?", "answer": "No", "notes": "/trust/pentest — no third-party penetration test has been completed or contracted; planned against OWASP ASVS-L2, not yet scheduled or contracted. Internal Burp/ZAP runs in the interim.", "evidence": "No third-party penetration test has been completed or contracted — see /trust/pentest: planned against OWASP ASVS-L2, not yet scheduled or contracted. Internal Burp/ZAP runs are the interim DAST coverage." }, { "id": "AIS-09", "question": "Are webhooks and inbound integrations cryptographically authenticated?", "answer": "Yes", "evidence": "/docs/developers/webhook-receivers.md — HMAC-SHA256 signature, timestamp + nonce replay protection, IP allowlists where supported." } ] }, { "id": "BCR", "title": "Business Continuity & Operational Resilience", "questions": [ { "id": "BCR-01", "question": "Is a business-continuity plan documented and reviewed annually?", "answer": "Compensating Control", "notes": "Operational continuity is covered by /docs/cloud-deployment-runbook.md and /docs/sre/slos.md; standalone customer-facing BCP document is a Q3 2026 deliverable." }, { "id": "BCR-02", "question": "Are RTO and RPO defined and communicated for each tier of service?", "answer": "Yes", "evidence": "/docs/sre/slos.md — RTO 4h, RPO 15m for tier-1 (auth + core API)." }, { "id": "BCR-03", "question": "Are backups encrypted, off-site, and tested for restoration?", "answer": "Compensating Control", "evidence": "The managed PostgreSQL database takes automated daily snapshots with point-in-time recovery (infra/terraform/lightsail-saas/database.tf) — not RDS. Object storage uses S3-managed AES-256 (SSE-S3), not KMS. No cross-region backup replication exists (see BCR-04), and restoration has not been drill-tested — a documented monthly restore drill is an open item.", "notes": "Documented monthly restore-drill cadence is open SOC 2 evidence item (CC7.5)." }, { "id": "BCR-04", "question": "Is the platform deployed across multiple availability zones?", "answer": "Compensating Control", "evidence": "Production runs on AWS Lightsail, not RDS/ECS/ALB. Two application instances are distributed across separate availability zones behind a Lightsail load balancer (infra/terraform/lightsail-saas/main.tf), and the managed PostgreSQL database is provisioned on a high-availability bundle by default (variables.tf, db_high_availability). No cross-region DR exists." }, { "id": "BCR-05", "question": "Are graceful-degradation patterns implemented for downstream failures?", "answer": "Yes", "evidence": "/docs/developers/circuit-breaker.md — S40 circuit breaker on third-party HTTP calls. /docs/developers/dead-letter.md — S40 DLQ for async failures." }, { "id": "BCR-06", "question": "Are SLA commitments documented and credit-backed?", "answer": "Yes", "notes": "99.9% monthly availability SLA in the MSA with credit schedule on the order form." }, { "id": "BCR-07", "question": "Is a customer-facing status page maintained?", "answer": "No", "notes": "/docs/status-page-setup.md describes the planned Statuspage.io implementation. Public status page launch is on the Q3 2026 roadmap." }, { "id": "BCR-08", "question": "Are continuity tests performed at least annually?", "answer": "Compensating Control", "notes": "Real production incidents have exercised the runbook. Formal annual tabletop is a Q4 2026 commitment." } ] }, { "id": "CCC", "title": "Change Control & Configuration Management", "questions": [ { "id": "CCC-01", "question": "Are production changes governed by a documented process?", "answer": "Partial", "evidence": "SOC 2 mapping CC8. Every change is committed with a conventional-commit message and runs through the automated gates (lint, typecheck, tests, secret scan); main blocks force-pushes. CMDash currently has a single maintainer, so no second reviewer is required (see /trust/soc2). Schema migrations under apps/api/prisma/migrations/." }, { "id": "CCC-02", "question": "Are emergency changes approved through an expedited but documented path?", "answer": "Yes", "notes": "Emergency hotfix branches require post-merge retrospective documented in the PR; no bypass of CI gates." }, { "id": "CCC-03", "question": "Is infrastructure provisioned via code (IaC)?", "answer": "Partial", "evidence": "AWS infrastructure is defined as Terraform code under infra/terraform/ (the deployed stack is lightsail-saas/). Configuration drift is not detected automatically (see CCC-05)." }, { "id": "CCC-04", "question": "Are changes traceable to an authorized requester and reviewer?", "answer": "Yes", "evidence": "git log and the GitHub pull-request history record every change and its author. CODEOWNERS names the owner, but no second reviewer is required: CMDash currently has a single maintainer, so no second reviewer is required (see /trust/soc2)." }, { "id": "CCC-05", "question": "Is configuration baseline drift detected and remediated?", "answer": "No", "evidence": "No automated Terraform drift-detection job or AWS Config rule set was found in this repository. Configuration drift is not currently detected automatically." }, { "id": "CCC-06", "question": "Are rollback procedures tested?", "answer": "Compensating Control", "evidence": "Documented release process (scripts/deploy-lightsail.sh, docs/runbooks/blue-green-cutover.md) retains each host’s prior release images (KEEP_COUNT=3) so a bad release can be rolled back by redeploying a prior image — a real, different mechanism from the blue/green ECS + Terraform-state-revert process this control previously described (production is AWS Lightsail, not ECS; the runbook’s own 2026-07-26 notice flags the mismatch). No record of that rollback path actually being exercised in a test/drill was found in this repository, so this is not asserted as “tested.”" }, { "id": "CCC-07", "question": "Are feature toggles used to decouple deploy from release?", "answer": "Yes", "evidence": "/docs/developers/feature-flags.md — S38 flag service with per-tenant overrides." }, { "id": "CCC-08", "question": "Is segregation of duties enforced for production changes?", "answer": "No", "evidence": "Every change is committed with a conventional-commit message and runs through the automated gates (lint, typecheck, tests, secret scan); main blocks force-pushes. CMDash currently has a single maintainer, so no second reviewer is required (see /trust/soc2). Production releases are built, signed and deployed by the maintainer from the release host (scripts/ci/release-local.sh, scripts/deploy-lightsail.sh), not by CI." } ] }, { "id": "CEK", "title": "Cryptography, Encryption & Key Management", "questions": [ { "id": "CEK-01", "question": "Is data encrypted at rest using approved algorithms?", "answer": "Compensating Control", "evidence": "Object storage (S3) uses server-side AES-256 encryption with S3-managed keys (SSE-S3), not AWS KMS — infra/terraform/lightsail-saas/objectstore.tf. The production database is a Lightsail managed PostgreSQL instance; this repository’s infrastructure code does not document a KMS-based at-rest encryption mechanism for it. No EBS volumes are provisioned (Lightsail, not EC2)." }, { "id": "CEK-02", "question": "Is data encrypted in transit using TLS 1.2 or higher?", "answer": "No", "evidence": "Production's load balancer currently accepts TLS 1.0 and 1.1 in addition to 1.2, and refuses TLS 1.3 (verified against production, 2026-09-25). There is no ALB — this is a Lightsail load-balancer certificate (infra/terraform/lightsail-saas/main.tf) with no minimum-TLS-version policy set. Database connections do use sslmode=require." }, { "id": "CEK-03", "question": "Are cryptographic keys managed via a dedicated KMS?", "answer": "No", "evidence": "No dedicated KMS is used for customer data. Object storage uses S3-managed encryption (SSE-S3); the production database's at-rest encryption mechanism is not documented in this repository's infrastructure code. The only KMS key in this codebase wraps the control plane's license-signing key (docs/runbooks/control-plane-deploy.md, alias/cmdash-license-signing), unrelated to customer tenant data." }, { "id": "CEK-04", "question": "Are private keys protected from extraction (HSM/KMS-backed)?", "answer": "No", "evidence": "Not KMS/HSM-backed for customer data. Application secrets, including the audit-chain and license signing keys, are held in AWS Secrets Manager (infra/terraform/lightsail-saas/secrets.tf); the license-signing key specifically is envelope-encrypted under a KMS key (docs/runbooks/license-signing-key-setup.md), but that protects a control-plane key, not customer data." }, { "id": "CEK-05", "question": "Is key rotation enforced on a documented schedule?", "answer": "Partial", "evidence": "No AWS KMS customer-managed key rotation exists in production (no CMKs are provisioned for customer data — see CEK-03). Application-issued JWT access tokens are short-lived (15 minutes) with rotating refresh tokens, which is a real, documented rotation practice (/trust/security)." }, { "id": "CEK-06", "question": "Is crypto-erasure available as a deletion mechanism for tenant offboarding?", "answer": "No", "notes": "Currently FK-cascade delete only. Crypto-erasure via per-tenant envelope key tear-down is improvement-catalog item III.2.3, scheduled Q4 2026." }, { "id": "CEK-07", "question": "Are weak ciphers and protocols prohibited?", "answer": "No", "evidence": "No ALB or ELBSecurityPolicy is in use. Production runs a Lightsail load balancer with no TLS-policy/cipher configuration set in this repository's Terraform, and TLS 1.0/1.1 are currently still accepted (see CEK-02) — weak protocol versions are not yet prohibited." }, { "id": "CEK-08", "question": "Are TLS certificates managed via an automated lifecycle?", "answer": "No", "evidence": "No AWS Certificate Manager is used. The production certificate is a Lightsail load-balancer certificate (infra/terraform/lightsail-saas/main.tf), a separate AWS certificate product from ACM." }, { "id": "CEK-09", "question": "Do you support Bring Your Own Key (BYOK)?", "answer": "No", "notes": "BYOK is on the post-SOC 2 roadmap (target H2 2027). Current customers are encrypted with CMDash-managed CMKs." }, { "id": "CEK-10", "question": "Are cryptographic libraries kept current and patched?", "answer": "Yes", "evidence": "Renovate + Dependabot auto-PR; CycloneDX SBOM published per release. /docs/developers/dependency-updates.md." } ] }, { "id": "DCS", "title": "Datacenter Security", "questions": [ { "id": "DCS-01", "question": "Are physical security controls (badge, escort, video) in place at datacenters?", "answer": "NA", "notes": "Inherited from AWS. CMDash operates no datacenters or colos. See https://aws.amazon.com/compliance/data-center/controls/." }, { "id": "DCS-02", "question": "Are environmental controls (fire, HVAC, power) in place?", "answer": "NA", "notes": "Inherited from AWS shared-responsibility model." }, { "id": "DCS-03", "question": "Are datacenters located in approved geographies?", "answer": "Yes", "evidence": "Production processing in AWS us-east-1 (N. Virginia, USA). Subprocessor regions enumerated at /trust/subprocessors." }, { "id": "DCS-04", "question": "Are datacenter visitors logged?", "answer": "NA", "notes": "Inherited from AWS." }, { "id": "DCS-05", "question": "Is media containing customer data sanitized before disposal?", "answer": "NA", "notes": "All customer data resides on AWS-managed media; AWS handles media-disposal per their compliance attestations." }, { "id": "DCS-06", "question": "Are datacenter access reviews performed?", "answer": "NA", "notes": "Inherited from AWS. AWS publishes their SOC 2 + ISO 27001 reports under NDA via AWS Artifact." }, { "id": "DCS-07", "question": "Is asset disposal performed in a way that prevents data recovery?", "answer": "NA", "notes": "Inherited from AWS for managed storage." } ] }, { "id": "DSP", "title": "Data Security & Privacy Lifecycle Management", "questions": [ { "id": "DSP-01", "question": "Is a data classification scheme defined?", "answer": "Compensating Control", "evidence": "/docs/developers/tags.md tag taxonomy classifies internal data; PII fields tagged in apps/api/prisma/schema.prisma.", "notes": "Customer-facing data-classification matrix is a Q3 2026 deliverable." }, { "id": "DSP-02", "question": "Is personal data inventory maintained?", "answer": "Yes", "evidence": "Subprocessor list at /trust/subprocessors documents data categories per processor; schema-level PII tagging in apps/api/prisma/schema.prisma." }, { "id": "DSP-03", "question": "Is data minimization practiced?", "answer": "Yes", "evidence": "Schema review during design rejects collection without documented purpose." }, { "id": "DSP-04", "question": "Are data-subject access, deletion, and portability requests supported?", "answer": "Yes", "evidence": "/apps/web/src/app/(dashboard)/data-export/ — self-serve tooling." }, { "id": "DSP-05", "question": "Are international transfers governed by an approved mechanism?", "answer": "Yes", "evidence": "/trust/dpa — SCC for EU/UK transfers; BCR fallback documented." }, { "id": "DSP-06", "question": "Is data retention configured per a documented policy?", "answer": "Yes", "evidence": "/apps/web/src/app/(dashboard)/data-retention/ — per-tenant retention policy configuration." }, { "id": "DSP-07", "question": "Is data deletion verifiable?", "answer": "Compensating Control", "notes": "FK-cascade delete on tenant offboarding is verifiable via audit_logs + database-side row counts. Crypto-erasure (improvement-catalog III.2.3) will provide stronger verification post-Q4 2026." }, { "id": "DSP-08", "question": "Is sensitive data masked or tokenized in non-production environments?", "answer": "Yes", "evidence": "Staging refreshes from prod use a documented anonymization pipeline (PII-stripped, tokenized identifiers). Production data never lands in dev." }, { "id": "DSP-09", "question": "Is DLP deployed to prevent unauthorized exfiltration?", "answer": "Compensating Control", "notes": "There is no network-level egress allowlist (production uses Lightsail networking, with no VPC); application-level outbound requests go through an SSRF-safe wrapper. No AWS CloudTrail or GuardDuty is deployed to monitor data-movement patterns (see TVM-06). Endpoint DLP on workstations is not deployed." }, { "id": "DSP-10", "question": "Are privacy impact assessments (PIA) performed for new data uses?", "answer": "Compensating Control", "notes": "Schema-review process flags new PII collection; standalone PIA template will be introduced in Q3 2026 alongside the RoPA register." } ] }, { "id": "GRC", "title": "Governance, Risk & Compliance", "questions": [ { "id": "GRC-01", "question": "Are governance policies established, approved, and communicated?", "answer": "Yes", "evidence": "/docs/security/, /docs/runbooks/, /docs/compliance/ — version-controlled. CMDash has a single maintainer, so there is no separate approval or communication step." }, { "id": "GRC-02", "question": "Is a risk-management framework adopted?", "answer": "Yes", "evidence": "CMDash operates its own product against itself — internal-tenant risks tracked in apps/api/src/risks/* and surfaced at /risks. SOC 2 mapping CC3." }, { "id": "GRC-03", "question": "Are roles and responsibilities for security and privacy assigned?", "answer": "Compensating Control", "evidence": "Security accountability sits with CMDash's single maintainer (see /trust/soc2).", "notes": "A formal responsibility statement and RACI matrix are open management items." }, { "id": "GRC-04", "question": "Are exceptions to policy formally documented and approved?", "answer": "Yes", "evidence": "Every exception is captured in architecture/09-known-debt.md as a dated caveat with named owner." }, { "id": "GRC-05", "question": "Is compliance with applicable laws and regulations tracked?", "answer": "Yes", "evidence": "GDPR + CCPA covered in /trust/dpa; SOC 2 readiness in /trust/soc2." }, { "id": "GRC-06", "question": "Are policies reviewed and updated at defined intervals?", "answer": "Yes", "evidence": "Sprint-cadence review of /docs/compliance/soc2-type-ii-controls-mapping.md and /docs/security/* via the debt-ledger workflow." }, { "id": "GRC-07", "question": "Are management metrics for security program effectiveness tracked?", "answer": "Yes", "evidence": "/docs/sre/slos.md SLO dashboards (S39 + S45 Grafana); MTTR / MTTD captured per postmortem." }, { "id": "GRC-08", "question": "Is a formal compliance attestation (e.g. SOC 2) held?", "answer": "No", "notes": "/trust/soc2 — no SOC 2 report and no auditor engaged yet. No audit period has started, and no start date is set. Per-CC readiness self-assessment mapped at /docs/compliance/soc2-type-ii-controls-mapping.md." } ] }, { "id": "HRS", "title": "Human Resources", "questions": [ { "id": "HRS-01", "question": "Are background checks performed on all personnel before hire?", "answer": "No", "notes": "CMDash currently has a single maintainer and operates no formal background-screening programme." }, { "id": "HRS-02", "question": "Are confidentiality agreements signed by all personnel?", "answer": "Yes", "notes": "PIIA + confidentiality clauses in standard offer letter; contractor MSA covers contractors." }, { "id": "HRS-03", "question": "Is annual security-awareness training mandatory?", "answer": "Yes", "evidence": "Annual refresh tracked as calendar item; onboarding requires reading /docs/security/* + /docs/runbooks/secret-leak-response.md." }, { "id": "HRS-04", "question": "Are roles requiring privileged access subject to enhanced screening or training?", "answer": "Yes", "evidence": "Production-access onboarding requires runbook walkthrough + on-call shadowing." }, { "id": "HRS-05", "question": "Is access promptly removed upon termination or role change?", "answer": "Yes", "evidence": "SCIM v2 deprovisioning at apps/api/src/saml/scim.controller.ts; refresh-token rotation invalidates active sessions." }, { "id": "HRS-06", "question": "Is there a formal disciplinary process for policy violations?", "answer": "Yes", "notes": "Security violations are handled under the acceptable-use expectations documented in the repository." }, { "id": "HRS-07", "question": "Are remote-work security expectations documented?", "answer": "No", "notes": "There is no managed-device programme; remote-work security expectations are not enforced through device management. CMDash currently has a single maintainer (see /trust/soc2)." } ] }, { "id": "IAM", "title": "Identity & Access Management", "questions": [ { "id": "IAM-01", "question": "Are unique user identities enforced?", "answer": "Yes", "evidence": "Per-user UUID + unique email; shared accounts disallowed in AUP. apps/api/src/auth/." }, { "id": "IAM-02", "question": "Is multi-factor authentication available to all users?", "answer": "Yes", "evidence": "TOTP MFA with recovery codes; SAML SSO supports IdP-side MFA. /docs/security/authentication.md." }, { "id": "IAM-03", "question": "Is MFA enforced for administrative and privileged users?", "answer": "Yes", "evidence": "S40 mfaPolicy gate enforces MFA for any user with admin/owner role; cannot be bypassed without role downgrade." }, { "id": "IAM-04", "question": "Is SSO supported for enterprise customers?", "answer": "Yes", "evidence": "SAML 2.0 SSO with SP-init + IdP-init flows. apps/api/src/saml/." }, { "id": "IAM-05", "question": "Is automated provisioning supported (SCIM)?", "answer": "Yes", "evidence": "SCIM v2 at apps/api/src/saml/scim.controller.ts; LDAP sync worker for non-SCIM IdPs." }, { "id": "IAM-06", "question": "Is role-based access control enforced application-side?", "answer": "Yes", "evidence": "RBAC with Owner/Admin/Viewer + custom roles; per-tenant Postgres RLS at apps/api/prisma/migrations/*rls*." }, { "id": "IAM-07", "question": "Are passwords stored using a strong one-way hash with salt?", "answer": "Yes", "evidence": "/docs/security/authentication.md — bcrypt cost factor 12 with per-user salt." }, { "id": "IAM-08", "question": "Is the password policy compliant with modern guidance (NIST 800-63B)?", "answer": "Partial", "evidence": "/docs/security/authentication.md — 8-character minimum and 72-character maximum on register and reset, no composition rules by default, no forced rotation. There is no breached-password check today." }, { "id": "IAM-09", "question": "Are sessions invalidated on credential change?", "answer": "Yes", "evidence": "S38-K3 session invalidation: refresh tokens revoked on password reset and MFA disable." }, { "id": "IAM-10", "question": "Are API tokens scoped, expirable, and revocable?", "answer": "Yes", "evidence": "S41 API-key TTL — every API key has expiry; per-token scope; revocation via admin UI propagates within cache window." }, { "id": "IAM-11", "question": "Are privileged-access reviews performed at least quarterly?", "answer": "Compensating Control", "evidence": "Tooling exists at /audit-logs + RBAC inspector.", "notes": "Documented quarterly attestation cadence is open SOC 2 Type I evidence-build item." }, { "id": "IAM-12", "question": "Are failed authentications rate-limited?", "answer": "Yes", "evidence": "Timing-equalised login prevents account-existence disclosure via response-time side channels, plus NestJS ThrottlerGuard rate limits on auth endpoints (e.g. 20 attempts/60s per IP on login) — apps/api/src/auth/auth.controller.ts. No WAF is deployed in production today. /trust/security." } ] }, { "id": "IPY", "title": "Interoperability & Portability", "questions": [ { "id": "IPY-01", "question": "Are open standards used for data import / export?", "answer": "Yes", "evidence": "/apps/web/src/app/(dashboard)/data-export/ supports CSV, JSON, and provider-format exports per integration." }, { "id": "IPY-02", "question": "Are public APIs documented?", "answer": "Yes", "evidence": "OpenAPI spec generated from NestJS controllers; published to the developer docs site." }, { "id": "IPY-03", "question": "Are SCIM and SAML used to support enterprise interoperability?", "answer": "Yes", "evidence": "SAML 2.0 + SCIM v2 at apps/api/src/saml/." }, { "id": "IPY-04", "question": "Is webhook delivery used to support customer integrations?", "answer": "Yes", "evidence": "/docs/developers/webhook-receivers.md — outbound webhooks with HMAC-SHA256 signatures, retry with exponential backoff, DLQ for poison events." }, { "id": "IPY-05", "question": "Is exit/migration assistance offered on contract termination?", "answer": "Yes", "notes": "MSA includes a 30-day post-termination data-export window via the same self-serve tooling at /apps/web/src/app/(dashboard)/data-export/." }, { "id": "IPY-06", "question": "Are APIs versioned with a documented deprecation policy?", "answer": "Yes", "notes": "URL-path versioning (/v1/, /v2/); minimum 12-month deprecation notice for breaking changes; deprecation surfaced in response headers + sales-changelog." } ] }, { "id": "IVS", "title": "Infrastructure & Virtualization Security", "questions": [ { "id": "IVS-01", "question": "Are network segments isolated by environment?", "answer": "No", "evidence": "No separate AWS accounts per environment were found in this repository's infrastructure code — production is one Lightsail-based AWS footprint (infra/terraform/lightsail-saas/), not a multi-account, multi-VPC architecture." }, { "id": "IVS-02", "question": "Is multi-tenant data isolation enforced?", "answer": "Yes", "evidence": "Per-tenant Postgres row-level-security policies under apps/api/prisma/migrations/*rls*; tenantId enforced on every query path." }, { "id": "IVS-03", "question": "Are infrastructure components hardened against the CIS benchmarks where applicable?", "answer": "Partial", "evidence": "No AWS Config is deployed, so CIS AWS Foundations benchmark monitoring via AWS Config does not occur. Container base-image hardening specifics were not independently verified as part of this review." }, { "id": "IVS-04", "question": "Are workloads run on immutable infrastructure?", "answer": "Compensating Control", "evidence": "Application containers are immutable, content-addressed Docker images that are redeployed rather than patched in place (scripts/deploy-lightsail.sh). The underlying compute is long-lived AWS Lightsail instances, not ECS Fargate’s ephemeral task infrastructure." }, { "id": "IVS-05", "question": "Is hypervisor-layer isolation provided by the IaaS?", "answer": "Compensating Control", "evidence": "Compute runs on AWS Lightsail instances, not AWS Fargate tasks — there is no Firecracker microVM-per-task isolation. Lightsail instances are still isolated per AWS's standard instance virtualization, though this repository does not document the specific hypervisor/isolation technology involved." }, { "id": "IVS-06", "question": "Are administrative access paths restricted and logged?", "answer": "No", "evidence": "SSH is currently open on production instances, restricted to operator-supplied admin CIDRs (infra/terraform/lightsail-saas/main.tf) — it is not SSM-Session-Manager-only. That file's own comment names moving to AWS SSM / Session Manager, so no inbound SSH port is exposed, as a longer-term improvement, not the current state. Administrative sessions over SSH are not logged by this mechanism." }, { "id": "IVS-07", "question": "Are management interfaces protected from the public internet?", "answer": "Partial", "evidence": "The managed database has no public endpoint (publicly_accessible = false, infra/terraform/lightsail-saas/database.tf), and SSH access to instances is restricted to operator-supplied admin CIDRs (main.tf). There is no ECS task management or VPC-endpoint architecture (no ECS is deployed), and this repository does not document how AWS console/IAM access itself is restricted." }, { "id": "IVS-08", "question": "Are inbound/outbound network flows logged?", "answer": "No", "evidence": "No VPC Flow Logs, CloudWatch log group, or GuardDuty are provisioned in the deployed stack (infra/terraform/lightsail-saas/). Not yet implemented; no target date committed." } ] }, { "id": "LOG", "title": "Logging & Monitoring", "questions": [ { "id": "LOG-01", "question": "Are application and infrastructure logs centralized?", "answer": "Partial", "evidence": "/docs/developers/structured-logging.md — pino JSON logs with consistent request/tenant/user/trace context. No third-party log or APM vendor receives application telemetry; the observability stack (Prometheus, Loki, Tempo) is self-hosted." }, { "id": "LOG-02", "question": "Are logs protected from tampering or unauthorized deletion?", "answer": "Partial", "evidence": "No third-party log vendor holds application logs. No AWS CloudTrail is deployed, so AWS-management-plane actions are not separately logged with tamper protection." }, { "id": "LOG-03", "question": "Are administrative actions logged with operator identity?", "answer": "Partial", "evidence": "The application's audit_logs table records actorId on every state change. No AWS CloudTrail or AWS Systems Manager Session Manager logging was found in this repository for infrastructure-level administrative actions (cloud console or SSH access)." }, { "id": "LOG-04", "question": "Are logs retained for a defined period?", "answer": "Partial", "evidence": "The application's audit_logs table has a retention setting per organization, 365 days by default; a daily purge at 02:00 UTC deletes older entries for each organization that has saved a retention policy. There is no cold or immutable archive and no S3 object lock. No AWS CloudTrail is deployed, so AWS-management-plane logs have no defined retention here." }, { "id": "LOG-05", "question": "Are security-relevant events alerted in real time?", "answer": "No", "evidence": "No AWS GuardDuty is deployed, and no PagerDuty (or equivalent paging) integration exists anywhere in this repository — infra/terraform/lightsail-saas/alarms.tf's own comment flags PagerDuty/Opsgenie as a future swap-in, not a live one. CloudWatch alarms and an SNS paging topic for the cloud deployment are written but not yet applied to production (see /trust/security). Application metrics are collected by the self-hosted Prometheus stack, but nothing pages on-call from it today." }, { "id": "LOG-06", "question": "Are SLO breaches tracked and alerted?", "answer": "Yes", "evidence": "/docs/sre/slos.md — fast- and slow-burn alerts on every tier-1 SLO; S45 Grafana dashboards." }, { "id": "LOG-07", "question": "Are end-to-end traces captured?", "answer": "Yes", "evidence": "S41 + S45 W3C trace-context propagation across services and webhook deliveries. /docs/developers/structured-logging.md." }, { "id": "LOG-08", "question": "Are evidence chains preserved for compliance reporting?", "answer": "Yes", "evidence": "/docs/developers/evidence-propagation.md — S46 evidence-id propagation across the request graph for SOC 2 audit-trail collection." }, { "id": "LOG-09", "question": "Are sensitive fields redacted from logs?", "answer": "Yes", "evidence": "/docs/developers/structured-logging.md — pino redact list covers password, token, authorization, cookie, secret. Redaction enforced at the logger boundary." } ] }, { "id": "SEF", "title": "Security Incident Management, e-Discovery & Cloud Forensics", "questions": [ { "id": "SEF-01", "question": "Is there a documented incident-response plan?", "answer": "Yes", "evidence": "/docs/runbooks/secret-leak-response.md is the canonical IR runbook; service-specific runbooks under /docs/runbooks/." }, { "id": "SEF-02", "question": "Are IR roles assigned and trained?", "answer": "Yes", "evidence": "On-call rotation owns initial triage; incident-commander role rotates on a documented cadence." }, { "id": "SEF-03", "question": "Is the IR plan tested at least annually?", "answer": "Compensating Control", "notes": "Real production incidents have exercised the runbook; formal annual tabletop is a Q4 2026 commitment." }, { "id": "SEF-04", "question": "Are incidents classified by severity with defined response SLAs?", "answer": "Yes", "evidence": "SEV0/SEV1/SEV2 classification in the IR runbook; SEV0 = 15-minute on-call ack." }, { "id": "SEF-05", "question": "Is forensic-evidence preservation handled per documented procedure?", "answer": "Compensating Control", "evidence": "The audit_logs table with its retention policy provides the application-side substrate for forensic evidence. No AWS CloudTrail is deployed for AWS-management-plane evidence.", "notes": "Documented forensic-handling procedure is a Q4 2026 deliverable." }, { "id": "SEF-06", "question": "Are post-incident reviews (postmortems) conducted?", "answer": "Yes", "evidence": "Blameless postmortems for SEV0/SEV1; templates in /docs/runbooks/." }, { "id": "SEF-07", "question": "Is breach notification performed within a documented SLA?", "answer": "Yes", "evidence": "/trust/dpa — 72-hour confirmed-breach notification per GDPR Article 33." }, { "id": "SEF-08", "question": "Is a responsible-disclosure / vulnerability-reporting channel published?", "answer": "Yes", "evidence": "/trust/disclosure — security@cmdash.com reporting mailbox; 90-day coordinated disclosure window; safe-harbour." }, { "id": "SEF-09", "question": "Are dead-letter mechanisms in place for failed event-processing?", "answer": "Yes", "evidence": "/docs/developers/dead-letter.md — S40 DLQ with redrive UI; failed events are surfaced for IR review." } ] }, { "id": "STA", "title": "Supply-chain, Transparency & Accountability", "questions": [ { "id": "STA-01", "question": "Are subprocessors listed publicly with notification of changes?", "answer": "Yes", "evidence": "/trust/subprocessors — dated table of every subprocessor with purpose, region, legal basis; 30-day change-notification policy." }, { "id": "STA-02", "question": "Are subprocessor risk assessments performed before onboarding?", "answer": "Yes", "notes": "Each new vendor reviewed against the same template (purpose, data categories, region, legal basis) before procurement signs the order form." }, { "id": "STA-03", "question": "Are supply-chain attacks (typosquat, dependency confusion) mitigated?", "answer": "Yes", "evidence": "/docs/security/supply-chain.md — internal scope on @cmdash/* packages; release images signed with a Cosign release key pair. No SLSA provenance attestation is produced." }, { "id": "STA-04", "question": "Are CVEs in third-party dependencies monitored continuously?", "answer": "Yes", "evidence": "/docs/developers/dependency-updates.md — Renovate + GitHub Dependabot; severity-based merge cadence." }, { "id": "STA-05", "question": "Is a CycloneDX or SPDX SBOM produced and available?", "answer": "Yes", "evidence": "/docs/security/supply-chain.md — a CycloneDX SBOM is generated per release image by the release script and attached to the image as a Cosign attestation." }, { "id": "STA-06", "question": "Is container provenance verified at deployment time?", "answer": "No", "evidence": "Release images are scanned (Trivy) and signed by digest with a Cosign release key pair, and the SBOM is attached as a Cosign attestation (docs/security/supply-chain.md). Signatures are verified by the release script before the release tag is published, not at deployment time: there is no admission controller (production runs on Lightsail, not Kubernetes), and no SLSA provenance attestation is produced." }, { "id": "STA-07", "question": "Is a Trust Center maintained with public security posture?", "answer": "Yes", "evidence": "/trust/* — landing, security, subprocessors, DPA, disclosure, pen-test, SOC 2 status, and these questionnaires." }, { "id": "STA-08", "question": "Are flow-down obligations imposed on subprocessors via contract?", "answer": "Yes", "evidence": "/trust/dpa — DPA flow-down required for any subprocessor processing customer data." } ] }, { "id": "TVM", "title": "Threat & Vulnerability Management", "questions": [ { "id": "TVM-01", "question": "Are vulnerabilities tracked with severity-based remediation SLAs?", "answer": "Yes", "evidence": "/trust/pentest — Critical: fixed within 7 days of triage or a mitigating control within 48 hours; High: 30 days; Medium: 60 days or a documented acceptance; Low/Informational: 90 days or closed with a written rationale." }, { "id": "TVM-02", "question": "Is dependency scanning continuous?", "answer": "Yes", "evidence": "/docs/developers/dependency-updates.md — Renovate + Dependabot per push and on schedule." }, { "id": "TVM-03", "question": "Is container-image scanning performed pre-deploy?", "answer": "Yes", "evidence": "/docs/security/supply-chain.md — Trivy scan on every image build." }, { "id": "TVM-04", "question": "Are penetration tests performed at least annually?", "answer": "No", "notes": "/trust/pentest — no third-party penetration test has been completed or contracted; planned against OWASP ASVS-L2, not yet scheduled. An annual cadence will be established after the first engagement.", "evidence": "/trust/pentest — no third-party penetration test has been completed or contracted; planned against OWASP ASVS-L2, not yet scheduled. An annual cadence will be established after the first engagement." }, { "id": "TVM-05", "question": "Are threat-intelligence feeds monitored?", "answer": "Compensating Control", "notes": "Subscribed to CSA threat-intel circular and CVE.org feed; ISAC/ISAO membership not yet pursued." }, { "id": "TVM-06", "question": "Are intrusion-detection or anomaly-detection systems deployed?", "answer": "No", "evidence": "No AWS GuardDuty is deployed. An application-level AnomalyEvent mechanism exists (apps/api/src/anomaly-detection/) but it tracks tenant posture-score and risk-count drift, not security/intrusion signals such as login anomalies — see /trust/security." }, { "id": "TVM-07", "question": "Is a responsible-disclosure program published?", "answer": "Yes", "evidence": "/trust/disclosure — security@cmdash.com; 90-day coordinated-disclosure window; safe-harbour." }, { "id": "TVM-08", "question": "Is there a funded bug-bounty program?", "answer": "No", "notes": "/trust/disclosure is honest about this — no funded bounty. Reports are acknowledged per the timelines published there." }, { "id": "TVM-09", "question": "Are zero-day or out-of-cycle patches applied per documented procedure?", "answer": "Yes", "notes": "Emergency hotfix path documented in /docs/cloud-deployment-runbook.md; CI gates not bypassed even for hotfix." } ] }, { "id": "UEM", "title": "Universal Endpoint Management", "questions": [ { "id": "UEM-01", "question": "Are end-user devices accessing production data centrally managed (MDM)?", "answer": "No", "notes": "CMDash does not operate a managed-device (MDM) programme, so this is not enforced or verified centrally. CMDash currently has a single maintainer (see /trust/soc2)." }, { "id": "UEM-02", "question": "Is full-disk encryption enforced on managed endpoints?", "answer": "No", "notes": "CMDash does not operate a managed-device (MDM) programme, so this is not enforced or verified centrally. CMDash currently has a single maintainer (see /trust/soc2)." }, { "id": "UEM-03", "question": "Are screen-lock timeouts enforced?", "answer": "No", "notes": "CMDash does not operate a managed-device (MDM) programme, so this is not enforced or verified centrally. CMDash currently has a single maintainer (see /trust/soc2)." }, { "id": "UEM-04", "question": "Are OS and application patches automated?", "answer": "No", "notes": "CMDash does not operate a managed-device (MDM) programme, so this is not enforced or verified centrally. CMDash currently has a single maintainer (see /trust/soc2)." }, { "id": "UEM-05", "question": "Is anti-malware deployed on managed endpoints?", "answer": "No", "notes": "CMDash does not operate a managed-device (MDM) programme, so this is not enforced or verified centrally. CMDash currently has a single maintainer (see /trust/soc2)." }, { "id": "UEM-06", "question": "Are unauthorized USB / removable media controlled?", "answer": "No", "notes": "CMDash does not operate a managed-device (MDM) programme, so this is not enforced or verified centrally. CMDash currently has a single maintainer (see /trust/soc2)." }, { "id": "UEM-07", "question": "Can devices be remotely wiped on loss / theft?", "answer": "No", "notes": "CMDash does not operate a managed-device (MDM) programme, so this is not enforced or verified centrally. CMDash currently has a single maintainer (see /trust/soc2)." }, { "id": "UEM-08", "question": "Are personal (BYOD) devices restricted from production access?", "answer": "No", "notes": "CMDash does not operate a managed-device (MDM) programme, so this is not enforced or verified centrally. CMDash currently has a single maintainer (see /trust/soc2)." } ] } ] }