Shift Left on Reciprocity

Federal compliance uses one word, reciprocity, for two different things. One is a government decision: an authorizing official accepts a risk determination, signs an authorization to operate, and other agencies rely on it instead of repeating the work. The other is an architecture decision: expressing a single control implementation, authored once, in the shape each framework asks for. The first is slow on purpose, and no amount of engineering speeds it up. The second can be built today, and most of the cost people blame on missing reciprocity is really the absence of the second.

This is a field report on building the second. The system is a real, running site whose every deploy derives a set of signed, machine-readable compliance documents from one source of truth, re-checks them against the live infrastructure, and publishes them where anyone can verify them with curl, jq, and cosign. It is a self-attested proof of concept (one operator, one cloud account, no federal data, no agency sponsor), so it demonstrates the mechanism, not an authorization. The mechanism is what generalizes; the single-site specifics are stand-ins.

Shifting reciprocity left

Compliance is normally a back-end activity. You build the system, then afterward you assemble a security plan that describes it, hand the package to an assessor, and wait. The plan is a snapshot the moment it is written and begins drifting from the running system immediately, and reconciling that drift is where most assessment effort, and most audit findings, go.

Shifting reciprocity left means moving evidence production into the pipeline that builds and runs the system, so the compliance state is a continuously maintained output rather than a periodic document. Concretely, that is five moves:

• One canonical inventory. Every deploy inventories the live system, its resources and dependencies and build provenance, into a single machine-readable signal. That signal is the source of truth; nothing downstream is hand-maintained.
• Derived, not authored, documents. The security plan, the plan of action and milestones, and the vulnerability report are generated from that inventory on every deploy. A document cannot drift from a system that regenerates it from the system's own state.
• Authored once, projected many. The control evidence is written one time, against NIST 800-53, and projected into whatever shape a framework wants (FedRAMP, CMMC, a state program) through published crosswalks. Supporting another framework costs a mapping file, not another control-writing project. This is evidence reciprocity: the same facts, expressed in many vocabularies, composed rather than rewritten.
• Fail closed, then sign. A reconciliation gate runs before anything is published and refuses the build unless every document carries the same inventory identity and this commit's hash, and unless the live account reconciles against the inventory. Only past that gate are artifacts signed and published.
• Re-verified at runtime. A scheduled job re-evaluates the live configuration against the same policy the deploy gate used and re-signs the result every day, so the published state reflects the system as it is now, not as it was at the last code change.

The result is a compliance posture that is continuous, tamper-evident, and verifiable by a third party without taking the producer's word for it. Those are the properties reciprocity is meant to deliver, produced as a byproduct of shipping.

The system, and how it proves each control

The system is samaydlette.com: a static personal website on AWS that doubles as the continuous-compliance pipeline described here, plus a small authenticated web application behind it. The authorization boundary is a set of managed AWS services, deployed from GitHub Actions over OIDC: CloudFront and S3 for the site, API Gateway and Lambda for the application, Cognito for application sign-in, Route 53 (DNSSEC-signed) for DNS, ACM for TLS, KMS for keys, Secrets Manager for the one application secret, and CloudWatch for logs. Physical, environmental, and media-protection families are inherited from AWS's own FedRAMP authorization and cited, not re-implemented. The system is rated FIPS 199 Moderate / FedRAMP 20x Class C throughout.

What follows is how it meets each major group of control requirements, and where the machine-readable evidence for each lives. The grouping is by function rather than by family number, but every claim below maps to specific controls in the generated security plan.

Identity, authentication, and access (IA, AC). Application users sign in through Cognito with a password and a time-based one-time-password second factor; accounts are operator-created, not self-registered. The deploy pipeline authenticates to AWS through GitHub OIDC, a short-lived, workload-bound credential, so there is no long-lived access key to leak or rotate. Inside AWS, permissions follow least privilege: the deploy role carries only the actions it needs, policies attach to groups rather than users, and a separate read-only role exists for assessment access with an explicit deny on secret retrieval. The IAM policy bodies travel in the inventory as SHA-256 hashes, so a reviewer can confirm the deployed policy matches the documented one without the policy text being public.

Continuous monitoring and assessment (CA, RA, SI, AU, SR). This is the center of the system. A scheduled Lambda re-evaluates the live AWS configuration every day against the exact compiled policy the deploy gate runs, and re-signs the result, so drift between code changes surfaces within a day rather than at the next audit. Dependencies are scanned on every build (Grype and Dependabot) and the application is scanned dynamically (a monthly OWASP ZAP run); findings flow into a vulnerability report that scores each on the FedRAMP 20x PAIN scale, checks it against the CISA Known Exploited Vulnerabilities catalog, and blocks the deploy if anything exceeds the Class C remediation tolerance. Audit logs land in CloudWatch with a year's retention. The reconciliation gate is itself a continuous-assessment control: it fails the build when the documents and the live account disagree. Supply-chain integrity is covered by a software bill of materials and the signing chain below.

Cryptographic protection (SC). Everything in transit is TLS: CloudFront redirects to HTTPS and negotiates TLS 1.2 or better with an ACM-issued certificate, and origin connections are HTTPS-only. Everything at rest is encrypted; buckets and log groups use SSE-KMS under four customer-managed keys, one each for data at rest, the DNSSEC key-signing key, the runtime signing key, and the application secret. DNS is DNSSEC-signed. The compliance artifacts themselves are signed two ways: deploy-time documents with Sigstore keyless signing (a short-lived certificate bound to the GitHub workflow identity and recorded in the public Rekor transparency log, with no private key to custody), and the daily runtime signal with an ECDSA key in KMS whose public half is published for anyone to verify against.

Configuration and change management (CM, SA). The entire system is defined in Terraform; there is no console-clicked infrastructure. Every change takes one path: a pull request, an Open Policy Agent evaluation of the Terraform plan and the rendered site that blocks on any violation, then an apply. Each commit is tagged with a change-significance type, and the git history is the change record. Because the security plan, the POA&M, and the vulnerability report are generated from the inventory on every deploy, they cannot describe a configuration the system no longer has. The usual gap between a security plan and the live system is closed automatically. Infrastructure-as-code scanners (Checkov, tfsec) run in the same pipeline, and any finding is either fixed or recorded as a dispositioned, risk-accepted item with a written rationale, never silently dropped.

Incident response and contingency (IR, CP). Detection is the daily drift check and the build-time gates; a documented incident-response plan covers the human side. Recovery leans on the same property that makes the documents trustworthy: the whole system is reproducible from source. The site content, the infrastructure, and the compliance pipeline all live in one Git repository, so rebuilding is a terraform apply rather than a restore-from-backup exercise, and S3 versioning protects the served content. The compliance Lambda has a dead-letter queue so a failed run is captured rather than lost. The single-region footprint is a deliberate, documented residual for a system at this impact level, not an oversight.

Boundary protection (SC-7, SC-5). Nothing is exposed to the internet directly; all traffic arrives through CloudFront and API Gateway, both managed interfaces, with AWS Shield Standard and request throttling in front. A web application firewall is intentionally declined, because the attack surface is a static site plus a single throttled, authenticated API; its incremental layer-7 filtering is documented as a residual rather than pretended away.

One implementation, many frameworks. All of the above is written against NIST 800-53 Rev 5, once. From that single set of control implementations (115 hand-written, the rest resolved by family-level defaults, 333 in all), the pipeline projects a security plan for each framework a reader might ask about: FedRAMP Rev 5 Moderate (333/333 requirements addressed), FedRAMP 20x Class C, NIST 800-53 Rev 4, CMMC Level 2 (110/110), GovRAMP Moderate with the CJIS overlay (339/339), and TX-RAMP Levels 1 (122/122) and 2 (322/322). Each is a profile or a crosswalk plus one projection run; none required rewriting a control. A consuming organization gets the same treatment in reverse: a single check of its own configuration reports every framework requirement that check satisfies at once. The package is built to conform to FedRAMP's Consolidated Rules for 2026, mechanized ahead of the deadline rather than after it.

Why this matters beyond the audit

The reason to build this is not to pass an audit faster, though it does that. It is that a compliance state produced this way is trustworthy in a way a document is not. Anyone can pull the signed artifacts from a URL and verify, independently, that they were produced by the named pipeline, that they match the live system, and that they are current as of today. Trust stops being a matter of believing the producer and becomes a matter of checking math. That check is one command: scripts/verify-published.sh in the public repository fetches the live artifacts, verifies their signatures against the pinned workflow identity, and reconciles them — from the public internet, with no credentials.

That property is exactly what two adjacent markets are missing. Cyber-insurance underwriting and third-party risk management both run on stale questionnaires and point-in-time attestations, because current, trustworthy, machine-queryable data about a system's actual posture has not existed. A continuously published, signed inventory and vulnerability report is that data. Whether underwriters and risk teams consume it is a question of adoption, not of engineering, since the feed is already there.

And the cost is the headline. The whole pipeline runs for a few dollars a month. Most of what gets blamed on a lack of reciprocity is not the government's slow, deliberate authorization decision, which should stay slow and deliberate. It is the absence of the evidence layer underneath it, the part any team can build without anyone's permission. This builds it. The authorization reciprocity stays where it belongs; the evidence reciprocity is available now.