grcengineering/conduit

# CONDUIT **ASSURE TPRM 的证据交换协议** [](https://www.python.org/downloads/) [](https://pdm.fming.dev) [](https://docs.pydantic.dev/) ## 传统 TPRM 的问题 ### 如今破碎的工作流 ``` Customer A sends 200-question security questionnaire ↓ Vendor fills it out (8-12 hours) ↓ Customer A manually reviews answers (4-6 hours) ↓ Customer A asks follow-up questions ↓ Vendor responds again ↓ Customer A creates risk assessment in their GRC tool ``` **然后对于客户 B、C、D... 每年重复此循环 50 次以上！** ### 传统 TPRM 的主要问题： | 问题 | 影响 | 年度成本（每个供应商） | |---------|--------|--------------------------| | **供应商疲劳** | 同样的问题回答 50 次以上 | 400-600 小时（$40K-60K） | | **不一致性** | 对同一问题向不同客户提供不同答案 | 高风险敞口 | | **无标准化** | 每个客户都有独特的问卷格式 | 无法自动化 | | **人工处理** | 人工阅读 150 页的 SOC 2 报告 | 每次审查 13 小时 | | **数据过时** | 年度审查意味着 11 个月的信息过时 | 虚假的安全感 | | **无验证** | “我们要加密数据” —— 但如何加密？是否最新？ | 信任但不验证 | | **证据搜寻** | 证据散落在多个文档中 | 难以审计 | | **SOC 2 缺口** | SOC 2 未涵盖关键的 TPRM 要求 | 缺失风险领域 | ### 真实案例：Acme SaaS ``` Acme SaaS has 50 enterprise customers. Traditional TPRM (per year): ├─ 50 security questionnaires to complete ├─ Each takes 8-12 hours (includes: research, write, review, submit) ├─ Follow-up questions: +2 hours per customer ├─ Total: 500-700 hours/year ├─ Cost: $50,000-70,000 in security team time └─ Result: Still get inconsistent answers, customer complaints Customer Side (each): ├─ Review 200 vendor responses manually (4-6 hours) ├─ Read SOC 2 report for gaps (3-4 hours) ├─ Create risk assessment in GRC tool (2 hours) ├─ Follow-up questions (2 hours) ├─ Total: 11-16 hours per vendor review └─ Result: Outdated by the time assessment is done ``` ## CONDUIT 解决方案 **供应商以标准化的 CONDUIT 格式（24 种证据类型）发布一次。** **所有客户自动消费** - 不再有重复的问卷。 ### 运作方式：AI 驱动的文档转换 ``` ┌─────────────────────────────────────────────────────────────┐ │ 📄 INPUT: Vendor Documents (Unstructured) │ │ ├─ SOC 2 Type II Report (150 pages) │ │ ├─ ISO 27001 Certificate │ │ ├─ Policies & Test Results │ │ └─ Security Questionnaires │ └─────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ 🤖 AI LAYER 1: Extraction (Claude API) │ │ • Multi-document synthesis │ │ • Extracts 24 standardized evidence types │ │ • Confidence scoring (0.0-1.0) │ │ • Source attribution (doc + page refs) │ └─────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ 🛡️ AI LAYER 2: Validation (Pydantic Schemas) │ │ • Schema validation (required fields, types) │ │ • Business logic checks (date recency, SLAs) │ │ • Percentage-based compliance scoring │ │ • Pass/fail per requirement │ └─────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ 📊 AI LAYER 3: Gap Analysis (Claude + Domain Knowledge) │ │ • SOC 2 overlap detection │ │ • Missing evidence identification │ │ • Risk prioritization │ │ • Remediation guidance │ └─────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ 📦 OUTPUT: CONDUIT Evidence Package (Structured) │ │ ├─ 24 JSON evidence files (standardized) │ │ ├─ Compliance scores (percentage-based) │ │ ├─ Gap analysis report │ │ ├─ Risk register with remediation steps │ │ └─ Interactive dashboard visualization │ └─────────────────────────────────────────────────────────────┘ │ ┌─────────────────┼─────────────────┐ ▼ ▼ ▼ Customer A Customer B Customer C All consume the SAME validated evidence package No questionnaires, no vendor fatigue, no inconsistencies ``` ### 示例：BCP/DR 测试证据 ``` AI extracts from vendor docs: ├─ Test Date: 2025-08-15 ├─ Test Result: Partial Pass (RTO exceeded by 2h) ├─ Test Type: Partial Failover └─ Scope: Production DB & app servers Compliance Scoring (3 requirements): ├─ ✓ Test within 12 months: PASS (1/3) ├─ ✗ Test result successful: FAIL (1/3) ← RTO not met └─ ✓ Scope documented: PASS (2/3) Compliance: 66.7% → PARTIALLY_COMPLIANT ⚠️ Risk Analysis: • Service disruption if DR fails • Customer availability SLA at risk (RTO: 4h target, 6h actual) Remediation: 1. Re-test BCP/DR within 30 days 2. Investigate why RTO exceeded by 2 hours 3. Update DR runbook to meet 4-hour RTO ``` **优势：** - ✅ 供应商发布一次（每年节省 650 小时） - ✅ 标准化格式（24 种 ASSURE 证据类型） - ✅ AI 验证并带有置信度分数 - ✅ 内置 SOC 2 缺口分析 - ✅ 基于百分比的合规性（透明指标） ## CONDUIT 对比传统 TPRM：并肩对比 ### 针对供应商（发布者） | 传统 TPRM | CONDUIT | |------------------|---------| | 填写 50 多份独特的安全问卷 | 发布 **1 个标准化证据包** | | 每份问卷需要 8-12 小时 | **1 小时** 上传文档 + 审查 AI 提取结果 | | 对不同客户的回答不一致 | **100% 一致** - 对所有人都使用相同的证据 | | 从 SOC 2 报告手动复制/粘贴 | AI 从您的文档中**自动提取** | | 在客户审查之前没有验证 | 通过 Pydantic 模式进行**即时验证** | | 客户问“这是最新的吗？” | 每个字段都有**时间戳 + 置信度分数** | | 证据散落在邮件主题中 | **所有证据集中在一个包中**，并带有来源归属 | | 每年总计 500-700 小时 | **每年 50 小时**（节省 92% 时间） | | **$50K-70K 年度成本** | **约 $6K 年度成本**（节省 91% 成本） | ### 针对客户（消费者） | 传统 TPRM | CONDUIT | |------------------|---------| | 发送 200 个问题的安全问卷 | **下载供应商的 CONDUIT 包** | | 等待 2-4 周才能得到供应商回复 | **即时访问**最新证据 | | 人工审查 200 个文本答案 | **交互式仪表板**，带有通过/失败状态 | | 人工阅读 150 页的 SOC 2 报告 | AI **预消化**证据并附带页码参考 | | 猜测哪些 SOC 2 章节适用 | **自动 SOC 2 缺口分析** | | “他们说他们加密数据”（信吗？） | **确切证据**：“AES-256, soc2_report.pdf p.34” | | 从头开始创建风险评估 | **自动生成的风险登记册**，附带补救步骤 | | 合规状态：❓ 未知 | **合规分数：66.7%**（通过 2/3 要求） | | 年度审查（每年 11 个月数据过时） | **持续监控**，带有过期警报 | | 每个供应商审查需 11-16 小时 | 每个供应商 **30 分钟**（节省 97% 时间） | | 无法跨供应商比较 | **标准化指标**支持供应商比较 | ### 关键差异：CONDUIT 解决了什么 #### 1. **标准化**（TPRM 的“SBOM 时刻”） ``` Traditional TPRM: └─ Every customer invents their own questionnaire format └─ Result: Impossible to automate, compare, or validate CONDUIT: └─ 24 standardized evidence types (ASSURE framework) └─ Result: Machine-readable, automatable, comparable across vendors ``` #### 2. **基于证据（而非基于调查）** ``` Traditional TPRM: └─ Customer: "Do you test BCP/DR annually?" └─ Vendor: "Yes" (no evidence required) └─ Result: Trust but don't verify CONDUIT: └─ CONDUIT Package requires: ├─ test_date: "2025-08-15" ├─ test_result: "partial_pass" ├─ source_document: "soc2_report.pdf, page 45-47" ├─ extraction_confidence: 0.92 └─ Result: Verifiable, auditable evidence with source attribution ``` #### 3. **SOC 2 缺口分析（内置）** ``` Traditional TPRM: └─ Vendor: "Here's our SOC 2 report" └─ Customer: Reads 150 pages, manually identifies gaps └─ Result: Probably misses critical ASSURE requirements CONDUIT: └─ CONDUIT Package includes: ├─ Evidence #23 (SSO/MFA): 75% compliant │ ├─ SOC 2 Coverage: 50% │ └─ Gap: "SOC 2 NEVER checks SSO paywall requirement!" └─ Result: Automatic gap detection with remediation guidance ``` #### 4. **持续验证（而非年度）** ``` Traditional TPRM: └─ Annual vendor review └─ Data is stale 11 months of the year └─ Result: False sense of security CONDUIT: └─ Continuous monitoring: ├─ Vendor publishes updated package quarterly ├─ Automated alerts: "Pentest expires in 30 days" ├─ Change detection: "MFA compliance dropped from 75% → 50%" └─ Result: Always current, proactive risk management ``` #### 5. **AI 驱动的智能（而非人工审查）** ``` Traditional TPRM: └─ Human analyst reads SOC 2 report for 4-6 hours └─ Extracts key findings manually └─ Result: Slow, expensive, inconsistent CONDUIT: └─ Claude AI reads ALL vendor documents in seconds: ├─ Extracts 24 evidence types automatically ├─ Synthesizes conflicting information ├─ Scores confidence (0.0-1.0) on every extraction ├─ Identifies risks with business impact context └─ Result: Instant, accurate, scalable intelligence ``` #### 6. **基于百分比的合规性（而非二元）** ``` Traditional TPRM: └─ Vendor risk rating: "Low / Medium / High" └─ No transparency into how rating was calculated └─ Result: Hard to justify to auditors, can't track improvement CONDUIT: └─ Percentage-based compliance per control: ├─ BCP/DR: 66.7% (2/3 requirements passed) ├─ Vulnerability Mgmt: 50.0% (2/4 requirements passed) ├─ SSO/MFA: 75.0% (3/4 requirements passed) └─ Result: Transparent, auditable, tracks improvement over time ``` ### 行业影响 **CONDUIT 旨在成为“TPRM 领域的 SBOM”** 就像软件物料清单 (SBOM) 标准化了依赖项跟踪一样： - SBOM 之前：每家公司都以不同方式跟踪依赖项 - SBOM 之后：标准格式、自动化工具、全行业采用 CONDUIT 为第三方风险管理 (TPRM) 做了同样的事情： - CONDUIT 之前：每个客户都有独特的问卷 - CONDUIT 之后：标准证据格式、自动化处理、供应商生态系统 **愿景**：每个 SaaS 供应商都在其信任中心发布 CONDUIT 包。每个 GRC 工具自动导入 CONDUIT 包。不再有问卷。 ## 🎨 实时演示 **[查看交互式仪表板 →](https://grcengineering.github.io/conduit/)** 使用模拟供应商数据探索 CONDUIT 基于百分比的合规性可视化。点击节点以查看详细要求、风险和原始 JSON 输出。 ## 状态 ✅ **阶段 1 - 已完成** - 已实施 3 个证据模式并支持基于百分比的合规性 - 39 个单元测试通过 - 仪表板集成文档 🚧 **阶段 5（加速） - 开发中** - 交互式 Plotly 仪表板 - 3 种视图模式：供应商-控制、供应链、风险-控制 - 可点击节点，支持详细深入查看 ## ASSURE 框架（24 种证据类型） CONDUIT 实施了 ASSURE 核心尽职调查框架： | # | 证据类型 | 复杂度 | 状态 | |---|---------------|------------|--------| | 1 | 架构与分段 | 中 | 📋 已计划 | | 2 | 数据映射 | 低 | 📋 已计划 | | 3 | 风险评估 | 中 | 📋 已计划 | | 4 | 漏洞管理 | **高** | 🚧 **阶段 1** | | 5 | 事件响应 | 中 | 📋 已计划 | | 6 | 备份配置 | 低 | 📋 已计划 | | 7 | BCP/DR 测试 | **低** | 🚧 **阶段 1** | | 8 | 访问审查 | 低 | 📋 已计划 | | 9 | 生产环境访问控制 | 中 | 📋 已计划 | | 10 | 网络 ACL | 中 | 📋 已计划 | | 11 | 2FA 验证 | 低 | 📋 已计划 | | 12 | 静态加密 | 中 | 📋 已计划 | | 13 | 传输中加密 | 低 | 📋 已计划 | | 14 | 日志配置 | 低 | 📋 已计划 | | 15 | 安全警报 | 低 | 📋 已计划 | | 16 | 分支保护 | 低 | 📋 已计划 | | 17 | 变更控制 | 低 | 📋 已计划 | | 18 | 校验和/FIM | 低 | 📋 已计划 | | 19 | CIS 扫描 | 中 | 📋 已计划 | | 20 | 托管验证 | 低 | 📋 已计划 | | 21 | 保密协议 | 中 | 📋 已计划 | | 22 | 合规协议 | 中 | 📋 已计划 | | 23 | SSO/MFA 要求 | **中** | 🚧 **阶段 1** | | 24 | AI 控制 | 未知 | 📋 待定 | ## 架构 CONDUIT 为每种证据类型使用**独立文件**，以实现清晰的组织： ``` src/conduit/models/ ├── base.py # Shared BaseEvidence class ├── evidence_001_architecture.py # Control #1 ├── evidence_004_vulnerability.py # Control #4 (Phase 1) ├── evidence_007_bcpdr.py # Control #7 (Phase 1) ├── evidence_023_sso_mfa.py # Control #23 (Phase 1) └── ... (24 files total) ``` **为什么使用独立文件？** - ✅ 易于查找（文件名 = 控制编号） - ✅ 小文件（每个约 100-150 行） - ✅ 对 Git 友好（无合并冲突） - ✅ 测试与结构相镜像 - ✅ 可扩展 ## 快速开始 ### 安装 **针对用户（推荐）：** ``` # 使用 pip 安装 CONDUIT CLI pip install git+https://github.com/grcengineering/conduit.git # 或者使用 pipx（更适合 CLI 工具） pipx install git+https://github.com/grcengineering/conduit.git ``` **针对开发者：** ``` # 克隆并使用 PDM 安装 git clone https://github.com/grcengineering/conduit.git cd conduit pdm install # 配置 Claude API key cp .env.template .env # 编辑 .env 并添加你的 ANTHROPIC_API_KEY ``` ### 从文本提取证据（阶段 2 - 现已推出） **生产就绪：**基于模式的归一化已在 8 个供应商中通过 26 种模式验证（已确认对数缩放） ``` # 从 stdin（复制/粘贴文本） echo "We completed BCP/DR test on Aug 15, 2025. Partial failover test..." | \ conduit extract -v "Acme Corp" -t bcpdr # 从 file（trust center, email, SOC 2 extract 等） conduit extract -v "Acme Corp" -t bcpdr -f trust_center.txt # 从 PDF（SOC 2 reports, pentest reports 等） conduit extract -v "Acme Corp" -t sso_mfa -f "SOC2_Report.pdf" -o evidence.json # 可用 evidence 类型： # bcpdr - BCP/DR Testing (Evidence #7) # vulnerability - Vulnerability Management (Evidence #4) # sso_mfa - SSO/MFA Requirements (Evidence #23) # 使用昂贵的 Sonnet model 以获得更高的准确性 conduit extract -v "Acme Corp" -t bcpdr -f input.txt --expensive ``` ### 示例输出 ``` Extracting BCP/DR Testing evidence... Model: Claude Haiku (cheap) Validating with Pydantic schema... ╭──────────────────────────────────────────╮ │ ✓ Valid BCP/DR Testing evidence created! │ ╰──────────────────────────────────────────╯ Compliance Summary ┏━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ Metric ┃ Value ┃ ┡━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━┩ │ Vendor │ Acme Corp │ │ Evidence Type │ assure_007_bcpdr_testing │ │ Compliance % │ 100.0% │ │ Status │ compliant │ │ Requirements Passed │ 3/3 │ └───────────────────────┴──────────────────────────┘ ``` ### Python API 用法 ``` from conduit.transformer import text_to_bcpdr from conduit.models.evidence_007_bcpdr import BCPDREvidence # 从 ANY 文本源提取 text = """ At Acme Corp, we completed our disaster recovery test on August 15, 2025. We performed a partial failover test covering production systems... """ # 将文本转换为 → 已验证 evidence data = text_to_bcpdr(text, "Acme Corp") evidence = BCPDREvidence.model_validate(data) # 使用 validated object print(f"Compliance: {evidence.get_compliance_percentage()}%") print(f"Status: {evidence.get_compliance_status()}") print(f"Test Date: {evidence.test_date}") ``` ### 未来命令（阶段 3） ``` # 将 vendor document 转换为 CONDUIT 格式（PDF 处理） conduit transform vendor_soc2.pdf # 验证 CONDUIT evidence package conduit validate evidence_package/ # 分析 SOC 2 重叠 conduit gaps evidence_package/ --soc2 vendor_soc2.pdf ``` ## 技术栈 - **Python 3.12+** - 带有类型提示的现代 Python - **Pydantic v2** - 数据验证与 JSON 模式生成 - **Anthropic Claude** - 用于文档分析的 LLM - **PDM** - 包管理 - **Typer** - CLI 框架 - **Rich** - 终端输出 - **React + Vite** - 仪表板（阶段 5） - **Plotly** - 可视化（阶段 5） ## 开发 ``` # 安装 dependencies pdm install # 运行 tests pdm run test # Lint 代码 pdm run lint # 格式化代码 pdm run format ``` ## 路线图 - **阶段 1**（第 1 周）：3 个入门证据模式 + 验证 - **阶段 2**（第 2 周）：带有 Claude API 的 LLM 转换器 - **阶段 3**（第 3 周）：CLI 工具（transform, validate, gaps） - **阶段 4**（第 4-5 周）：其余 21 个证据模式 - **阶段 5**（第 6-7 周）：带有可视化的 React 仪表板 - **阶段 6**（第 8 周）：示例（AWS, Stripe, Okta）+ 文档 ## 许可证 MIT ## 有疑问？ 提交 issue 或联系 GRC 工程团队。

标签：ASSURE, GRC, PDM, Pydantic, Python, SaaS安全, SOC 2, STIX, TAXII, TPRM, 互操作性, 供应商评估, 信任管理, 合规自动化, 安全控制, 安全问卷, 审计, 提示词模板, 数据验证, 文档标准化, 无后门, 第三方风险管理, 证据交换协议