Authorization Boundary — samaydlette.com

The Live Map

The map below is generated, not drawn. Every deploy builds it from the signed canonical inventory: each component is placed by a classification I maintain (which zone and group it belongs to, what exists but is not inventoried, and the data flows between them), and connected to the components its configuration references, from Terraform state. The deploy signs it, and the reconciliation gate refuses to publish it unless it describes exactly that build's inventory. I prototyped the approach with RAMPART on TAP — The Analogy Platform, which now corroborates the map independently: it collects the account straight from the AWS APIs, and the comparison is published beside the map.

That is the point of generating it. A component no classification rule places fails the deploy until it is classified. An AWS resource missing its classification tags is flagged. A data flow whose endpoint is not in the inventory is reported, and so is a data flow the classification lists whose endpoints do not match a real component. Select a flow to trace it, or any component for its classification, findings and the flows through it.

Text view of the live map: components and data flows

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 external dependencies 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 (the operator’s virtual TOTP MFA), 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. The operator email also receives the evidence SLA alarm notifications (flow I) and stays out of scope. The notifications carry alarm metadata only: no evidence content, vulnerability findings or credentials. The alerting controls themselves, the alarms and the encrypted SNS topic, are inside the boundary. Findings stay in the GitHub issue and the published VDR.

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 FedRAMP Certified Class C package (Package ID AGENCYAMAZONEW). Compliance with FedRAMP / NIST SP 800-53 controls is inherited from that 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). The Silk Reeling application no longer calls the Anthropic API: its optional LLM-written feedback is customer-configurable and disabled in this deployment (SCN-2026-006).

FIPS-Validated Cryptographic Modules

The map's text view lists every FIPS 140-2/3 validated module in scope, per the FedRAMP ABD convention. This section is also the system's CR26 Cryptographic Module Use record: it documents each module and whether it is validated under the NIST Cryptographic Module Validation Program (CMU-CSO-CMD). For Class C, validated modules are used for the sensitive cryptography — at-rest encryption and signing run on the FIPS 140-3 AWS KMS HSM (CMU-CSO-UVM, a SHOULD) — with the non-validated Sigstore implementations carried as a documented residual. CMU-CSO-CAT (defaulting agency tenants to validated modules) is N/A: the offering has no agency tenants. The machine-readable module list is also rolled up in the Certification Package Overview at /.well-known/certification-package-overview.json.

Inherited from AGENCYAMAZONEW. AWS KMS is FIPS 140-3 (HSM-backed) and is the validated module behind every customer-managed key in the system. Four customer-managed CMKs run on it: one encrypts CloudWatch Logs and the compliance Lambda's environment, one encrypts the Silk Reeling application’s Lambda environment and logs, one is the ECDSA P-256 key that signs the daily runtime signal, and one is the ECDSA P-256 DNSSEC key-signing key. The public website and access-log buckets — which hold only public or public-derived content — use S3 server-side encryption with AES-256 (SSE-S3, AWS-managed keys), the appropriate at-rest control for public data; the application persists no user pose/movement data, because pose extraction runs client-side in the browser and nothing is stored. (There is no EBS in this serverless architecture.) ACM TLS termination on CloudFront uses FIPS-validated cipher suites with TLS 1.2+ enforced.

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 for data at rest. ECDSA P-256 for Sigstore signatures and for the runtime-signal and DNSSEC signing keys. SHA-256 for content hashing across the canonical inventory. TLS 1.2+ on every public endpoint (CloudFront, API Gateway, AWS APIs, GitHub, Sigstore, Duo).

Data Flows (A–I)

The lettered flows on the map match its data flow table. A few flow-level notes that won't fit on the table:

Ingress. Two externally-initiated ingresses cross the boundary: flow A, the operator pushing source code to the GitHub repository, authenticated by username and password plus Duo TOTP MFA; and flow H, an application end-user calling the API, authenticated by a Cognito-issued JWT that API Gateway validates at the edge before any application code runs. There is still no agency-customer ingress, because there is no federal-customer surface.

Egress. Two flows leave the boundary: flow G, CloudFront serving public site content and /.well-known/ artifacts to anonymous readers over TLS 1.2+; and flow I, the evidence SLA alarms emailing the operator email, which is outside the boundary (ROT #3), through the SNS topic. Flow I carries alarm metadata only (alarm name, state, reason, threshold, account and alarm identifiers), and SNS email is not end-to-end encrypted. The daily runtime cycle (flow F) and the hourly watchdog read of the site bucket are internal.

Privileged versus non-privileged access. The flow table marks each authentication context. Privileged: operator (root + admin), GitHub Actions deployer (Terraform apply, S3 sync, Lambda update), now via GitHub OIDC role assumption rather than a static key. Non-privileged: the runtime emitter Lambda's IAM role (read-only on three S3 config APIs and one CloudFront distribution, secretsmanager:DescribeSecret on the one application secret, and kms:Sign on the runtime-signing key; write to one S3 key), and the evidence watchdog Lambda's IAM role (read three named /.well-known/ objects; publish metrics to one CloudWatch namespace; no write to evidence and no publish to the alert topic). Cognito-authenticated: application end-users (flow H). 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) now uses GitHub OIDC role assumption with no long-lived AWS access keys; POAM-001 is closed. The application interconnection to Anthropic that POAM-020 tracked was removed under SCN-2026-006; flow H now ends at the application Lambda.

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: no federal customer accounts exist. The system does implement an application end-user authentication surface (Amazon Cognito with mandatory MFA), shown as flow H and the Cognito component, but it serves the operator’s own application users, not federal customers.
• Administrative and support personnel authentication logical data flow: covered by flows A and B on the map above.
• System application data flow within the proposed cloud authorization boundary: covered by flows C, D, F, H, and the internal leg of I on the map above.
• System application data flow to all leveraged and interconnected systems: covered by flows B, E, H, and I on the map above (AWS leveraged path; Sigstore signing chain; application requests to the app Lambda; alarm email to the operator, out of boundary).

A separate network diagram in the conventional 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 (now DNSSEC-signed) 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.