Wardex — The CRA-Ready Release Gate for NIS2 & DORA

English | Português

Important

CRA Article 14 (v2.0): As obrigações de notificação por exploração activa do Cyber Resilience Act entram em vigor em setembro de 2026. O Wardex v2.0 implementa o caminho completo: correlação com o catálogo CISA KEV, exit code distinto (12), artefacto de notificação assinado com HMAC-SHA256, e registo de auditoria encadeado com os três prazos regulatórios. Este caminho não pode ser substituído por aceitações de risco.

---

Wardex é uma CLI e biblioteca Go que transforma decisões de segurança e conformidade em evidência auditável. Opera em dois modos independentes — nenhum exige o outro.

Posicionamento europeu: O Wardex é construído de raiz para os regulamentos europeus — NIS2, DORA, CRA — e para o padrão de compliance que está a emergir na UE. Cada decisão do release gate, cada aceitação de risco, cada artefacto Art14 é selado criptograficamente e registado num audit log encadeado que sobrevive a auditorias externas.

---

Audit Log Encadeado — Feature Principal

O audit log encadeado é o coração do Wardex. Cada entrada é ligada criptograficamente à anterior, formando uma cadeia inviolável de evidência.

┌─────────────┐    SHA-256    ┌─────────────┐    SHA-256    ┌─────────────┐
│  Entrada 1  │──────────────▶│  Entrada 2  │──────────────▶│  Entrada 3  │
│  (genesis)  │               │  (decisão)  │               │  (aceitação)│
└─────────────┘               └─────────────┘               └─────────────┘
       │                             │                             │
       ▼                             ▼                             ▼
  Config hash                 Config hash                   Config hash
  (CPL v2.2)                  (CPL v2.2)                   (CPL v2.2)

O que torna inviolável:

• Cada entrada inclui o hash da entrada anterior (hash encadeado)
• O hash da configuração (CPL) liga cada decisão à política em vigor
• Alterações ao audit log ou à configuração são detectadas imediatamente
• Exportável como JSONL para SIEM, Datadog, ou auditoria externa

# Verificar integridade da cadeia
wardex audit verify-chain --audit-log wardex-gate-audit.log

# Verificar ligação com configurações arquivadas
wardex audit verify-link --audit-log wardex-gate-audit.log --config-archive ./configs/

---

What's New — v2.2.2

Security Hardening:

• Workspace confinement: evaluate restringe acesso a ficheiros ao projecto raiz
• Pathguard: substitui SafePath ad-hoc por validação de paths
• SBOM generation com syft pinned e verificação SHA-256

Code Quality (PR #102):

• Atomic writes consolidados (pkg/atomicwrite) — corrigido bug de temp-file leak
• Gate pipeline compartilhado (pkg/gate) — DRY entre evaluate e wardex
• runEvaluate() decomposto de CC=123 em 11 helpers focados

Immutable Provenance (v2.3.0 branch):

• Manifesto criptográfico de provenance com BLAKE3 + Ed25519
• Âncora Bitcoin via OpenTimestamps
• Âncora Ethereum/Polygon via smart contract ProvenanceAnchor

---

Frameworks suportados

ISO/IEC 27001:2022 · SOC 2 · NIS 2 · DORA · CRA Article 14 · NIST CSF 2.0

wardex assess controls.yaml --framework iso27001  # predefinição
wardex assess controls.yaml --framework nis2
wardex assess controls.yaml --framework dora

---

Instalação

go install github.com/had-nu/wardex/v2@latest

Requer Go ≥ 1.26. Confirma que $(go env GOPATH)/bin está no teu $PATH.

Para compilar a partir do código-fonte:

git clone https://github.com/had-nu/wardex.git
cd wardex && make build

Docker

docker pull ghcr.io/had-nu/wardex:2.2.2

Helm (Kubernetes)

helm upgrade --install wardex deploy/helm/wardex/ \
  --set acceptSecret.value=$(openssl rand -hex 32)

Consulta deploy/helm/wardex/ para a referência completa do chart.

---

Quickstart

1. Avaliar risco de vulnerabilidades

# Converter output do Grype para formato Wardex
wardex convert grype test/usability/grype-results.json > vulns.yaml

# Avaliar com contexto do activo
wardex evaluate \
  --evidence vulns.yaml \
  --config doc/examples/wardex-config.yaml

# Dry-run — pré-visualizar sem escrever artefactos
wardex evaluate --evidence vulns.yaml --config doc/examples/wardex-config.yaml --dry-run

2. Gerar e gerir chaves

# Gerar chave Ed25519 para o sistema de confiança
wardex keygen

# A chave é criada em ~/.crypto/trust/root.key
# A pública é ~/.crypto/trust/root.key.pub (enviar ao admin)

3. Selar e verificar provenance

# Selar source tree (a partir da branch v2.3.0)
immutable-provenance seal \
  --dir . \
  --output provenance.yaml \
  --version v2.2.2 \
  --keyring ~/.crypto/provenance/signing.key

# Verificar integridade
immutable-provenance verify --manifest provenance.yaml --dir .

Exit codes: 0 ALLOW · 3 Adulterado · 4 Armazém inconsistente · 10 BLOCK · 11 Gap · 12 Explorado activamente

---

Comandos Principais

Comando	Descrição
wardex evaluate	Avalia vulnerabilidades contra o release gate
wardex assess	Análise de lacunas de conformidade
wardex convert grype/sbom	Converte output de scanners para formato Wardex
wardex enrich epss	Enriquece vulnerabilidades com dados EPSS
wardex accept request/verify/list	Gestão de aceitações de risco
wardex art14 list/show/verify	Ciclo de vida do artefacto CRA Article 14
wardex config hash/seal	CPL e sealed config
wardex audit verify-chain/verify-link	Verificação do audit log encadeado
wardex trust init/add	Gestão do trust store
wardex keygen	Geração de chaves Ed25519
wardex pki init/issue	Modo PKI com CA Ed25519
wardex policy show	Mostra política de risco configurada
wardex simulate	Simula decisões do gate com dados históricos

---

Release Gate Baseado em Risco

O gate avalia cada vulnerabilidade com o modelo:

R(v, α) = (CVSS(v)/10) × EPSS(v) × C(α) × E(α) × (1 − Φ(α))

O resultado é comparado com o apetite de risco definido em wardex-config.yaml. Três bandas possíveis: ALLOW, WARN, BLOCK.

Configuração

# wardex-config.yaml
release_gate:
  enabled: true
  risk_appetite: 0.20
  warn_above: 0.12
  mode: any               # "any" bloqueia se qualquer vuln exceder; "aggregate" usa soma
  asset_context:
    criticality: 0.8
    internet_facing: true
    requires_auth: true
  compensating_controls:
    - type: waf
      effectiveness: 0.35

A mesma CVE, quatro contextos

CVE	CVSS	EPSS	[BANK]	[SAAS]	[INFRA]	[HOSP]
Log4Shell	10.0	0.94	1.41 BLOCK	0.75 BLOCK	1.41 BLOCK	1.13 BLOCK
xz backdoor	10.0	0.86	1.29 BLOCK	0.69 BLOCK	1.29 BLOCK	1.03 BLOCK
curl SOCKS5	9.8	0.26	0.38 BLOCK	0.20 WARN	0.38 BLOCK	0.31 BLOCK
minimist	9.8	0.01	0.01 ALLOW	0.01 ALLOW	0.01 ALLOW	0.01 ALLOW

Enriquecimento EPSS

wardex enrich epss wardex-vulns.yaml --output epss-enrich.yaml
wardex evaluate --epss-enrichment epss-enrich.yaml --evidence vulns.yaml controls.yaml

Integração CI/CD

# .github/workflows/wardex-gate.yml
jobs:
  risk-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install Wardex
        run: go install github.com/had-nu/wardex/v2@latest
      - name: Evaluate risk gate
        run: |
          wardex evaluate \
            --config .wardex/config.yaml \
            --evidence vulns.yaml \
            controls.yaml

---

Análise de Gaps de Conformidade

O Wardex compara o que o infosec declarou com o que está operacionalmente activo, e identifica o delta em relação ao framework.

Categoria	Significado
Coberto	Presente na camada implemented, maturidade >= 3, com evidência operacional.
Política sem execução	Documentado apenas. Nenhum controlo implementado correspondente.
Prática sem governação	Implementado mas sem política documentada.
Lacuna	Ausente em ambas as camadas para um controlo do catálogo.

wardex assess documented-controls.yaml implemented-controls.yaml \
  --framework iso27001 \
  -o markdown

# Com inventário de activos
wardex assess documented-controls.yaml implemented-controls.yaml \
  --assets assets.yaml \
  --framework iso27001 \
  -o json --out-file posture.json

---

CRA Article 14

As obrigações de notificação por exploração activa do Regulamento Europeu de Resiliência Cibernética entram em vigor em setembro de 2026.

Active Exploitation Hard Stop: Quando uma vulnerabilidade é classificada como activamente explorada (actively_exploited: true), o wardex evaluate termina com código 12 — distinto do bloqueio normal (10). Não pode ser substituído por aceitações de risco.

# Artefacto Art14
wardex art14 list
wardex art14 show <artefact-id>
wardex art14 verify <artefact-id>
wardex art14 mark-dispatched <artefact-id> --phase early-warning

# Aceitação de exploit activo
wardex accept active-exploit --cve CVE-2024-3094 --justification "..." --art14-artefact wardex-art14-....json

Consulta o Playbook de Governação para o fluxo completo.

---

Gestão de Chaves & Governação

Chaves Criptográficas

Todas as chaves Ed25519 são armazenadas em ~/.crypto/ com subdiretórios por finalidade:

~/.crypto/
├── provenance/          # Assinatura de manifestos de provenance
│   ├── signing.key      # Ed25519 privada (mode 0400)
│   └── signing.key.pub  # Ed25519 pública
└── trust/               # Sistema de confiança wardex
    └── root.key         # Chave raiz (gerada por wardex keygen)

Permissões: Directórios 700, chaves privadas 0400, chaves públicas 0644.

Verificação de Provenance — v2.2.2

Para verificar a integridade do source tree v2.2.2, use a chave pública abaixo e o root hash do manifesto:

Chave pública de assinatura (v2.2.2):

ed25519:HsD9e6BB2LlaeKODGqgWUZoflDgdUH1HWTdyWA7dGqE=

Root hash (BLAKE3, 113 ficheiros):

sha256:6f972edf99f5457f8fb13668c529f4343dab7a76d20b67ea746ebdf54d910fee

# Descarregar o manifesto assinado do release
gh release download v2.2.2 --pattern "provenance-manifest*"

# Verificar (requer o binário immutable-provenance da branch v2.3.0)
immutable-provenance verify \
  --manifest provenance-manifest-v2.2.2-signed.yaml \
  --dir /caminho/para/wardex-v2.2.2

Trust Store & Sealed Config (WexState)

Para conformidade DORA e cadeias de custódia não-repudiáveis:

• Identidade forte: Chaves Ed25519 para Admins, CISOs e Analistas.
• Sealed config: As políticas de risco não podem ser alteradas sem aprovação executiva.
• Trust store append-only: Registo central de chaves autorizadas e revogações.

# Sela a política (acção do CISO)
wardex config seal --keyring ~/.crypto/trust/root.key --input config.yaml --out config.wexstate

# Avalia com verificação obrigatória do selo
wardex evaluate --config config.wexstate --evidence vulns.yaml --strict

Modo PKI

Para ambientes que exigem identidade baseada em certificados:

wardex pki init --org "A Tua Empresa" --validity 3650d
wardex pki issue --name ci-agent --out ci-agent.wex
wardex config seal --keyring ci-agent.wex --input config.yaml --out config.wexstate

---

Environment & Syslog

Variável	Predefinição	Descrição
WARDEX_ACCEPT_SECRET	—	Chave HMAC-SHA256 para assinar aceitações e artefactos Art14 (mín 32 car.)
WARDEX_ACTOR	cli	Identidade registada nas entradas de auditoria
WARDEX_SYSLOG_ENDPOINT	—	tcp://syslog.example.com:514 — encaminhar eventos para syslog central
WARDEX_SYSLOG_PROTO	tcp	Transporte syslog: tcp, udp, ou tls
WARDEX_SYSLOG_CERT	—	Caminho para cert TLS cliente para tls
WARDEX_SYSLOG_KEY	—	Caminho para key TLS cliente para tls
WARDEX_SYSLOG_CA	—	Caminho para CA personalizada para tls

---

SDK

import "github.com/had-nu/wardex/v2/pkg/sdk"

controls, _ := sdk.LoadControls("./controls.yaml")
result, _   := sdk.Analyze(controls, "iso27001")

fmt.Printf("Coverage: %.1f%%\n", result.Summary.GlobalCoverage)

Para o release gate:

import (
    "github.com/had-nu/wardex/v2/pkg/model"
    "github.com/had-nu/wardex/v2/pkg/releasegate"
)

gate := releasegate.Gate{
    AssetContext: model.AssetContext{
        Criticality:    0.9,
        InternetFacing: true,
        RequiresAuth:   true,
    },
    CompensatingControls: []model.CompensatingControl{
        {Type: "waf", Effectiveness: 0.35},
    },
    RiskAppetite: 0.20,
}

report := gate.Evaluate([]model.Vulnerability{
    {CVEID: "CVE-2024-1234", CVSSBase: 9.1, EPSSScore: 0.84, Reachable: true},
})

fmt.Println(report.OverallDecision) // ALLOW | WARN | BLOCK

---

Documentação

• Arquitectura e funcionamento interno
• Contexto de negócio e o problema do gate binário
• Playbook — casos de uso com comandos completos
• Governação — Trust Store & Sealed Config Playbook
• Integração com GitHub Actions
• Helm chart (referência)
• Exit codes
• Ambiente de desenvolvimento (docker-compose)
• CHANGELOG
• Contribuir

---

Licenciamento

Duplo licenciamento:

AGPL-3.0 (gratuito): uso em pipelines CI/CD internas ou em projectos open-source que disponibilizem o código-fonte.

Licença comercial (pago): integração em produtos proprietários, plataformas SaaS, ou distribuição sem abertura do código-fonte. Consulta os Termos Comerciais ou contacta andre_ataide@proton.me.