Accreditation Dossier — NIST 800-53, OSCAL, and the Path to IL4/IL5

1. The claim

Writ ships with a system security package that, when deployed into an accreditable environment, allows a downstream mission program to file a minor-change request against the platform’s accreditation rather than stand up its own from scratch. Historically this has been an 18-month process with a team of four to six. We reduce it to weeks by:

1. Delivering a pre-drafted System Security Plan (SSP) keyed to NIST SP 800-53 Rev. 5
2. Shipping OSCAL component definitions for every platform service
3. Running the SSDF-aligned supply-chain lane that produces evidence continuously
4. Publishing a documented Type-Authorization template for mission frontends

This paper documents each of those.

2. Control-family coverage

Against NIST SP 800-53 Rev. 5 baseline moderate, the platform’s current coverage breakdown is:

Family	Full name	Writ status
AC	Access Control	Platform-covered (22 controls)
AT	Awareness and Training	Customer-inherits (3 controls)
AU	Audit and Accountability	Platform-covered (16 controls)
CA	Assessment, Authorization, and Monitoring	Platform-covered (9 controls)
CM	Configuration Management	Platform-covered (14 controls)
CP	Contingency Planning	Partial — Velero-based backup is covered; disaster-recovery narrative customer-specific (13 controls)
IA	Identification and Authentication	Platform-covered (12 controls)
IR	Incident Response	Partial — runtime detection via Falco + NeuVector covered; IR playbook customer-specific (10 controls)
MA	Maintenance	Customer-inherits (6 controls)
MP	Media Protection	Customer-inherits (8 controls)
PE	Physical and Environmental Protection	Customer-inherits (20 controls)
PL	Planning	Platform-covered (9 controls)
PS	Personnel Security	Customer-inherits (8 controls)
PT	PII Processing and Transparency	Partial — data-classification primitives covered; policy customer-specific (7 controls)
RA	Risk Assessment	Platform-covered (10 controls)
SA	System and Services Acquisition	Platform-covered (22 controls)
SC	System and Communications Protection	Platform-covered (44 controls)
SI	System and Information Integrity	Platform-covered (23 controls)

2.1 What “platform-covered” means

The platform supplies: the control implementation, the evidence narrative, the runtime enforcement where applicable, and the continuous-control-evidence artifact that demonstrates the control is operating as intended.

2.2 What “customer-inherits” means

The control is not enforceable by software. Physical security (PE), personnel vetting (PS), media protection (MP), and most of AT are properties of the operating environment and the people in it. The SSP includes the customer-inherits narrative template and the evidence-reference placeholder, so the customer completes only the customer-specific portion.

2.3 What “partial” means

The platform provides a starting-point narrative and several enforcement mechanisms, but mission-specific controls require the customer’s policy to complete. For example, IR-4 (Incident Handling) includes our platform-specific incident-handling runbook, but the customer’s mission-wide IR plan must reference it.

3. The supply-chain lane (SSDF mapping)

NIST SP 800-218 (the Secure Software Development Framework, SSDF) organizes secure software practices into four groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). Our supply-chain lane maps to each:

PO — Prepare the Organization

• Organization-wide threat model, published
• Security roles enumerated in the SSP
• Secure development training is a hiring prerequisite

PS — Protect the Software

• Source is signed at commit time (Sigstore gitsign)
• Build artifacts are signed (cosign with ML-DSA-65, Rekor-logged)
• Release artifacts have verified provenance (SLSA v1.0 L3 via Tekton Chains)

PW — Produce Well-Secured Software

• Every commit runs SAST (Semgrep + custom Writ rulesets)
• Every build runs SCA (Grype) against the SBOM
• Every dependency introduction requires license review (we forbid SSPL, BSL, ELv2, RSALv2, Commons Clause)
• Every container is base-imaged on Iron Bank
• Kyverno admission policies enforce signed-only, STIG-compliant, CVE-bounded images at deploy time

RV — Respond to Vulnerabilities

• CISA KEV monitored per release
• Vulnerability SLA published (critical: 24 hours, high: 7 days)
• Security disclosure channel documented ([email protected] with an age1 encrypted inbox)
• VEX documents attached to releases where we mark a vulnerability not-exploitable in our configuration

4. OSCAL component definitions

Each Writ service ships as an OSCAL component-definition document. A component definition enumerates:

• Which controls the component implements
• The implementation status (implemented / partial / planned / alternative)
• The implementation statement (narrative)
• Set-parameters for the customer’s tailoring
• Inherited control dependencies (upstream components this relies on)
• References to evidence artifacts

The customer’s SSP assembles component definitions into a system-security-plan document. Customer-specific tailoring is done in the customer’s tailoring overlay, not by editing the shipped component definitions. This lets Writ update component definitions without disturbing customer-specific content.

5. Continuous control evidence

The evidence-collector service runs as a Kubernetes CronJob. Every 6 hours it walks the cluster state, compares observations against the control-implementation statements in the OSCAL component definitions, and produces a snapshot OSCAL observations document. The snapshot is:

1. Signed with ML-DSA-65
2. Attested with SLSA provenance
3. Archived to the writ-evidence MinIO bucket with a WORM retention policy (default 7 years; customer-tailorable)
4. Indexed in OpenSearch for assessor query

Assessors query by control, by time range, and by tenant. The audit trail for any given control at any given moment is reproducible.

6. Runtime enforcement

Several controls are enforced at runtime, not just documented:

• AC-3 (Access Enforcement) — OPA policy evaluates every authorization decision; denials are logged with the reason phrase.
• AU-12 (Audit Generation) — Every API call emits an audit event. The event includes the SPIFFE identity of the caller, the resource, the decision, and the attestation of the service that emitted it.
• SC-12 (Cryptographic Key Establishment and Management) — OpenBao holds every key; access requires a SPIFFE-identified workload with an explicit policy.
• SC-13 (Cryptographic Protection) — The dcrypto wrapper library is the only approved path to cryptographic primitives. Direct calls to openssl or boringssl in application code are linted as policy violations.
• SI-4 (System Monitoring) — Falco + NeuVector watch the runtime. Policy violations emit to Vector → OpenSearch → on-call pager.
• SI-7 (Software, Firmware, and Information Integrity) — Kyverno admission policy verifies cosign ML-DSA signatures on every incoming image.

7. Type Authorization and the minor-change path

DoD’s Risk Management Framework (RMF) supports Type Authorization: a single accreditation can cover multiple substantially-identical system instances. Writ’s accreditation package is designed around this pattern:

• Platform baseline. The cluster profile at version v0.1.0 (or whichever version the customer is deploying) is the accredited baseline. The baseline is authored in OSCAL and published in the release.
• Customer delta. The customer produces a tailoring overlay that documents mission-specific settings (tenancy model, classification levels served, external integrations). The delta is typically 15–30 pages; a from-scratch SSP for an equivalent system runs 200–400 pages.
• Mission-frontend minor change. A downstream mission frontend targets the customer’s accredited Writ installation. The mission-frontend’s SSP references the Writ platform SSP and supplies only the mission-frontend-specific portions. Typical scope: 5–15 pages.

The net effect: a mission-frontend program office that inherits both the platform and the customer’s Writ installation spends 4–8 weeks on documentation rather than 12–18 months.

8. FIPS 140-3

The fips/v1 attestation predicate is emitted per build and indicates whether the build has been validated against the FIPS 140-3 CMVP program. As of April 2026, validation is in audit-mode rather than enforce-mode; our target for enforce-mode (i.e., Kyverno rejects builds without a valid fips/v1 attestation) is tied to the CMVP certification schedule for the PQC modules we depend on (predominantly a pending oqs-provider validation).

For customers who must deploy FIPS-enforced today, we provide a FIPS-enforced edge-only profile that uses only classical FIPS 140-3 validated cryptography. The tradeoff is that PQC is audit-only until the PQC modules complete validation. Most customers accept this tradeoff; a few prefer the non-FIPS-enforced profile with PQC on-default, because their threat model weights store-now-decrypt-later above FIPS compliance.

9. Compliance narratives (SSP excerpts)

This section of the paper, in the customer bundle, contains the verbatim control-implementation narratives for every “platform-covered” control. It is lengthy (~180 pages) and not appropriate for a public abstract; the full narrative set is provided under NDA during accreditation planning.

10. How to run an accreditation review against this package

Suggested assessor workflow:

1. Read Sections 1–8 of this paper and the SSP (the narrative is modular; read by family).
2. Pull the OSCAL system-security-plan document and the per-service component-definition documents into an OSCAL-aware tool (e.g., OSCAL Viewer, Compliance Trestle).
3. Query the writ-evidence store for a date range of interest; sample control-family observations.
4. Verify a sample of cosign signatures against the Rekor transparency log.
5. Spot-check runtime-enforced controls (AC-3, AU-12, SC-13, SI-4, SI-7) against a live cluster.
6. Review the customer tailoring overlay; focus on the customer-specific delta.

A typical assessor familiar with OSCAL tooling can complete a Writ platform-baseline review in 4–6 weeks. Accreditation of the full system (platform + customer tailoring + mission frontend) is 8–16 weeks in total, dependent on customer and mission-frontend readiness.

11. References

• NIST SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems and Organizations
• NIST SP 800-171 Rev. 3 — Protecting Controlled Unclassified Information in Nonfederal Systems
• NIST SP 800-218 — Secure Software Development Framework (SSDF)
• DoD RMF Knowledge Service — Type Authorization guidance
• OSCAL 1.1.x specification — pages.nist.gov/OSCAL
• DISA Cloud Computing SRG rev 4
• Writ Architecture Reference — see WP-001
• Writ Federation Architecture — see WP-004