Trust & Compliance

Security & Compliance

The standards DARA is built against and the results of our internal security assessment.

System Security Plan

DARA Cybersecurity Assessment

Assessment date: June 27, 2026 · re-audited July 5, 2026
Performed by: Internal security review (automated, evidence-based)
Scope: Application architecture, authn/z & tenant isolation, CUI/FCI data handling, secrets management, database & RLS, API & webhook security, AI/LLM data flow, file uploads, dependencies & supply chain, cloud/deployment configuration. The July 5, 2026 CMMC L2 re-audit re-examined the surface added since June — document/annotated-response exports, per-review uploads, personas as a review lens, and trial enforcement — and confirmed the prior remediations (DARA-001…019) remain intact with no regressions.
Method: Read-only static review of the repository, configuration, and dependency tree. No exploit code was run against production or third-party services. Every control is rated by repository evidence only; items not determinable from the repo are marked Undetermined.
Evidence standard: Findings cite file paths and line references. Configuration and governance items that cannot be confirmed from the repository are explicitly marked Unverified rather than assumed compliant.

High open

Moderate open

Low open

Remediated

Standards & Frameworks

NIST SP 800-171 Rev. 3

Primary control baseline

Protecting CUI in Nonfederal Systems

The baseline requirements for safeguarding Controlled Unclassified Information on contractor systems.

NIST SP 800-171A Rev. 3

Assessment methodology

Assessing Security Requirements for CUI

The assessment procedures used to evaluate each 800-171 requirement.

NIST SP 800-53 Rev. 5

Reference control catalog

Security and Privacy Controls

The comprehensive control catalog from which 800-171 derives; used for control mapping.

NIST CSF 2.0

Program-level alignment

Cybersecurity Framework

Outcome-based functions — Govern, Identify, Protect, Detect, Respond, Recover.

CMMC 2.0 (Level 2)

Readiness target

32 CFR Part 170

DoD certification model; Level 2 mirrors the 110 requirements of NIST SP 800-171.

OWASP

Secure-coding standard

ASVS · Top 10 · API Top 10 · LLM Top 10

Application, API, and LLM security verification standards used for code-level review.

CIS Benchmarks

Configuration baseline

Cloud & Platform Hardening

Provider hardening guidance for cloud and platform configuration.

Control Posture — NIST SP 800-171 Rev. 3 Families

Family	Status	Observation
Access ControlAC	Partial	Per-tenant RLS on all tenant tables under a least-privilege non-BYPASSRLS app role (company_id GUC per request); anon/authenticated REST access revoked; platform-admin via env allow-list (no source-embedded identities) with audited admin actions (DARA-010); deactivated accounts now fail closed across the app (DARA-026); app-layer companyId scoping retained as defense-in-depth. Remaining: a cross-department authorization gap on some child mutation actions (DARA-025) and a per-user platform-admin DB role for finer control.
Awareness & TrainingAT	Not implemented	No security training program evidenced in the repository.
Audit & AccountabilityAU	Partial	Append-only audit trail (dara_audit_log) records actor/action/target/time for security-relevant events (sign-in/provisioning, authz + BYOK-key changes, persona changes, CUI document/evaluation handling, billing). CUI export/egress paths — matrix/report exports, AI pass re-runs, and the annotated export — are now audited (DARA-024, DARA-030). Remaining: an admin-only, per-company audit viewer (planned under Team), a defined retention/review policy (DARA-041), and log review/alerting.
Configuration ManagementCM	Partial	Good .gitignore; single pnpm lockfile (frozen in CI); CI security gates in place (secret scan, dependency audit, SAST, SBOM); tracked migration baseline + documented two-layer schema source of truth (DARA-017). Remaining: enable branch protection on main so the CI gates actually block deploys, which today run independently of the Vercel deploy (DARA-023), plus automated RLS-drift detection (DARA-035).
Identification & AuthenticationIA	Partial	Supabase Auth with Google SSO (OAuth/PKCE) and email+password; "remember me" session controls; committed DB credential remediated (env, rotated, history-purged). MFA is available via the identity provider but not yet enforced in code or at the project level (DARA-031), and password policy/lockout needs verification (DARA-040) — both required for CMMC L2.
Incident ResponseIR	Not implemented	No incident response plan evidenced.
MaintenanceMA	Undetermined	No maintenance procedure evidenced in the repository.
Media ProtectionMP	Partial	BYOK keys and CUI extracted text both encrypted at rest (AES-256-GCM; DARA-009); private storage bucket; solicitation delete now removes all stored CUI blobs, no longer orphaning files (DARA-027). Remaining: a formal media sanitization/retention policy and a tenant-level right-to-delete / CUI purge (DARA-043).
Personnel SecurityPS	Not applicable	Organizational process; not assessable from the repository.
Physical ProtectionPE	Not applicable	Inherited from cloud providers (Vercel / Supabase / AWS).
Risk AssessmentRA	Partial	This assessment performed; automated dependency audit + CodeQL SAST run in CI on every push/PR. Remaining: continuous/runtime vulnerability scanning and a recurring risk-assessment cadence.
Security Assessment & MonitoringCA	Partial	Point-in-time review plus per-push CI scanning (secret, dependency, SAST). A System Security Plan is documented in-app (/app/security/plan). Remaining: continuous runtime monitoring and alerting.
System & Communications ProtectionSC	Partial	Platform TLS; security headers + CSP; DB TLS enforced (DARA-014); CUI encrypted at rest (DARA-009). CUI→LLM egress: commercial endpoints retained with compensating controls — boundary notices, BYOK option, per-run audit (DARA-007, risk accepted); zero-data-retention agreements on platform keys pursued offline. Remaining (SC-5): no application-layer rate limiting / WAF (DARA-021) and a decompression-bomb guard on document extraction (DARA-032); a nonce-based CSP to drop unsafe-inline (DARA-033).
System & Information IntegritySI	Partial	LLM input fenced (incl. the annotated-export path, DARA-024); React output escaping sound; automated dependency audit + CodeQL SAST in CI. Remaining: Next.js 14.2.35 now carries unpatched high-severity advisories (SSRF, middleware bypass) requiring a 14→15 upgrade (DARA-022), and a latent dangerouslySetInnerHTML sink to remove (DARA-038).
PlanningPL	Partial	System Security Plan drafted as a living in-app document (/app/security/plan) mapping implemented controls to NIST families, with the findings register serving as the POA&M. Remaining: formal sign-off and a maintenance cadence.
Supply Chain Risk ManagementSR	Partial	Frozen pnpm lockfile, high-severity dependency audit, and a CycloneDX SBOM generated in CI. Remaining: scan the SBOM + add a license gate rather than only generating it (DARA-037), SHA-pin third-party GitHub Actions (DARA-036), and artifact provenance/signing.

Verified Strengths

A July 2026 re-audit confirmed the prior remediations (DARA-001…019) hold with no regressions: all 26 tenant tables carry per-tenant RLS + least-privilege grants, and every data path added since June (exports, annotated export, per-review uploads) routes through the tenant transaction.
Application-layer tenant scoping by companyId is applied consistently; no live cross-tenant (IDOR) query was found in the application data plane.
No LLM tool/function calling is configured, which limits the blast radius of prompt injection to output manipulation.
No client-exposed secrets; only public keys carry the NEXT_PUBLIC_ prefix.
CSRF posture is adequate: state changes use Next.js Server Actions and the Stripe webhook verifies its signature.
React output escaping is relied on throughout and no eval is used; the single dangerouslySetInnerHTML sink renders only static literals and is slated for removal (DARA-038).
BYOK provider keys are encrypted at rest with AES-256-GCM (random IV + auth tag).

Assessment Findings

A point-in-time assessment was completed on June 27, 2026 · re-audited July 5, 2026. Findings are tracked and remediated on the schedule below. Detailed technical findings are restricted to platform administrators.

6 High4 Moderate12 Low

This page reflects an internal, evidence-based review and is not a formal certification or third-party attestation. Items that could not be confirmed from the codebase are treated as unverified rather than compliant.