kenithphilip/FedPy
GitHub: kenithphilip/FedPy
FedPy 是一个 FedRAMP 20x 合规自动化工具集，通过只读云证据采集和多用户跟踪仪表板覆盖完整的合规验证与治理生命周期。
Stars: 2 | Forks: 0
# FedRAMP 20x 合规工具
[](https://github.com/kenithphilip/FedPy/actions/workflows/ci.yml)
[](LICENSE)
本仓库包含**两个互补的项目**，它们共同覆盖了完整的 FedRAMP 20x 生命周期 —— 一方面是自动化技术证据，另一方面是人工跟踪的治理状态。
| 项目 | 功能 | 技术栈 |
|---|---|---|
| [`cloud-evidence/`](cloud-evidence/) | 一个**只读**收集器，用于捕获每个 FedRAMP 20x KSI 的 AWS + GCP + Kubernetes 配置证据，对其进行评分、签名、映射到 NIST 800-53，并将其推送到您的 GRC 技术栈。 | TypeScript · Node (tsx) 或 Bun · AWS SDK v3 · googleapis · @kubernetes/client-node |
| [`tracker/`](tracker/) | 一个基于 FedRAMP 机器可读 (FRMR) 目录的本地多用户 Web 仪表板，用于跟踪实施状态、所有权归属、证据链接以及 NIST 交叉对照表。 | TypeScript · Hono · better-sqlite3 · React + Vite |
## 目录
- [为什么会有这个项目](#why-this-exists)
- [您将获得什么](#what-you-get)
- [仓库布局](#repository-layout)
- [架构概览](#architecture-at-a-glance)
- [快速开始](#quick-start)
- [cloud-evidence 收集器](#the-cloud-evidence-collector)
- [只读安全模型](#read-only-safety-model)
- [影响级别与框架](#impact-levels--frameworks)
- [NIST 800-53 控制基准](#nist-800-53-control-benchmark)
- [输出产物](#output-artifacts)
- [集成](#integrations)
- [生产环境强化](#production-hardening)
- [跟踪器](#the-tracker)
- [测试](#testing)
- [文档索引](#documentation-index)
- [数据来源与致谢](#data-sources--attribution)
- [安全](#security)
- [许可证](#license)
## 为什么会有这个项目
FedRAMP 20x 将授权的重点重新放在**机器可读、持续验证的证据**上，而不是静态的 SSP 叙述。权威的事实来源是 [FedRAMP 机器可读 (FRMR)](https://github.com/FedRAMP/docs) 数据，它定义了**关键安全指标 (KSI)** 和 **FedRAMP 要求 (FRR)**。
这些工具将这一事实来源转化为两个实用的工作流：
1. **自动化证明。** `cloud-evidence` 以*只读*方式登录您的云账户，直接根据实时配置评估可通过云端测试的指标，并输出已签名、schema 有效且映射到 OSCAL 的证据 —— 因此这些证据是可复现且可由审计人员验证的，而不是手工拼凑的。
2. **跟踪其余部分。** 并非所有要求都可以通过云 API 进行测试（很大一部分是治理/流程义务）。`tracker` 为您的团队提供了一个共享界面，用于记录全套 223 项要求的状态、负责人、证据链接和最后审查日期，并提供 NIST 800-53 交叉对照表，以便与现有的 Rev5 基准进行映射。
一切都是**本地优先和自托管的** —— 除非您明确推送，否则您的证据和跟踪器状态永远不会离开您控制的基础设施。
## 您将获得什么
- ✅ **完整的 KSI 覆盖** —— 所有 **63 个 KSI** 和 **223 项要求**都已考虑在内：在可测试的地方使用云收集器，为治理要求提供流程工件证据，并为涉及 FedRAMP / 机构 / 3PAO 义务的项目提供明确的*仅限感知*跟踪。
- 🔒 **可证明的只读** —— 每次云 SDK 调用都由*两个*独立的层强制执行只读（仅查看者 IAM **和**运行时防护代理）。
- 🎚️ **低 / 中 / 高** —— 选择您的影响层级；收集器会将每个要求限定在该层级内（高适用性是从 NIST 800-53 Rev5 派生的，并已明确标出）。
- 📊 **NIST 800-53 基准** —— 将调查结果汇总到 800-53 控制项并对每个控制项进行评分，涵盖 20x 引用的控制集和完整的 SP 800-53B 基准。
- 🖊️ **防篡改** —— Ed25519 签名的清单 + 可选的 RFC 3161 可信时间戳；离线的 `verify` CLI 会重新检查每个哈希和签名。
- 🔁 **OSCAL + 交叉对照** —— OSCAL 1.1 评估结果，外加 NIST → SOC 2 / ISO 27001 / HIPAA 交叉对照。
- 🔌 **推送到任何地方** —— Paramify、内置的跟踪器、Slack/PagerDuty、Jira/ServiceNow/GitHub Issues、SIEM (OCSF)、通用 HMAC webhook，以及可选的由 LM 起草的修复 PR。
- 🧰 **运维强化** —— 重试/退避机制、在限流下进行自适应并发、仅追加的运行账本，以及防止运行重叠的运行锁。
## 仓库布局
```
FedRAMP 20x/
├── cloud-evidence/ Read-only AWS+GCP+K8s evidence collector
│ ├── core/ Orchestrator, schema, signing, OSCAL, benchmark, hardening
│ ├── providers/ Per-cloud collectors (aws/, gcp/, k8s/)
│ ├── scripts/ Reproducible data extractors (FRMR, NIST r5, baselines)
│ ├── docs/ Committed generated lookups + IAM permission catalog
│ └── tests/ Vitest suites (38 files, 396 tests)
├── tracker/ Local multi-user web tracker over the FRMR catalog
│ ├── server/ Hono API + better-sqlite3 + RBAC/2FA/audit
│ ├── client/ React + Vite SPA
│ └── tests/ Vitest suites (11 files, 99 tests)
├── ARCHITECTURE.md How the two projects fit together (with diagrams)
├── RUNBOOK.md Operations: setup, IAM, env vars, troubleshooting
├── COST.md Cost model for the collector + integrations
├── GAP-ANALYSIS.md Positioning vs Prowler/ScoutSuite/Wiz/Drata/Vanta/Paramify
├── CHANGELOG.md Version history
├── LICENSE Apache-2.0
└── NOTICE Third-party data attribution
# 外部参考克隆（git-ignored，不属于此 repo 的代码）：
├── docs/ Clone of github.com/FedRAMP/docs (FRMR source of truth)
└── nist-r5-data/ NIST 800-53 Rev5 reference data
```
## 架构概览
```
graph LR
CSP[CSP environment
AWS + GCP + K8s] --> CE[cloud-evidence
orchestrator] CE --> Out[(out/*.json
+ manifest.sig
+ control-benchmark.json
+ assessment-results.json)] Out --> Sign[Ed25519 + RFC 3161] Out --> Tracker[(tracker DB)] Out --> GRC[Paramify / SIEM / Tickets / Webhook] Auditor[3PAO / auditor] -. verifies .-> Out Tracker --> UI[React SPA] ``` 有关完整的模块映射和数据流，请参见 [ARCHITECTURE.md](ARCHITECTURE.md)。 ## 快速开始 **前置条件：** Node 22+（在 22 和 24 上测试过）；收集器可选择使用 [Bun](https://bun.sh) 1.3+ 或 [Deno](https://deno.com) 2.8+。AWS 凭证通过 `aws sso login` / `AWS_PROFILE` 获取，GCP 凭证通过 `gcloud auth application-default login` 获取。 ``` git clone git@github.com:kenithphilip/FedPy.git "FedRAMP 20x" cd "FedRAMP 20x" ``` ### 收集证据 ``` cd cloud-evidence npm install # 仅计划 — 不进行 SDK 调用 npm run collect -- --dry-run # Moderate 级别的真实收集，基于 20 倍引用的 controls 进行 benchmark npm run collect -- --impact-level moderate --framework 20x # 完整的 High 级别运行，针对整个 NIST SP 800-53B High baseline 进行 benchmark， # 包含所有运行后报告、OSCAL、crosswalk 和签名 npm run collect -- --impact-level high --framework rev5 --all-reports --oscal --crosswalk # 离线验证已完成的运行（重新哈希每个文件，检查签名） npm run verify -- ./out ``` ### 运行跟踪器 ``` # 从 repo 根目录，获取 FRMR source of truth（如果你还没有的话） git clone https://github.com/FedRAMP/docs.git cd tracker npm install npm run ingest # load FRMR.documentation.json into data/tracker.db npm run dev # API on :4000, web UI on :5173 # 打开 http://localhost:5173 — 你创建的第一个账户将成为管理员 ``` ## cloud-evidence 收集器 一个用于 **AWS、GCP 和 Kubernetes** 上 FedRAMP 20x KSI 的只读 TypeScript 收集器。它可以在 Node（通过 `tsx`）、Bun 或 Deno 上运行 —— 推荐将 Bun 用于生产环境收集（原生 TS，更快的启动/I/O，在限流下更好的并发）；Node + `tsx` 是默认选项，也是测试套件运行的平台。Deno 也通过 `collect:deno` / `verify:deno` 脚本受到支持（它需要明确的 `--allow-*` 权限标志；请参见 [RUNBOOK.md](RUNBOOK.md)）。 ### 只读安全模型 收集器**绝不能修改云状态**，这由两个独立的机制强制执行（仅靠任何一个都可以阻止写入；但两者都是运行所必需的）： 1. **仅查看者 IAM。** 运行者主体仅绑定到只读托管策略（AWS `ReadOnlyAccess`、GCP 查看者/securityReviewer 角色、K8s `view`）。确切的最小权限角色列表位于 [RUNBOOK.md](RUNBOOK.md) 和 [cloud-evidence/docs/IAM-PERMISSIONS-CATALOG.md](cloud-evidence/docs/IAM-PERMISSIONS-CATALOG.md) 中。 2. **运行时防护代理。** 每个 SDK 客户端在构造时都由 `core/readonly-guardrail.ts` (AWS) 或 `core/readonly-guardrail-gcp.ts` (GCP) 包装。任何动词前缀不在只读允许列表中的命令都会在**调用离开进程之前**抛出 `ReadOnlyViolationError` —— 因此，即使是权限范围设置错误的 IAM 角色或有错误的新收集器也无法执行写入操作。 ### 影响级别与框架 在设置时（`config.yaml` `impact_level:`）或在每次运行时（`--impact-level low|moderate|high`）选择层级。然后，收集器将所有 223 项要求限定在该层级内： - **可通过云端测试的 KSI** 会针对实时配置运行其收集器。 - **治理要求** 输出已签名的*流程工件*证据，通过带有 SLA/截止日期监控的证明登记表进行跟踪。 - **FedRAMP/机构/3PAO 义务** 被记录为**仅限感知**，并从您的提供商通过/失败评估中排除。 高适用性是**从 NIST 800-53 Rev5 基准派生的**（没有单独发布的 20x 高层级），并且始终标记为 `derived-rev5`。 ### NIST 800-53 控制基准 每次运行都会将调查结果**汇总到 NIST 800-53 控制项**，并在选定的影响级别对每个控制项进行评分，以便您可以根据基准对您的云基础设施进行基准测试。通过 `--framework` 提供两种视角： | `--framework` | 范围内的控制集 | 回答的问题 | |---|---|---| | `20x`（默认） | 被评估的 20x KSI/FRR 引用的控制项 | “20x 关心的控制项在这个级别下覆盖程度如何？” | | `rev5` | 该级别的完整 NIST SP 800-53B 基准（低 **149** / 中 **287** / 高 **370**） | “哪些基准控制项有自动化的云证据，哪些仍然需要手动评估？” | 每个控制项都会获得一个状态 —— `satisfied`（所有映射的发现均通过）、`partially-satisfied`（混合）、`not-satisfied`（全部失败）或 `not-assessed`（无自动化证据）。报告（`control-benchmark.json`）提供两个比率：`assessed_pass_rate`（satisfied ÷ 有证据的控制项）和 `baseline_coverage_rate`（satisfied ÷ 整个范围内集合）。仅限感知的证明会列在控制项下，但本身永远不能满足该控制项。 基准成员资格以提交文件的形式提供（`cloud-evidence/docs/nist-r5-baselines.generated.json`，源自 NIST 官方的 OSCAL 已解析 profile 目录），因此**运行时不需要网络**；使用 `node scripts/extract-nist-baselines.mjs` 刷新它。 ### 输出产物 单次运行将写入 `./out/`： | 文件 | 内容 | |---|---| | `KSI-*.json` | 每个 KSI 的证据信封（v3 schema，每个要求一个） | | `pva-run-summary.json` | 运行汇总 + 影响级别 + 框架 + 基准概要 | | `family-rollup.json` | 按控制项系列的态势 | | `control-benchmark.json` | NIST 800-53 控制基准（本次运行的框架/级别） | | `inventory.json` *(`--inventory-workbook`)* | 丰富的组织级云资产清单（每种资源类型；事实来源）+ 关系图 | | `inventory-workbook.{csv,xlsx}` | FedRAMP 附录 M 集成清单工作簿（AWS + GCP 资产） | | `inventory-oscal.json` / `inventory-cmdb.json` / `inventory-diff.json` / `inventory-cost.json` | OSCAL inventory-items · ServiceNow CMDB 记录 · 跨运行的变更差异 · 按服务计算的当月迄今成本 | | `manifest.json` + `manifest.sig` | Ed25519 签名的每个输出文件的清单 | | `manifest.tsr` *(可选)* | RFC 3161 可信时间戳 token | | `assessment-results.json` *(`--oscal`)* | OSCAL 1.1 评估结果 | | `crosswalk-report.json` *(`--crosswalk`)* | NIST → SOC 2 / ISO 27001 / HIPAA | | `coverage-report.json` | 静默故障 / 缺口检测 | | `report.html`, `findings.csv` *(`--all-reports`)* | 人与电子表格的视图 | | `diff-report.{json,html}` | 与上一次运行的变更对比 | | `anomaly-report.json` *(`--anomaly`)* | 与滚动基准相比的偏差 | | `run-ledger.jsonl` | 每次操作及时间的仅追加审计跟踪 | ### 集成 所有集成均为可选启用（需要各自的环境变量；请参见 [RUNBOOK.md](RUNBOOK.md)）： Paramify · 内置的跟踪器--push-tracker`) · Slack / PagerDuty (`--notify-on-drift`) · Jira / ServiceNow / GitHub Issues (`--ticket-push`) · 通过 OCSF 的 SIEM (`--siem-url`) · 通用 HMAC 签名的 webhook (`--webhook-url`) · Anthropic Claude 修复 PR 草稿 (`--llm-generate-prs`) · Powerpipe mod (`--powerpipe`) · SBOM 摄取 (`--sbom-dir`)。 ### 生产环境强化 - 每次 SDK 调用均提供**重试/退避**（可配置尝试次数/退避上限）。 - **自适应并发** —— 一个 token bucket + AIMD 限制器，可以在限流时进行退避并恢复，外加运行中的 TTL 记忆化。 - **仅追加的运行账本** —— 包含每个操作和结果的崩溃持久型 JSONL。 - **运行锁** —— 防止两次运行破坏同一个输出目录（TTL + PID 存活检测；退出时自动释放）。 ## 跟踪器 一个本地、多用户的 Web 仪表板，它摄取 FRMR 目录，让您的团队跟踪每个 20x 要求和 KSI 的实施状态。它位于上游 FedRAMP 文档克隆的*旁边*，并按需重新摄取，同时保留您的状态、所有者、注释和证据（状态由稳定的 FRMR ID 作为键值）。 亮点：带有“下一个要解决的 10 个”的仪表板、缺口分析、要求和 KSI 浏览器、带有 FRD 术语工具提示的完整项目详情、**NIST 800-53 交叉对照**、收集器运行视图（影响级别 + 基准概要）、CSV/JSON 导出，以及具有会话的多用户账户、**TOTP 2FA**、**基于角色的访问控制**、按项目的**审计日志**，以及在线备份/恢复。 有关完整的功能列表和 API，请参见 [tracker/README.md](tracker/README.md)。 ## 测试 ``` # cloud-evidence — 38 个文件，396 个测试 cd cloud-evidence && npm test && npm run typecheck # tracker — 11 个文件，99 个测试 cd tracker && npm test && npm run typecheck ``` 两个项目均通过了类型检查，并且完整的套件（**495 个测试**）全部通过。从仓库根目录运行的 CI 风格单行命令： ``` (cd cloud-evidence && npm test) && (cd tracker && npm test) ``` ## 文档索引 | 文档 | 内容 | |---|---| | [ARCHITECTURE.md](ARCHITECTURE.md) | 模块映射、数据流、集成点、只读不变量 | | [RUNBOOK.md](RUNBOOK.md) | 设置、所需的 IAM、所有环境变量、退出代码、故障排除 | | [cloud-evidence/docs/OPERATOR-GUIDE.md](cloud-evidence/docs/OPERATOR-GUIDE.md) | **统一的操作员参考** —— 完整的 CLI 标志列表、环境变量列表、配置文件（`config.yaml`、`thresholds.yaml`、前向规范 `org-profile.yaml`）、循环全景（已实现 / 已规范 / 路线图）、条件循环激活矩阵、输出产物目录、常见运行模式 | | [cloud-evidence/org-profile.yaml.example](cloud-evidence/org-profile.yaml.example) | 用于条件循环的前向规范模板 (LOOP-M, LOOP-O, LOOP-S, LOOP-X, G.G2-CIRCIA, M.M4-CIRCIA, G.G2-SEC-8K) | | [COST.md](COST.md) | 收集器和可选集成的成本模型 | | [GAP-ANALYSIS.md](GAP-ANALYSIS.md) | 这与 Prowler / ScoutSuite / Wiz / Drata / Vanta / Paramify 的对比 | | [CHANGELOG.md](CHANGELOG.md) | 版本历史 | | [cloud-evidence/README.md](cloud-evidence/README.md) | 收集器深度剖析 | | [cloud-evidence/CLAUDE.md](cloud-evidence/CLAUDE.md) | REO 标准 + Scope Guard + 条件适用性矩阵（面向贡献者） | | [cloud-evidence/docs/STATUS.md](cloud-evidence/docs/STATUS.md) | 当前实施状态：每个切片、每个循环 | | [cloud-evidence/docs/IAM-PERMISSIONS-CATALOG.md](cloud-evidence/docs/IAM-PERMISSIONS-CATALOG.md) | 每个收集器的确切云权限 | | [cloud-evidence/docs/roadmap/README.md](cloud-evidence/docs/roadmap/README.md) | 核心外/路线图文档 (LOOP-U/V/Y/Z + 第五轮审计) | | [tracker/README.md](tracker/README.md) | 跟踪器功能、API、配置 | ## 数据来源与致谢 本仓库从公开来源**派生**了已提交的查找文件（由 `cloud-evidence/scripts/` 中的脚本重新生成，未重新授权）： - **FedRAMP FRMR** —— [github.com/FedRAMP/docs](https://github.com/FedRAMP/docs)（20x/Rev5 要求和 KSI 的美国政府事实来源）。 - **NIST SP 800-53 Rev5 控制目录** —— 通过 [GovReady/nist-sp-800-53-r5-data](https://github.com/GovReady/nist-sp-800-53-r5-data) 获取控制名称/系列。 - **NIST SP 800-53B Rev5 基准** —— 通过 [usnistgov/oscal-content](https://github.com/usnistgov/oscal-content) 获取低/中/高成员资格。 有关完整的致谢，请参见 [NOTICE](NOTICE)。这些来源仍受其各自条款的管辖。 ## 安全 - 收集器**在设计上是只读的**（参见[安全模型](#read-only-safety-model)）；出现 `ReadOnlyViolationError` 是收集器中的 bug，绝不是可以绕过的问题。 - 证据是**防篡改的**（Ed25519 清单 + 可选的 RFC 3161 时间戳），并且可以通过 `npm run verify -- ./out` 进行离线独立验证。 - 跟踪器使用 `scrypt` 存储密码，使用 HttpOnly/SameSite 会话 cookie，支持 TOTP 2FA 和 RBAC，并在审计日志中记录每一次变更。 如果您发现安全问题，请提交一份私人报告，而不是发布公开的 issue。 ## 许可证 根据 [Apache License 2.0](LICENSE) 授权。© 2026 Kenith Philip。
AWS + GCP + K8s] --> CE[cloud-evidence
orchestrator] CE --> Out[(out/*.json
+ manifest.sig
+ control-benchmark.json
+ assessment-results.json)] Out --> Sign[Ed25519 + RFC 3161] Out --> Tracker[(tracker DB)] Out --> GRC[Paramify / SIEM / Tickets / Webhook] Auditor[3PAO / auditor] -. verifies .-> Out Tracker --> UI[React SPA] ``` 有关完整的模块映射和数据流，请参见 [ARCHITECTURE.md](ARCHITECTURE.md)。 ## 快速开始 **前置条件：** Node 22+（在 22 和 24 上测试过）；收集器可选择使用 [Bun](https://bun.sh) 1.3+ 或 [Deno](https://deno.com) 2.8+。AWS 凭证通过 `aws sso login` / `AWS_PROFILE` 获取，GCP 凭证通过 `gcloud auth application-default login` 获取。 ``` git clone git@github.com:kenithphilip/FedPy.git "FedRAMP 20x" cd "FedRAMP 20x" ``` ### 收集证据 ``` cd cloud-evidence npm install # 仅计划 — 不进行 SDK 调用 npm run collect -- --dry-run # Moderate 级别的真实收集，基于 20 倍引用的 controls 进行 benchmark npm run collect -- --impact-level moderate --framework 20x # 完整的 High 级别运行，针对整个 NIST SP 800-53B High baseline 进行 benchmark， # 包含所有运行后报告、OSCAL、crosswalk 和签名 npm run collect -- --impact-level high --framework rev5 --all-reports --oscal --crosswalk # 离线验证已完成的运行（重新哈希每个文件，检查签名） npm run verify -- ./out ``` ### 运行跟踪器 ``` # 从 repo 根目录，获取 FRMR source of truth（如果你还没有的话） git clone https://github.com/FedRAMP/docs.git cd tracker npm install npm run ingest # load FRMR.documentation.json into data/tracker.db npm run dev # API on :4000, web UI on :5173 # 打开 http://localhost:5173 — 你创建的第一个账户将成为管理员 ``` ## cloud-evidence 收集器 一个用于 **AWS、GCP 和 Kubernetes** 上 FedRAMP 20x KSI 的只读 TypeScript 收集器。它可以在 Node（通过 `tsx`）、Bun 或 Deno 上运行 —— 推荐将 Bun 用于生产环境收集（原生 TS，更快的启动/I/O，在限流下更好的并发）；Node + `tsx` 是默认选项，也是测试套件运行的平台。Deno 也通过 `collect:deno` / `verify:deno` 脚本受到支持（它需要明确的 `--allow-*` 权限标志；请参见 [RUNBOOK.md](RUNBOOK.md)）。 ### 只读安全模型 收集器**绝不能修改云状态**，这由两个独立的机制强制执行（仅靠任何一个都可以阻止写入；但两者都是运行所必需的）： 1. **仅查看者 IAM。** 运行者主体仅绑定到只读托管策略（AWS `ReadOnlyAccess`、GCP 查看者/securityReviewer 角色、K8s `view`）。确切的最小权限角色列表位于 [RUNBOOK.md](RUNBOOK.md) 和 [cloud-evidence/docs/IAM-PERMISSIONS-CATALOG.md](cloud-evidence/docs/IAM-PERMISSIONS-CATALOG.md) 中。 2. **运行时防护代理。** 每个 SDK 客户端在构造时都由 `core/readonly-guardrail.ts` (AWS) 或 `core/readonly-guardrail-gcp.ts` (GCP) 包装。任何动词前缀不在只读允许列表中的命令都会在**调用离开进程之前**抛出 `ReadOnlyViolationError` —— 因此，即使是权限范围设置错误的 IAM 角色或有错误的新收集器也无法执行写入操作。 ### 影响级别与框架 在设置时（`config.yaml` `impact_level:`）或在每次运行时（`--impact-level low|moderate|high`）选择层级。然后，收集器将所有 223 项要求限定在该层级内： - **可通过云端测试的 KSI** 会针对实时配置运行其收集器。 - **治理要求** 输出已签名的*流程工件*证据，通过带有 SLA/截止日期监控的证明登记表进行跟踪。 - **FedRAMP/机构/3PAO 义务** 被记录为**仅限感知**，并从您的提供商通过/失败评估中排除。 高适用性是**从 NIST 800-53 Rev5 基准派生的**（没有单独发布的 20x 高层级），并且始终标记为 `derived-rev5`。 ### NIST 800-53 控制基准 每次运行都会将调查结果**汇总到 NIST 800-53 控制项**，并在选定的影响级别对每个控制项进行评分，以便您可以根据基准对您的云基础设施进行基准测试。通过 `--framework` 提供两种视角： | `--framework` | 范围内的控制集 | 回答的问题 | |---|---|---| | `20x`（默认） | 被评估的 20x KSI/FRR 引用的控制项 | “20x 关心的控制项在这个级别下覆盖程度如何？” | | `rev5` | 该级别的完整 NIST SP 800-53B 基准（低 **149** / 中 **287** / 高 **370**） | “哪些基准控制项有自动化的云证据，哪些仍然需要手动评估？” | 每个控制项都会获得一个状态 —— `satisfied`（所有映射的发现均通过）、`partially-satisfied`（混合）、`not-satisfied`（全部失败）或 `not-assessed`（无自动化证据）。报告（`control-benchmark.json`）提供两个比率：`assessed_pass_rate`（satisfied ÷ 有证据的控制项）和 `baseline_coverage_rate`（satisfied ÷ 整个范围内集合）。仅限感知的证明会列在控制项下，但本身永远不能满足该控制项。 基准成员资格以提交文件的形式提供（`cloud-evidence/docs/nist-r5-baselines.generated.json`，源自 NIST 官方的 OSCAL 已解析 profile 目录），因此**运行时不需要网络**；使用 `node scripts/extract-nist-baselines.mjs` 刷新它。 ### 输出产物 单次运行将写入 `./out/`： | 文件 | 内容 | |---|---| | `KSI-*.json` | 每个 KSI 的证据信封（v3 schema，每个要求一个） | | `pva-run-summary.json` | 运行汇总 + 影响级别 + 框架 + 基准概要 | | `family-rollup.json` | 按控制项系列的态势 | | `control-benchmark.json` | NIST 800-53 控制基准（本次运行的框架/级别） | | `inventory.json` *(`--inventory-workbook`)* | 丰富的组织级云资产清单（每种资源类型；事实来源）+ 关系图 | | `inventory-workbook.{csv,xlsx}` | FedRAMP 附录 M 集成清单工作簿（AWS + GCP 资产） | | `inventory-oscal.json` / `inventory-cmdb.json` / `inventory-diff.json` / `inventory-cost.json` | OSCAL inventory-items · ServiceNow CMDB 记录 · 跨运行的变更差异 · 按服务计算的当月迄今成本 | | `manifest.json` + `manifest.sig` | Ed25519 签名的每个输出文件的清单 | | `manifest.tsr` *(可选)* | RFC 3161 可信时间戳 token | | `assessment-results.json` *(`--oscal`)* | OSCAL 1.1 评估结果 | | `crosswalk-report.json` *(`--crosswalk`)* | NIST → SOC 2 / ISO 27001 / HIPAA | | `coverage-report.json` | 静默故障 / 缺口检测 | | `report.html`, `findings.csv` *(`--all-reports`)* | 人与电子表格的视图 | | `diff-report.{json,html}` | 与上一次运行的变更对比 | | `anomaly-report.json` *(`--anomaly`)* | 与滚动基准相比的偏差 | | `run-ledger.jsonl` | 每次操作及时间的仅追加审计跟踪 | ### 集成 所有集成均为可选启用（需要各自的环境变量；请参见 [RUNBOOK.md](RUNBOOK.md)）： Paramify · 内置的跟踪器--push-tracker`) · Slack / PagerDuty (`--notify-on-drift`) · Jira / ServiceNow / GitHub Issues (`--ticket-push`) · 通过 OCSF 的 SIEM (`--siem-url`) · 通用 HMAC 签名的 webhook (`--webhook-url`) · Anthropic Claude 修复 PR 草稿 (`--llm-generate-prs`) · Powerpipe mod (`--powerpipe`) · SBOM 摄取 (`--sbom-dir`)。 ### 生产环境强化 - 每次 SDK 调用均提供**重试/退避**（可配置尝试次数/退避上限）。 - **自适应并发** —— 一个 token bucket + AIMD 限制器，可以在限流时进行退避并恢复，外加运行中的 TTL 记忆化。 - **仅追加的运行账本** —— 包含每个操作和结果的崩溃持久型 JSONL。 - **运行锁** —— 防止两次运行破坏同一个输出目录（TTL + PID 存活检测；退出时自动释放）。 ## 跟踪器 一个本地、多用户的 Web 仪表板，它摄取 FRMR 目录，让您的团队跟踪每个 20x 要求和 KSI 的实施状态。它位于上游 FedRAMP 文档克隆的*旁边*，并按需重新摄取，同时保留您的状态、所有者、注释和证据（状态由稳定的 FRMR ID 作为键值）。 亮点：带有“下一个要解决的 10 个”的仪表板、缺口分析、要求和 KSI 浏览器、带有 FRD 术语工具提示的完整项目详情、**NIST 800-53 交叉对照**、收集器运行视图（影响级别 + 基准概要）、CSV/JSON 导出，以及具有会话的多用户账户、**TOTP 2FA**、**基于角色的访问控制**、按项目的**审计日志**，以及在线备份/恢复。 有关完整的功能列表和 API，请参见 [tracker/README.md](tracker/README.md)。 ## 测试 ``` # cloud-evidence — 38 个文件，396 个测试 cd cloud-evidence && npm test && npm run typecheck # tracker — 11 个文件，99 个测试 cd tracker && npm test && npm run typecheck ``` 两个项目均通过了类型检查，并且完整的套件（**495 个测试**）全部通过。从仓库根目录运行的 CI 风格单行命令： ``` (cd cloud-evidence && npm test) && (cd tracker && npm test) ``` ## 文档索引 | 文档 | 内容 | |---|---| | [ARCHITECTURE.md](ARCHITECTURE.md) | 模块映射、数据流、集成点、只读不变量 | | [RUNBOOK.md](RUNBOOK.md) | 设置、所需的 IAM、所有环境变量、退出代码、故障排除 | | [cloud-evidence/docs/OPERATOR-GUIDE.md](cloud-evidence/docs/OPERATOR-GUIDE.md) | **统一的操作员参考** —— 完整的 CLI 标志列表、环境变量列表、配置文件（`config.yaml`、`thresholds.yaml`、前向规范 `org-profile.yaml`）、循环全景（已实现 / 已规范 / 路线图）、条件循环激活矩阵、输出产物目录、常见运行模式 | | [cloud-evidence/org-profile.yaml.example](cloud-evidence/org-profile.yaml.example) | 用于条件循环的前向规范模板 (LOOP-M, LOOP-O, LOOP-S, LOOP-X, G.G2-CIRCIA, M.M4-CIRCIA, G.G2-SEC-8K) | | [COST.md](COST.md) | 收集器和可选集成的成本模型 | | [GAP-ANALYSIS.md](GAP-ANALYSIS.md) | 这与 Prowler / ScoutSuite / Wiz / Drata / Vanta / Paramify 的对比 | | [CHANGELOG.md](CHANGELOG.md) | 版本历史 | | [cloud-evidence/README.md](cloud-evidence/README.md) | 收集器深度剖析 | | [cloud-evidence/CLAUDE.md](cloud-evidence/CLAUDE.md) | REO 标准 + Scope Guard + 条件适用性矩阵（面向贡献者） | | [cloud-evidence/docs/STATUS.md](cloud-evidence/docs/STATUS.md) | 当前实施状态：每个切片、每个循环 | | [cloud-evidence/docs/IAM-PERMISSIONS-CATALOG.md](cloud-evidence/docs/IAM-PERMISSIONS-CATALOG.md) | 每个收集器的确切云权限 | | [cloud-evidence/docs/roadmap/README.md](cloud-evidence/docs/roadmap/README.md) | 核心外/路线图文档 (LOOP-U/V/Y/Z + 第五轮审计) | | [tracker/README.md](tracker/README.md) | 跟踪器功能、API、配置 | ## 数据来源与致谢 本仓库从公开来源**派生**了已提交的查找文件（由 `cloud-evidence/scripts/` 中的脚本重新生成，未重新授权）： - **FedRAMP FRMR** —— [github.com/FedRAMP/docs](https://github.com/FedRAMP/docs)（20x/Rev5 要求和 KSI 的美国政府事实来源）。 - **NIST SP 800-53 Rev5 控制目录** —— 通过 [GovReady/nist-sp-800-53-r5-data](https://github.com/GovReady/nist-sp-800-53-r5-data) 获取控制名称/系列。 - **NIST SP 800-53B Rev5 基准** —— 通过 [usnistgov/oscal-content](https://github.com/usnistgov/oscal-content) 获取低/中/高成员资格。 有关完整的致谢，请参见 [NOTICE](NOTICE)。这些来源仍受其各自条款的管辖。 ## 安全 - 收集器**在设计上是只读的**（参见[安全模型](#read-only-safety-model)）；出现 `ReadOnlyViolationError` 是收集器中的 bug，绝不是可以绕过的问题。 - 证据是**防篡改的**（Ed25519 清单 + 可选的 RFC 3161 时间戳），并且可以通过 `npm run verify -- ./out` 进行离线独立验证。 - 跟踪器使用 `scrypt` 存储密码，使用 HttpOnly/SameSite 会话 cookie，支持 TOTP 2FA 和 RBAC，并在审计日志中记录每一次变更。 如果您发现安全问题，请提交一份私人报告，而不是发布公开的 issue。 ## 许可证 根据 [Apache License 2.0](LICENSE) 授权。© 2026 Kenith Philip。
标签：FedRAMP, MITM代理, NIST 800-53, TypeScript, 云安全态势, 合规自动化, 安全插件, 自动化攻击