用途
该技能提供与透明度原则对齐的开源治理方案，帮助仓库维护者落实安全徽章、许可证合规、SBOM 生成与安全文档，使公开证据同时服务于运营需要与客户展示。
适用场景包括：创建新的公开仓库；准备 OpenSSF Scorecard 评估（目标 ≥7.0）；配置 CII 最佳实践徽章（最低 Passing）；设置 SLSA Level 3 构建证明；实施许可证合规扫描（FOSSA）；生成 SBOM（CycloneDX/SPDX）；创建安全架构文档；规划协同漏洞披露；响应客户尽职调查。
不适用于：私有/内部仓库（适用不同策略）；安全事件响应（使用 incident-response 技能）；战术性漏洞修复（使用 vulnerability-management 技能）。
主要能力
安全徽章架构
仓库需配置以下徽章：OpenSSF Scorecard（目标 ≥7.0，含 15 项自动检查，如分支保护、签名提交、依赖固定、漏洞扫描、代码审查）；CII 最佳实践（最低 Passing，含 70+ 项标准，覆盖项目基础、变更控制、质量保证、安全、分析）；SLSA Level 3（构建来源、签名制品、可复现构建）；SonarCloud 质量门禁（代码覆盖率 ≥80%、复杂度控制、安全热点为 0）；FOSSA 许可证合规（自动扫描、归属管理、合规报告）。这些证据汇总为公开证据，用于建立客户信任与竞争优势。
仓库设置清单
第一阶段：初始安全配置——启用分支保护（要求 PR 审查 1+ 批准者、状态检查通过、签名提交、限制推送）、启用 Dependabot 安全更新、GitHub 秘密扫描、CodeQL 分析、SonarCloud 自动安全扫描。
第二阶段：文档要求——创建 SECURITY_ARCHITECTURE.md（含 Mermaid 图）、FUTURE_SECURITY_ARCHITECTURE.md、SECURITY.md（漏洞披露流程）、WORKFLOWS.md（CI/CD 安全门禁）、LICENSE（Apache 2.0 或兼容）、NOTICE（第三方归属）、CODE_OF_CONDUCT.md、CONTRIBUTING.md、CRA-ASSESSMENT.md（欧盟网络弹性法案）。
第三阶段：许可证合规——集成 FOSSA 扫描、生成 LICENSES/ 目录、添加 .reuse/dep5、配置自动 NOTICE 生成、审查依赖许可证兼容性。
第四阶段：安全徽章——注册 OpenSSF Scorecard、申请 CII 最佳实践、配置 SLSA 证明、添加 SonarCloud 与 FOSSA 徽章、添加自定义安全徽章。
第五阶段：供应链安全——实现 SBOM 生成（CycloneDX 或 SPDX）、配置制品签名（Sigstore/cosign）、固定所有 GitHub Actions 依赖、启用 Dependabot 版本更新、设置自动漏洞扫描。
OpenSSF Scorecard 优化
关键检查（必须通过）：分支保护（要求状态检查、PR 审查、管理员强制执行）；签名发布（使用 sigstore 签名制品并生成 SBOM）；依赖固定（所有依赖固定到具体 SHA）；令牌权限（最小权限，如 contents: read）；漏洞（启用 Dependabot 警报、CodeQL、SonarCloud，设定修复 SLA）；代码审查（至少 1 个批准审查、禁止直接提交默认分支、使用 CODEOWNERS）。
重要检查（应当通过）：危险工作流（避免未审查的 pull_request_target、防止脚本注入）；许可证（包含 LICENSE 文件、SPDX 标识符）；SAST（CodeQL 安全查询、SonarCloud 安全热点检测）；依赖更新工具（Dependabot 安全与版本更新）。
其他检查：模糊测试（Java/Spring 项目配置 JQF）；维护状态（至少每 90 天提交、14 天内响应问题）；打包（发布到 npm/Maven Central 并带来源）；安全策略（维护 SECURITY.md）；二进制制品（避免提交二进制文件）。
CII 最佳实践徽章要求
Passing 级别最低要求：基础（13 项，含项目网站、文档、FLOSS 许可证、公开版本控制仓库、公开讨论论坛、英文沟通、缺陷报告流程、漏洞披露、可构建系统、自动化测试套件、新功能测试、警告标志、发布说明）；变更控制（6 项，含公开版本控制、SemVer 版本编号、变更日志、历史版本可用、提交者标识、提交审查）；质量（13 项，含 CI 自动化测试、无构建警告、静态分析、动态分析、内存安全、语句覆盖 ≥80%、分支覆盖 ≥70%、新功能新测试、持续集成测试、测试策略文档）；安全（11 项，含安全编码标准、HTTPS、TLS 1.2+、安全交付机制、自动漏洞检测、无已知未修补严重漏洞、公开漏洞披露流程、私密报告渠道、加固机制文档、密码学公开评审、输入验证）；分析（10 项，含静态代码分析、处理所有中危以上问题、内存安全语言或分析、发布动态分析、代码覆盖率测量、持续自动化测试）。
SLSA Level 3 实现
要求：源完整性（GitHub 托管、签名提交）；构建完整性（可复现构建、来源证明）；来源（所有制品签名证明）；隔离（构建在临时环境运行）。实现方式为在 GitHub Actions 中配置 slsa-github-generator 生成来源，并使用 gh attestation verify 验证。
许可证合规框架
预批准许可证：MIT、Apache 2.0、BSD（2/3 条款）、ISC、LGPL 2.1/3.0、MPL 2.0、EPL 2.0、CC-BY-4.0、CC-BY-SA-4.0。需 CEO 批准：GPL 2.0/3.0、AGPL 3.0、自定义许可证、修改版许可证。禁止使用：含广告条款的许可证、与 Apache 2.0 不兼容的许可证、条款不清或缺少归属的许可证。
FOSSA 集成通过 GitHub Actions 工作流调用 fossas/fossa-action，并在 README 添加 FOSSA 状态徽章。
SBOM 生成
按安全开发策略，所有发布需生成 SBOM。Java/Maven 项目使用 cyclonedx-maven-plugin 生成 CycloneDX 格式（输出 target/bom.json）；npm/Node.js 项目使用 @cyclonedx/cyclonedx-npm 生成 SPDX 格式（输出 sbom.spdx.json）；SBOM 附加到 GitHub Release 资产。
漏洞管理 SLA
严重：自动检测（Dependabot/CodeQL），24 小时内修复，立即通知 CEO。高危：自动检测，7 天内修复，每周状态更新。中危：自动检测，30 天内修复，每月审查。低危：自动检测，90 天内修复，每季度审查。修复选项：更新依赖（首选）、应用补丁、缓解（补偿控制）、接受风险（记录于风险登记册，需 CEO 批准）。
安全架构文档矩阵
SECURITY_ARCHITECTURE.md（当前安全实现，含认证流、数据流、基础设施图，每次发布更新）；FUTURE_SECURITY_ARCHITECTURE.md（计划改进，含目标架构、迁移计划，每季度更新）；THREAT_MODEL.md（STRIDE 分析、攻击树，每年或重大变更时更新）；WORKFLOWS.md（CI/CD 安全门禁，工作流变更时更新）；SECURITY.md（漏洞披露，每年更新）。Mermaid 图类型包括 flowchart、sequenceDiagram、graph、erDiagram。
使用方式
新仓库设置步骤：使用模板创建公开仓库；启用漏洞警报与自动安全修复；配置分支保护；在 FOSSA 添加仓库；在 OpenSSF Scorecard 注册；申请 CII 最佳实践；在 SonarCloud 导入项目；创建所需文档；在 README 添加徽章。
适用场景与限制
适用于公开仓库的开源治理、安全徽章配置、许可证合规、SBOM 生成、供应链安全与客户尽职调查准备。不适用于私有/内部仓库、安全事件响应与战术性漏洞修复。具体实施效果取决于仓库实际配置与外部服务可用性。