Live Trust Dashboard

Renders the live compliance artifacts published at /.well-known/ on this site: the deploy-time KSI signal (Sigstore-signed), the runtime KSI signal (re-validated daily by an AWS Lambda), the NIST OSCAL Rev 5 System Security Plan, the NIST OSCAL Plan of Action and Milestones, the FedRAMP 20x VDR report, and the FedRAMP IIW (SSP Appendix M) — all derived from the same canonical inventory. The page is presentational; the JSON and CSV documents are the source of truth.

Direct links: KSI signal · OSCAL SSP · OSCAL POA&M · VDR report · IIW (CSV).

For the architecture and rationale, see Automated Security Compliance. For the FedRAMP authorization boundary that scopes what is and is not in this picture, see the boundary diagram.

Trust Status

Deploy-time signal

checking…

Last deploy

—

Last runtime check

—

Drift

—

Framework Coverage

One NIST 800-53 Rev 5 control hub, projected to each framework through published crosswalks and profiles — the same evidence expressed in many shapes (see the methodology). These figures are self-attested coverage derived from the OSCAL SSP below; they demonstrate evidence reciprocity, not a government Authorization/Certification (see the authorization boundary).

FedRAMP Rev 5 Moderate

333/333

native baseline · 333 controls (158 implemented · 96 inherited/shared · 79 N/A)

FedRAMP 20x — Class C

continuous

KSI signal + VDR · Class C remediation SLAs (the 20x “Certified” Moderate-equivalent)

GovRAMP Moderate + CJIS

339/339

CJIS overlay N/A (no CJI processed); beyond-Moderate controls dispositioned with evidence

TX-RAMP Level 1

122/122

projected via the Rev 4→5 bridge

TX-RAMP Level 2

322/322

beyond-Moderate enhancements dispositioned (N/A or implemented with evidence)

CMMC Level 2

110/110

800-171 Rev 2 · 110 dispositioned · a consuming OSC inherits 77/110 (SRM; 3.12.4 is the customer's own SSP duty)

Verify it yourself

You do not have to trust this site. Every claim it makes is published under /.well-known/ and signed by the exact GitHub Actions workflow that produced it, recorded in the public Sigstore/Rekor transparency log. A stranger can reproduce the verdict from the public internet — that reproducibility is the whole point.

One command, from a clone of the public repository:

scripts/verify-published.sh          # or: make verify-published

It fetches the live artifacts and runs three layers, then prints PASS: the Sigstore signatures and SLSA provenance against the pinned workflow identity, the dependency-free in-toto claims check, and the AWS-free cross-artifact reconciliation (one inventory, one commit, POA&M and VDR coherent). To verify a single artifact by hand with nothing but cosign:

curl -sO https://samaydlette.com/.well-known/ksi-signal.json
curl -sO https://samaydlette.com/.well-known/ksi-signal.bundle

cosign verify-blob \
  --bundle ksi-signal.bundle \
  --certificate-identity 'https://github.com/sam-aydlette/samaydlette.com/.github/workflows/deploy-with-opa.yml@refs/heads/main' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  ksi-signal.json

The trust roots are Sigstore (Fulcio + Rekor) and the pinned public identity — not this site, and not the verifier script. Honest limit: the two live-state checks — that the inventory is complete against live AWS, and that live resource tags match the inventory — need cloud credentials, so the provider runs them on every deploy and an outsider verifies the signed evidence, not the live account. Full walkthrough →

Deploy ↔ Runtime Divergence

raw JSON

The deploy gate evaluates a Terraform plan; a Lambda re-evaluates the live account daily against the same compiled policy. This is the comparison between them, computed by the runtime emitter and carried inside the signed signal — not recomputed by this page.

Two failure modes are kept apart deliberately. A regression is a KSI that passed the deploy gate and is failing against the running system: real drift, and it blocks the next deploy. An unassessed KSI is one the evaluator could not reach a verdict on, usually a missing read permission — a fault in the observer rather than the system, which is reported but never treated as drift.

Loading…

Vulnerability Trend

raw JSON

Cross-run vulnerability trend, keyed by CVE: a CVE seen by several scanners or across several components is one finding with several assets. Each VDR build appends a point. This is the automated trend analysis RA-5(6) asks for, published openly.

KSI Signal (deploy-time)

raw JSON · Sigstore bundle · schema

Metadata

Loading…

Components

Validations

Populated in CI from the OPA gate.

Loading…

OSCAL Rev 5 SSP

raw JSON

Metadata

Loading…

Implementation status distribution

Implemented requirements

status origination search

Loading…