had-nu/wardex

GitHub: had-nu/wardex

基于风险的合规映射与发布门控引擎,将安全控制映射至 ISO 27001、SOC 2、NIS 2、DORA 框架,并结合业务上下文进行智能发布决策。

Stars: 1 | Forks: 0

Wardex

差距分析、基于风险的发布门控与业务影响 — CLI 工具与 Go 引擎

[![Wardex](https://img.shields.io/badge/Risk--based_Release-Wardex_v1.7.1-FF00FF?style=flat-square&logo=data:image/svg%2bxml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSIxNiIgaGVpZ2h0PSIxNiI+PHRleHQgeD0iMiIgeT0iMTQiIGZpbGw9IndoaXRlIiBmb250LXNpemU9IjE2IiBmb250LWZhbWlseT0ic2VyaWYiPs6pPC90ZXh0Pjwvc3ZnPgo=)](https://github.com/had-nu/wardex) ![Go](https://img.shields.io/badge/Go-1.26-00ADD8?style=flat-square&logo=go&logoColor=white) [![Go Report Card](https://goreportcard.com/badge/github.com/had-nu/wardex?style=flat-square)](https://goreportcard.com/report/github.com/had-nu/wardex) [![CI Pipeline](https://static.pigsec.cn/wp-content/uploads/repos/2026/04/b294c6aee5102924.svg)](https://github.com/had-nu/wardex/actions/workflows/ci.yml) ![Coverage Gate](https://img.shields.io/badge/coverage-%E2%89%A570%25-brightgreen?style=flat-square) ![Security Hardened](https://img.shields.io/badge/Security-TeamPCP_Hardened-success?style=flat-square&logo=github-actions&logoColor=white) ![ISO-27001](https://img.shields.io/badge/Compliance-ISO_27001%3A2022-8A2BE2?style=flat-square&logo=checkmarx&logoColor=white) [![License: AGPL v3 / Commercial](https://img.shields.io/badge/License-Dual_Licensed-8A2BE2.svg?style=flat-square)](#许可与商业用途) [![Powered by lazy.go](https://img.shields.io/badge/Powered_by-lazy.go-8A2BE2?style=flat-square&logo=go&logoColor=white)](https://github.com/had-nu/lazy.go)
English | Français | Castellano | Português

Wardex Secure Release Gate Banner
Wardex 是一个用 Go 语言编写的健壮命令行界面 (CLI) 工具和引擎,它接收您组织中已实施的安全控制措施,并将其映射到多个全球合规框架,包括 ISO/IEC 27001:2022 (附录 A) 的 93 项控制、SOC 2、NIS 2 和 DORA。 Wardex 设计为既可作为独立 CLI 使用,也可作为可集成 SDK 使用,在您的 CI/CD 流水线中充当 **基于风险的发布门控**。Wardex 不是基于静态二元指标(如 "CVSS > 7.0")来阻止软件发布,而是计算实际的发布风险,根据业务影响、基础设施暴露和现有的补偿控制来调整技术漏洞。 ## 为什么选择 Wardex? 请参阅 `/doc` 中的文档,以了解架构愿景和该工具解决的业务问题: - [业务愿景 (BUSINESS_VIEW.md)](doc/BUSINESS_VIEW.md) - [架构与技术数学 (TECHNICAL_VIEW.md)](doc/TECHNICAL_VIEW.md) - [面向审计员的不可否认性与加密架构 (SOC 2, ISO 27001)](doc/wardex-g20-audit-readiness.md) - [教学用例 — 10 个包含真实输入和输出的完整场景](doc/USECASES.md) ## 支持的框架(从 v1.5.0 起) Wardex 通过 `--framework` 标志为以下合规标准提供原生映射: - **ISO/IEC 27001:2022** (`iso27001` - 默认) - **SOC 2** (`soc2` - 信任服务标准) - **NIS 2** (`nis2` - 欧盟指令 2022/2555) - **DORA** (`dora` - 数字运营弹性法案) ## 许可与商业用途 Wardex 采用 **双重许可** 模式运营,以保护开源创新,同时允许安全的专有集成。 1. **开源与内部使用(免费)**:如果您严格将 Wardex 用于内部 CI/CD 流水线,或者将 Wardex 整合到一个项目中并将该项目代码完全开源,则受 [AGPL-3.0](LICENSE) 保护。 2. **商业用途与 SaaS 集成(付费)**:如果您打算将 Wardex 引擎嵌入商业产品后端、企业 SaaS 平台,或以专有方式分发(而不公开源代码),**必须购买商业许可证**。 如需获取企业的商业许可证信息,请阅读 [相关商业条款](doc/COMMERCIAL_LICENSE.md) 或联系:**andre_ataide@proton.me**。 ## 编译与安装 请确保已安装 [Go (>= 1.26)](https://go.dev/doc/install)。 ### 选项 1:全局安装(推荐) 您可以将 Wardex 直接安装到系统中,以便在任何地方运行 `wardex` 命令: ``` go install github.com/had-nu/wardex@latest ``` *(请确保 `$(go env GOPATH)/bin` 目录已包含在您的 `$PATH` 或环境变量中)* ### 选项 2:从源代码本地编译 如果您希望克隆仓库以进行本地测试或开发: ``` git clone https://github.com/had-nu/wardex.git cd wardex make build ``` ### 更新至最新版本 当发布新的补丁或次要版本(例如:`v1.1.1`)时,您可以通过获取最新代码或标签并重新构建二进制文件来进行更新: ``` # 全局安装 go install github.com/had-nu/wardex@latest # 用于本地构建(例如:选择特定的 tag) git fetch --tags git checkout v1.7.1 <<<<<<< HEAD make build ======= go build -o wardex . >>>>>>> origin/main ``` 有关发布说明和错误修复的详细信息,请参阅 [CHANGELOG.md](CHANGELOG.md)。 ## 使用方法 Wardex 允许以简单的 YAML 或 JSON 格式导入策略,将漏洞(例如:Grype 输出或 SBOM)交叉比对到目标文件中,并验证门控: ``` ./bin/wardex --config=test/testdata/wardex-config.yaml --gate=test/testdata/vulnerabilities.yaml test/testdata/dummy_controls.yaml ``` 这将生成可视化报告(Markdown、CSV 或 JSON 格式),展示 ISO 27001 四大全局领域(人员、流程、技术、物理)的成熟度分析,并根据组织的校准风险执行决策策略(ALLOW / BLOCK / WARN)。 ## GitHub Actions (CI/CD) 集成 将 **Wardex** 集成到 GitHub Actions 中,可以将您的流水线转变为一个真正的 **风险治理** 流程。Wardex 在安全扫描之后充当“发布门控”。 查看一个实际示例: ``` # .github/workflows/wardex-gate.yml jobs: risk-governance: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 # Instalação Segura (v1.7.1) - name: Install Wardex run: | VERSION="v1.7.1" curl -sSL "https://github.com/had-nu/wardex/releases/download/${VERSION}/wardex_Linux_x86_64.tar.gz" | tar -xz sudo mv wardex /usr/local/bin/ # Avaliação de Risco - name: Evaluate Risk Gate run: | wardex --config ./doc/examples/wardex-config.yaml \ --gate ./evidence.json \ ./doc/examples/policy-nis2.yaml \ --fail-above 0.9 ``` 请参阅示例文件以配置您的流水线: - [CI/CD 配置 (wardex-config.yaml)](doc/examples/wardex-config.yaml) - [NIS2/ISO27001 策略示例 (policy-nis2.yaml)](doc/examples/policy-nis2.yaml) ## 新功能 (v1.7.1) - **治理命令(自动化就绪)**:用于复杂流水线的新子命令:`wardex evaluate`(专注于门控)、`wardex aggregate`(复合决策)和 `wardex policy check-expiry`(YAML 异常审计)。 - **风险经验校准**:根据 NVD/EPSS 数据的统计分析,重新校准了 `Criticality`(关键性)和 `Exposure`(暴露)参数,以适应 Hospital (1.5)、Startup (0.75) 和 Dev 概况。 - **EPSS 富化与人在回路 (HITL)**:由于缺少 EPSS 向量(此时 Wardex 假定“失效即关闭” 1.0)而导致的评估失败,现在可以通过 FIRST.org API 进行富化。 - **严格的语义失效即关闭**:针对未知漏洞分数的 `0.05` 回退值已撤销至 `0.0`。在没有具体数据的情况下,Wardex 假定最大风险。 将 **Wardex** 集成到 GitHub Actions 中,可以将您的流水线转变为一个真正的 **风险治理** 流程。Wardex 在安全扫描之后充当“发布门控”。 查看一个实际示例: ``` # .github/workflows/wardex-gate.yml jobs: risk-governance: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 # Instalação Segura (v1.7.1) - name: Install Wardex run: | VERSION="v1.7.1" curl -sSL "https://github.com/had-nu/wardex/releases/download/${VERSION}/wardex_Linux_x86_64.tar.gz" | tar -xz sudo mv wardex /usr/local/bin/ # Avaliação de Risco - name: Evaluate Risk Gate run: | wardex --config ./doc/examples/wardex-config.yaml \ --gate ./evidence.json \ ./doc/examples/policy-nis2.yaml \ --fail-above 0.9 ``` 请参阅示例文件以配置您的流水线: - [CI/CD 配置 (wardex-config.yaml)](doc/examples/wardex-config.yaml) - [NIS2/ISO27001 策略示例 (policy-nis2.yaml)](doc/examples/policy-nis2.yaml) ## 新功能 (v1.7.1) - **治理命令(自动化就绪)**:用于复杂流水线的新子命令:`wardex evaluate`(专注于门控)、`wardex aggregate`(复合决策)和 `wardex policy check-expiry`(YAML 异常审计)。 - **风险经验校准**:根据 NVD/EPSS 数据的统计分析,重新校准了 `Criticality`(关键性)和 `Exposure`(暴露)参数,以适应 Hospital (1.5)、Startup (0.75) 和 Dev 概况。 - **EPSS 富化与人在回路 (HITL)**:由于缺少 EPSS 向量(此时 Wardex 假定“失效即关闭” 1.0)而导致的评估失败,现在可以通过 FIRST.org API 进行富化。 - **严格的语义失效即关闭**:针对未知漏洞分数的 `0.05` 回退值已撤销至 `0.0`。在没有具体数据的情况下,Wardex 假定最大风险。 ## 作为库使用 (SDK) **Wardex** 的架构设计具有高度的职责分离(在 `pkg/` 目录中)。这意味着除了使用 CLI 外,Wardex 还可以作为库 导入到任何其他 Go 项目中,例如 REST API、GRC 编排服务或机器人。 以下是用于 *基于风险的发布门控* 评估的编程提交示例: ``` package main import ( "fmt" "github.com/had-nu/wardex/pkg/model" "github.com/had-nu/wardex/pkg/releasegate" ) func main() { // Configure o contexto da organização e do ativo gate := releasegate.Gate{ AssetContext: model.AssetContext{ Criticality: 0.9, InternetFacing: true, RequiresAuth: true, }, CompensatingControls: []model.CompensatingControl{ {Type: "waf", Effectiveness: 0.35}, }, RiskAppetite: 6.0, } vulns := []model.Vulnerability{ {CVEID: "CVE-2024-1234", CVSSBase: 9.1, EPSSScore: 0.84, Reachable: true}, } // Avalia o risco composto diretamente dentro do seu código report := gate.Evaluate(vulns) fmt.Printf("A decisão do Gate para este lançamento foi: %s\n", report.OverallDecision) } ``` ## 异常管理与风险接受 当 Wardex 因超出允许的风险偏好而阻止发布时,组织可以通过 `wardex accept` 子命令正式且可审计地管理异常: ``` # 请求批准被阻止漏洞的风险豁免 wardex accept request --report report.json --cve CVE-2024-1234 --accepted-by sec-lead@company.com --justification "Risco mitigado por controlos externos" --expires 30d # 验证所有活跃豁免的加密完整性 wardex accept verify ``` Wardex 使用 HMAC-SHA256 签名、仅追加审计日志 (`JSONL`) 和配置偏差检测来确保这些异常的完整性。 ### EPSS 富化与人在回路 (HITL) 当您的上游 *扫描器* 遗漏 EPSS 时,Wardex **假定最坏情况(EPSS 1.0 = 100%)**,阻止流水线直到显式验证: ``` # 当 CI 因缺少 EPSS 而阻塞时: wardex enrich epss wardex-vulns.yaml --output epss-enrich.yaml # 在 Pipeline 中,附加 signed payload: wardex --epss-enrichment epss-enrich.yaml --gate vulns.yaml controls.json ``` 该命令查询 FIRST.org API (`api.first.org`),获取真实概率,并通过 HMAC-SHA256 对结果进行签名。 ### 情境风险 -- 同一个 CVE,4 种决策 Wardex 计算:`FinalRisk = (CVSS x EPSS) x (1 - 补偿控制) x 关键性 x 暴露` | CVE | CVSS | EPSS | [BANK] | [SAAS] | [DEV] | [HOSP] | |---|---|---|---|---|---|---| | **Log4Shell** | 10.0 | 0.94 | **14.2** `BLOCK` | **2.5** `BLOCK` | **0.3** `ALLOW` | **7.9** `BLOCK` | | **xz backdoor** | 10.0 | 0.86 | **12.8** `BLOCK` | **2.3** `BLOCK` | **0.2** `ALLOW` | **7.1** `BLOCK` | | **curl SOCKS5** | 9.8 | 0.26 | **3.9** `BLOCK` | **0.7** `ALLOW` | **0.1** `ALLOW` | **2.1** `BLOCK` | | **minimist** | 9.8 | 0.01 | **0.1** `ALLOW` | **0.0** `ALLOW` | **0.0** `ALLOW` | **0.1** `ALLOW` | 经 **237 个真实 CVE** 和 FIRST.org 实时 EPSS 评分验证: | 概况 | 风险偏好 | BLOCK | ALLOW | % Block | |---|---|---|---|---| | [BANK] 一级银行 (DORA) | 0.5 | **176** | 57 | 74% | | [HOSP] 医院 (HIPAA) | 0.8 | **168** | 63 | 71% | | [SAAS] SaaS 初创公司 | 2.0 | **111** | 86 | 47% | | [DEV] 开发沙箱 | 4.0 | **0** | 238 | 0% | 完整报告:[EPSS 多情境压力测试报告](doc/epss-stress-test-report.md) ## 本地策略管理 Wardex 允许使用其自定义 YAML 语法,按框架和域(例如:ISO 27001)对策略文件进行细粒度管理。无需手动创建或编辑冗长的文件,您可以使用 `policy` 子命令安全地操作控制措施,并支持自动化工具: ``` # 验证所有 YAML 文件,确保 schema 完整性 wardex policy validate frameworks/iso27001/ # 以可读格式列出所有 control 的合规状态 wardex policy list frameworks/iso27001/ # Upsert(添加或更新)单个 control 而不破坏手动 YAML wardex policy add \ --file frameworks/iso27001/technological_controls.yml \ --id A.8.5 \ --title "Secure authentication" \ --status partial \ --owner "Security Team" \ --note "MFA enforced; hardware tokens pending rollout" ``` 这确保文件始终遵循预期的 _schema_,简化了审计流程,并能原生集成到使用 Wardex 作为治理即代码的仓库中。 更多配置详情请参阅 [Wardex Wiki: 基于风险的门控配置](https://github.com/had-nu/wardex/wiki)。
标签:CLI 工具, DevSecOps, DORA, EVTX分析, Go 语言, GRC, Homebrew安装, ISO 27001, NIS 2, SOC 2, 上游代理, 业务影响分析, 发布门禁, 合规性管理, 合规映射, 基于风险的合规, 安全合规, 安全引擎, 安全态势管理, 安全控制, 审计自动化, 差距分析, 持续合规, 日志审计, 策略即代码, 网络代理, 聊天机器人安全