Every CMMC Level 2 engagement we've watched from the outside ends the same way: a 400-page Word document, hand-assembled by a consultant, shipped to an assessor who prints it, highlights the gaps, and hands back a POA&M in a separate document. Six months later the infrastructure has changed and the SSP hasn't.
That's not a compliance artifact. It's a snapshot of someone's intentions on a Tuesday in March.
When aviation people have to argue to a regulator that their flight control software is safe, they don't hand over a 400-page document. They hand over a Goal Structuring Notation (GSN) diagram: a tree of claims where every leaf points at something machine-verifiable. A test result. A formal proof. A code review signature. If you want to argue any node in the tree, you argue about the evidence, not the prose.
CMMC L2 is no different. The claim "we control access to CUI per AC.L2-3.1.1" is just a goal. Decompose it:
iam_root_hardware_mfa_enabled — CI run #8421, commit e4279bc, 0 findings.aws_iam_user — 12 principals, all with password policy matching Terraform module iam-access-controls@v1.4.2.ac-l2-3.1.1.rego — 100% of 47 API Gateway endpoints require IAM auth.Each Solution node is a hash. Each hash resolves to a specific pipeline run. If the infrastructure changes and the evidence goes stale, the assurance case shows it — immediately, not six months later at the next assessment.
Pick any CMMC L2 control, say AC.L2-3.1.1. Here's the component-definition fragment that feeds our SSP assembly:
{
"control-implementations": [{
"source": "trestle://registry/nist-800-171r2/v1.0.0/catalog.json",
"implemented-requirements": [{
"control-id": "ac-l2-3.1.1",
"statements": [{
"by-components": [{
"description": "AWS IAM enforces least-privilege access...",
"props": [
{"name": "verification-method", "value": "prowler:iam_root_hardware_mfa_enabled"},
{"name": "verification-method", "value": "steampipe:aws_iam_user"},
{"name": "verification-method", "value": "opa:ac-l2-3.1.1.rego"}
]
}]
}]
}]
}]
}
The trestle:// URI resolves against our pinned OSCAL registry — every assessment citation is reproducible down to the sha256 of the catalog version we built against.
The GSN fragment associated with the same requirement declares the Solution nodes, each pointing at a CI job output that lives in the git history. No prose. No ambiguity. When prowler:iam_root_hardware_mfa_enabled returns non-zero, the assurance case fails that leaf and the POA&M entry writes itself.
Every infrastructure commit runs the compliance gate. If a Terraform change violates the control mapping, the PR fails before it merges. The SSP is never more than one commit behind reality.
Failed evidence nodes roll up into a POA&M entry with the check ID, the last-passing commit, and the responsible Terraform module. It's the same data your engineers already have in their CI logs — we just promote it into assessor-legible artifacts.
Year one: the assessor reviews the whole tree. Year two: they review the diff since last year, because every artifact is hashed and dated. A 90-day re-assessment becomes hours, not weeks.
We don't bill hourly for SSP writing. We bill for pipeline ownership — maintaining the component-definitions, updating the registry when NIST ships Rev 3, and running the detect/respond stack in your authorization boundary. The SSP is a build artifact. Like your Docker images.
We're not claiming a C3PAO will love OSCAL on first look. Adoption is uneven. The DoD has signalled OSCAL as the target but hasn't mandated it. So our deliverable includes the assembled-and-rendered markdown SSP and the underlying OSCAL artifacts. The markdown passes the paper test. The OSCAL earns points on technical maturity.
We're also not claiming this eliminates narrative. There are controls — insider threat awareness, for instance — where the evidence is a training record. Narrative is fine when it's the right evidence. What's not fine is narrative as a substitute for machine-verifiable evidence when machine-verifiable evidence exists.
GRC tooling built on "questionnaire + policy PDF" assumes the SSP is a document. Our stack assumes the SSP is the output of a continuously-running integrity argument. That's a different primitive. Different primitive, different moat.
If you're a DIB SMB with an assessment window in 2026 and you want to see what your SSP looks like when it's code rather than prose, start with a 30-minute scan of your infrastructure. We'll hand you back the first three component-definitions.