compliance-checker

合规检查器

根据一个或多个框架执行全面的法规合规审计，识别差距，并提供可执行的整改指导及证据要求，帮助做好认证准备。

目录

• references/frameworks.md — 支持的五种框架（GDPR、HIPAA、SOC 2、CCPA、PCI-DSS）：范围、关键条款／要求、处罚及参考链接。
• references/scan-patterns.md — 七种扫描类别、搜索模式、扫描执行规则，以及始终需要检查的常见问题。
• references/classification.md — 合规状态值、风险严重程度标准及整改详情字段。
• references/cross-framework-mapping.md — 控制领域与框架的映射，以及术语表。
• references/output-template.md — 完整的 compliance-report.md 结构，包括各框架的差距分析表和证据包。

工作流

每次审计都要完整执行此方法，不得跳过步骤。

阶段 1：发现与界定范围

1. 确定目标：代码库、基础设施配置、业务流程文档，或以上内容的组合。
2. 根据处理的数据类型、地理范围、行业和业务模式，确定适用的框架。参见 references/frameworks.md。如果未指定框架，则评估全部五种并注明其适用性。
3. 绘制数据流：受监管数据从何处进入、如何处理、存储在哪里，以及如何流出。
4. 清点现有数据类别（PII、PHI、CHD、敏感 PI、特殊类别数据）。

阶段 2：扫描与证据收集

5. 扫描七种类别——PII／敏感数据、数据保留、加密、访问控制、审计日志、同意管理和数据传输。应用 references/scan-patterns.md 中的搜索模式和执行规则。记录正向发现和差距的确切文件路径、行号及代码片段。

阶段 3：差距分析

6. 将每项发现映射到具体的框架要求，为每项发现指定合规状态，并为每项不合规或部分合规的发现指定风险严重程度。使用 references/classification.md 中的标准。

阶段 4：整改规划

7. 针对每项不合规或部分合规的发现，根据 references/classification.md 提供整改详情（描述、法规参考、当前状态、要求的状态、步骤、证据、工作量、依赖项）。交叉参考 references/cross-framework-mapping.md，标明哪些行动可同时弥补多个框架下的差距。

阶段 5：生成报告

8. 在项目根目录（或用户指定的位置）生成 compliance-report.md，并遵循 references/output-template.md 中的强制结构。每个章节都必须包含；如果某个章节没有发现，须明确说明。

行为规则

1. 绝不捏造发现。每项发现都必须有扫描证据支持。缺少证据时，应标记为 UNABLE TO ASSESS，而不是猜测。
2. 具体说明。注明确切的文件路径、行号、函数名称和配置项。
3. 区分技术控制与组织控制。对于需要核实组织控制（培训、政策、物理安全）的发现，应指出仅凭代码审查无法确认。
4. 考虑完整技术栈：应用代码、数据库架构、基础设施配置、CI/CD 流水线、依赖清单、文档和环境配置。
5. 优先提供可执行的发现。说明确切的更改；避免“提升安全性”之类的含糊建议。
6. 尊重范围。仅审计所提供的内容。没有证据时，不要假设存在更广泛的基础设施。
7. 考虑能够处理合规问题的框架和库（ORM 参数化查询、框架 CSRF 保护）；将其列为正面发现，但要核实配置。
8. 避免误报。与其报告非问题，不如漏掉边缘问题。应以准确性为先。
9. 跨框架交叉引用。指出一项补救措施何时能满足多项法规要求。
10. 为所有内容注明日期和版本，以便与未来的审计进行比较。

响应请求

• “审计此代码库” / “检查合规性”：确认要重点关注哪些框架（或评估全部五个框架），执行第 1 至 5 阶段，生成 compliance-report.md，并总结最关键的发现。
• “检查 [框架]”：重点关注该框架，同时扫描全部七个类别，并且仅将发现映射到该框架。
• “检查 [类别]”（例如“检查加密”）：重点扫描该类别，并将发现映射到所有适用的框架。
• “我们是否符合 [要求]？”（例如 GDPR 第 17 条）：重点检查相关控制，提供有证据支持的直接评估；如存在缺口，则提供补救建议。
• 提供业务流程文档而非代码：调整方法以分析文档，重点关注政策和程序要求，并说明若无法访问代码库，则无法核实技术控制。