The Diagram
The diagram is a single SVG, rendered above and also published at /assets/diagrams/authorization-boundary.svg. GitHub renders it natively when linked from any Markdown source; FedRAMP reviewers can download or print it as a single self-contained image with embedded legend and data flow table.
The conventions follow both the FedRAMP A FedRAMP Authorization Boundary living document and the standard ABD/DFD elements that FedRAMP reviewers expect: red dashed boundary outline, comprehensive legend, FIPS 140-2/3 validated cryptographic modules in list view, ports/protocols/authentication on every flow, distinguishing privileged from non-privileged access, and clear visual differentiation between FedRAMP-authorized and non-authorized external services.
The Four Rules of Thumb, Applied
The FedRAMP authorization-boundary guidance gives four Rules of Thumb (ROTs) for what is in versus out of scope. Applied to this system:
ROT #1 (in — federal information processed, stored, or transmitted). The PoC has no federal customer and no federal information today, so by strict reading of ROT #1 the boundary could be empty. The architecture is built to be ready if federal information ever enters the system, and the metadata definition in Key Concept #3 (data describing CIA — logs, audit trails, vulnerability reports) applies directly to the artifacts published at /.well-known/. Those artifacts are treated as in-scope so the boundary reflects the architecture rather than the current emptiness of the data tier.
ROT #2 (in — external services that affect CIA). Six classes of external services without a FedRAMP authorization are inside the boundary because they affect the CIA of system artifacts: Sigstore Fulcio, Sigstore Rekor, GitHub OIDC, GitHub repo plus Actions runners, Duo, and the vulnerability-metadata sources (GitHub Advisory Database, CISA KEV catalog). Each is named on the diagram with its CIA-impact dimension and compensating controls documented in docs/policies/.
ROT #3 (out — corporate services that do not affect CIA). The operator’s personal email, calendar, banking, and other personal SaaS are out of scope because they do not handle CIA-impacting data for the CSO. If the operator ever uses corporate email to relay vulnerability information about the system, that email service comes back into scope per ROT #2; this is acknowledged operationally and avoided by routing all vulnerability discussion through the public GitHub issue tracker and the published VDR report.
ROT #4 (out — dev environments without federal info). The operator’s local development machine is out of scope. There is no federal information on it today; if the system’s data scope ever changes, the dev machine is reassessed.
Leveraged vs. External (Without ATO)
Leveraged (green band). AWS underlying infrastructure is leveraged from the AWS East/West Moderate FedRAMP authorization (Package ID AGENCYAMAZONEW). Compliance with FedRAMP / NIST SP 800-53 controls is inherited from the AWS authorization package and the AWS Customer Responsibility Matrix. The PE, MA, MP, and parts of CP and SC families are inherited in the published OSCAL SSP.
External without ATO (amber band). The Sigstore stack, the GitHub identity and CI/CD layer, Duo, and the vulnerability-data sources have no separate FedRAMP authorization. They are inside the boundary because each affects CIA, but the CSP owns the responsibility for any control not provided by the underlying service. Compensating controls per service are documented in the relevant family policies (Sigstore in docs/policies/sc-policy.md; GitHub identity in docs/policies/ia-policy.md; Duo in docs/policies/ac-policy.md and the Secure Configuration Guide; vulnerability sources in docs/policies/ra-policy.md).
FIPS-Validated Cryptographic Modules
The diagram lists every FIPS 140-2/3 validated module in scope, per the FedRAMP ABD convention.
Inherited from AGENCYAMAZONEW. AWS KMS is FIPS 140-3 Level 3 (HSM-backed CMKs) and is the at-rest encryption module for S3 SSE, EBS, and Secrets Manager in this system. ACM TLS termination on CloudFront uses FIPS-validated cipher suites with TLS 1.2+ enforced. S3 server-side encryption (AES-256) is delivered via the KMS-backed module.
External, no FedRAMP ATO. The Sigstore signing chain uses the FIPS-approved ECDSA P-256 algorithm, but the Fulcio and Rekor implementations are not FIPS-validated cryptographic modules. The compensating control is the public Rekor transparency log: integrity is anchored in independent observation rather than module validation. This is documented as an awareness item rather than a remediation gap because the threat model is "anyone can verify, including via independent Rekor mirrors" rather than "trust the cryptographic module."
Cross-cutting. AES-256-GCM (S3, EBS) for data at rest. ECDSA P-256 for Sigstore signatures. SHA-256 for content hashing across the canonical inventory. TLS 1.2+ on every public endpoint (CloudFront, AWS APIs, GitHub, Sigstore, Duo).
Data Flows (A–G)
The diagram lettered arrows match the data flow table in the SVG legend. A few flow-level notes that won't fit on the table:
Ingress is narrow. The only externally-initiated ingress to the boundary is flow A: the operator pushing source code to the GitHub repository, authenticated by username + password plus Duo MFA. There is no agency-customer ingress because there is no agency-customer surface. There is no other inbound connection that crosses the boundary.
Egress is also narrow. The only egress is flow G: CloudFront serving public site content and /.well-known/ artifacts to anonymous readers over TLS 1.2+. There is no other outbound flow that exits the boundary; the daily runtime cycle (flow F) is internal.
Privileged versus non-privileged access. The diagram and table mark each authentication context. Privileged: operator (root + admin), GitHub Actions deployer (Terraform apply, S3 sync, Lambda update). Non-privileged: Lambda runtime IAM role (read-only on three S3 config APIs and one CloudFront distribution; write to one S3 key). Anonymous: public Internet readers. The privileged-versus-non-privileged distinction is the FedRAMP DFD convention; it makes scope-creep on the runtime principal mechanically visible.
POA&M cross-references. Flow B (GitHub Actions → AWS APIs) currently uses long-lived AWS access keys; migration to GitHub OIDC role assumption is tracked as POAM-001. Until that closes, an operator-rotation event is the standing privilege boundary.
Related FedRAMP Diagrams (Status)
The FedRAMP authorization-boundary guidance asks for four data-flow diagrams. Sized to this system:
- Federal customer user authentication logical data flow: not applicable. No federal customer accounts exist; no end-user authentication surface is implemented.
- Administrative and support personnel authentication logical data flow: covered by flows A and B in the diagram above.
- System application data flow within the proposed cloud authorization boundary: covered by flows C, D, and F in the diagram above.
- System application data flow to all leveraged and interconnected systems: covered by flows B and E in the diagram above (AWS leveraged path; Sigstore signing chain).
A separate network diagram in the InfusionPoints sense (subnets, network devices, DNS server locations) is minimally relevant for this system: there are no VPC subnets to depict (Lambda runs outside any VPC; S3 and CloudFront are managed services), there are no operator-controlled network devices, and DNS authority is the Route 53 hosted zone shown in the CSO band of the diagram above. If the system ever moves into a VPC or adds private network components, a separate network diagram is added then.
Agency-Specific Considerations
The guidance closes with a note that agencies may impose additional security requirements beyond the FedRAMP baseline. None apply today. If the system were ever to onboard a federal customer with privacy-control requirements, foreign-national handling restrictions, or other agency-specific overlays, the boundary is revisited and the OSCAL SSP regenerated to reflect the additions.
Source for the rules and definitions on this page: