itdojp/crypto-communications-assurance

# 密码学通信保障 为密码学通信产品提供可重用、机器可读的保障契约、配置文件、审计目标和证据桥接。 未来，经单独授权的桥接工作可能会与以下项目集成： - [ae-framework](https://github.com/itdojp/ae-framework)，用于规范、保障证据、策略门控和发布判定。 - [GenAI Repo Auditor](https://github.com/itdojp/genai-repo-auditor)，用于防御性仓库安全审计。 ## 项目角色 本仓库为密码学通信产品提供特定领域的保障输入和集成契约。它不是第三个保障控制平面。 计划的功能包括： - 密码学通信安全属性、威胁和攻击者目录； - 证据要求和可重用能力模块； - 工具中立的保障配置文件和安全工件，供后续桥接映射； - 仓库审计包和目标模板，其上游映射仍是未来的工作； - 在开发保障和仓库审计之间建立内容绑定的证据桥接； - 确定性合成夹具和兼容性测试。 ## 状态 引导阶段 / pre-alpha。 目前尚无稳定的契约、兼容性承诺、生产就绪声明或认证声明。 冻结的引导契约仍然是封闭的、纯数据形式的 [`cryptocomm-pack/v1`](schema/cryptocomm-pack-v1.schema.json) 信封。其 `planned` 值仅代表意图，不会被重新解释为兼容性。 CCA-110 增加了三个独立的封闭 Draft 2020-12 契约： - [`cryptocomm-pack-manifest/v1`](schema/cryptocomm-pack-manifest-v1.schema.json)，用于发布者/源对单个不可变包的声明； - [`cryptocomm-pack-lock/v1`](schema/cryptocomm-pack-lock-v1.schema.json)，用于使用者解析确切的清单字节和解析器身份； - [`cryptocomm-compatibility-record/v1`](schema/cryptocomm-compatibility-record-v1.schema.json)，用于对一个确切清单与一个确切目标进行证据绑定的评估。 这些契约不包含完整的安全属性、威胁、模块或集成目录，并且不对 ae-framework 或 GenAI Repo Auditor 做出任何实际的兼容性声明。请参阅[契约版本控制](docs/CONTRACT_VERSIONING.md)和 [ADR 0002](docs/decisions/0002-pack-manifest-lock-and-compatibility.md)。 契约输入在进行 schema 和语义验证之前，会使用有界严格 UTF-8 JSON 解码。SHA-256 继续覆盖确切的原始字节；不隐含任何 JSON 规范化。 CCA-120 增加了三个封闭的、协议中立的目录契约和拟议的公开目录工件： - [`cryptocomm-property-catalog/v1`](schema/cryptocomm-property-catalog-v1.schema.json)：40 项安全、隐私、恢复、弹性和发布结果； - [`cryptocomm-attacker-catalog/v1`](schema/cryptocomm-attacker-catalog-v1.schema.json)：28 项攻击者能力和 8 个有界攻击者模型； - [`cryptocomm-threat-catalog/v1`](schema/cryptocomm-threat-catalog-v1.schema.json)：36 起引用了能力和受影响属性的不良事件或路径。 [人类可读](docs/CATALOG_COVERAGE.md)和[机器可读](pack/catalogs/v1/coverage-matrix.json)的覆盖矩阵公开了供审查的有界 Issue 范围。它们不是目录集契约、注册表、产品声明、安全证明或完整性声明。请参阅 [ADR 0003](docs/decisions/0003-security-catalog-separation-and-relationships.md)和[术语源基线](docs/SOURCE_BASELINE.md)。 CCA-130 增加了三个封闭契约、一个包含 15 个条目的公开协议中立模块目录，以及一个纯确定性解析器： - [`cryptocomm-capability-module-catalog/v1`](schema/cryptocomm-capability-module-catalog-v1.schema.json) 定义了可用或不受支持的可重用保障范围模块，以及与所有三个 CCA-120 目录的确切字节绑定； - [`cryptocomm-profile-request/v1`](schema/cryptocomm-profile-request-v1.schema.json) 记录明确的模块选择和确切的模块目录绑定； - [`cryptocomm-resolved-profile/v1`](schema/cryptocomm-resolved-profile-v1.schema.json) 记录字面模块结果、目录闭包、源模块包含原因，以及源自属性的假设和排除项。 解析器验证确切字节和绑定，扩展模块/属性依赖项，在没有优先级的情况下检测冲突，保留 `resolved`、`unknown`、`unsupported` 和 `unresolvable`，并输出字节稳定的 UTF-8 JSON。`complete` 和 `incomplete` 仅仅是解析状态。该模块目录不会创建任何默认值、建议、最强配置文件、产品声明、执行请求、证据结果或批准。请参阅 [ADR 0004](docs/decisions/0004-capability-modules-and-deterministic-profile-resolution.md)。 CCA-130 的边界是明确的：`module != attacker capability`，`module != product capability`，`profile request != approval`，`resolved profile != product claim`，`resolution outcome != evidence status`，以及 `complete resolution != product security`。 CCA-240 增加了四个封闭契约和一个纯的、确定性的本地仓库 新鲜度评估器： - [`cryptocomm-execution-result/v1`](schema/cryptocomm-execution-result-v1.schema.json) 在具有特定状态的发生次数和工件角色规则下，保留 `pass`、`fail`、`skip`、`unsupported`、`timeout`、`tool-error` 和 `not-run`； - [`cryptocomm-evidence-provenance/v1`](schema/cryptocomm-evidence-provenance-v1.schema.json) 绑定明确的主体形式、确切的输入字节、生产者/工具/环境/范围事实、证据来源/使用限制，以及公开内容或私有不透明工件； - [`cryptocomm-freshness-assessment/v1`](schema/cryptocomm-freshness-assessment-v1.schema.json) 仅根据明确的调用者事实保留 `fresh`、`stale`、`mismatched`、`unknown` 和 `not-assessed`； - [`cryptocomm-evidence-binding-set/v1`](schema/cryptocomm-evidence-binding-set-v1.schema.json) 绑定一个结果的确切字节、来源记录，以及始终存在的新鲜度评估。 绑定集是一个最小的组合根，而不是证据存储或 聚合决策。请参阅 [CCA-240 契约语义](docs/EVIDENCE_CONTRACTS.md) 和 [ADR 0005](docs/decisions/0005-execution-provenance-freshness-and-binding.md)。 CCA-240 不做任何 ae-framework 或 GenAI Repo Auditor 兼容性声明，并且 没有添加上游适配器。 ## 非目标 本项目不会： - 实现密码学原语或协议； - 认证产品； - 证明不存在漏洞； - 在没有人工安全审查的情况下确认漏洞； - 扫描或利用生产或预发布系统； - 自动批准合并、发布、风险接受或披露； - 存储生产机密、客户数据或原始私人审计证据。 ## 保障边界 工具、模型、扫描器、测试和形式化验证输出是证据生产者。它们不是人工批准或发布权限。 合成和仅用于测试的证据不得提升为真实证据。未执行、已跳过、不受支持、已超时或失败的检查不得表示为通过。 执行、来源、新鲜度和策略权限保持独立：`pass != evidence requirement satisfied`，`real != fresh`，`policy-evaluable != policy satisfied`，`fresh != sufficient`，以及 `evidence result != human approval`。 规范性边界记录在以下文档中： - [产品边界](docs/PRODUCT_BOUNDARY.md) - [公开/私有边界](docs/PUBLIC_PRIVATE_BOUNDARY.md) - [状态语义](docs/STATUS_SEMANTICS.md) - [架构](docs/ARCHITECTURE.md) ## 开发基线 - Node.js `>=22 <23`（引导程序在 `.node-version` 中固定为 `22.22.2`）； - pnpm `10.34.5`，通过 Corepack 选择并由 `packageManager` 固定； - TypeScript `5.9.3`； - JSON Schema Draft 2020-12 和 AJV `8.20.0`； - Vitest `4.1.10`。 安装确切的依赖图： ``` corepack enable pnpm install --frozen-lockfile ``` 仓库本地命令： ``` pnpm run build pnpm run typecheck pnpm run lint pnpm run test pnpm run check:schemas pnpm run check:docs pnpm run lint:workflows pnpm run verify ``` `pnpm run verify` 聚合了确定性、仓库本地的构建、类型检查、lint、 schema、测试、文档和工作流策略检查。在锁定的依赖项 安装完成后，这些命令都不会联系外部模型、扫描器、注册表后备或实时目标。 ## 工作区 引导布局为权威包数据、 契约、后续适配器、合成夹具、示例、schema 和测试保留了不同的区域。 占位符目录包含一个解释其推迟范围的 README；它们 不得被解释为已实现的集成。 请参阅[架构](docs/ARCHITECTURE.md)和[路线图](docs/ROADMAP.md)。 ## 贡献与安全 按照 [CONTRIBUTING.md](CONTRIBUTING.md) 中的说明，使用 Issue、专用分支和 Draft PR。 通过 [GitHub 私人漏洞报告](SECURITY.md)报告疑似漏洞；请勿将机密或 私人证据放入公开 Issue 中。 ## 许可证 Apache License 2.0。请参阅 [LICENSE](LICENSE)。 归属信息在 [NOTICE](NOTICE) 中，全仓库的许可 标注在 [REUSE.toml](REUSE.toml) 中。

标签：DevSecOps, JSON Schema, MITM代理, 上游代理, 密码学, 手动系统调用, 机器可读契约, 自动化攻击, 质量保证