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

Important

CRA Article 14 (v2.0): The Cyber Resilience Act's active exploitation notification obligations enter into force in September 2026. Wardex v2.0 implements the full path: CISA KEV catalogue correlation, a distinct exit code (12), an HMAC-SHA256 signed notification artefact, and a chained audit entry with the three regulatory deadlines. This path cannot be overridden by risk acceptances.

EU AI Act (v2.4.0): The Artificial Intelligence Regulation (EU 2024/1689) is now available as a controls framework. 31 catalogued controls covering all key articles: prohibited practices, risk management, data governance, transparency, human oversight, accuracy/robustness/cybersecurity, provider and deployer obligations, GPAI, post-market monitoring, and incident reporting. Use --framework eu_ai_act to assess compliance.

Wardex is a CLI and Go library that turns security and compliance decisions into auditable evidence. Two independent modes — neither requires the other.

European positioning: Wardex is built from the ground up for European regulations — NIS2, DORA, CRA, EU AI Act — and for the compliance standard emerging across the EU. Every release gate decision, every risk acceptance, every Art14 artefact is cryptographically sealed and recorded in a chained audit log that survives external audits.

Chained Audit Log — Core Feature

The chained audit log is the heart of Wardex. Each entry is cryptographically linked to the previous one, forming an unbreakable chain of evidence.

┌─────────────┐    SHA-256    ┌─────────────┐    SHA-256    ┌─────────────┐
│  Entry 1    │──────────────▶│  Entry 2    │──────────────▶│  Entry 3    │
│  (genesis)  │               │  (decision) │               │  (acceptance)│
└─────────────┘               └─────────────┘               └─────────────┘
       │                             │                             │
       ▼                             ▼                             ▼
  Config hash                 Config hash                   Config hash
  (CPL v2.2)                  (CPL v2.2)                   (CPL v2.2)

What makes it tamper-proof:

Each entry includes the hash of the previous entry (chained hashing)
The config hash (CPL) links every decision to the policy in effect
Any modification to the audit log or config is immediately detectable
Exportable as JSONL for SIEM, Datadog, or external audit

# Verify chain integrity
wardex audit verify-chain --audit-log wardex-gate-audit.log

# Verify linkage with archived configurations
wardex audit verify-link --audit-log wardex-gate-audit.log --config-archive ./configs/

What's New — v2.4.0

EU AI Act Framework (31 controls):

Complete catalogue of Regulation (EU) 2024/1689: prohibited practices, risk management, data governance, technical documentation, transparency, human oversight, accuracy/robustness/cybersecurity, provider and deployer obligations, fundamental rights impact assessment, GPAI, post-market monitoring, incident reporting
Usage: wardex --framework eu_ai_act ./frameworks/eu_ai_act/*.yml

Gleipnir Provenance Anchoring:

Immutable integrity proof for release artifacts via wardex provenance seal
Supports embedded consensus engine (gleipnir-embedded) or remote gRPC server
Chain seal with SHA-256 of all artifacts + cryptographic anchor

gRPC driver isolation:

The gRPC provenance driver (with protobuf) is now behind the grpc build tag to prevent init panic. To use: go build -tags grpc.

Supported frameworks

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

wardex assess controls.yaml --framework iso27001     # default
wardex assess controls.yaml --framework nis2
wardex assess controls.yaml --framework dora
wardex assess controls.yaml --framework eu_ai_act    # new v2.4.0

Installation

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

Requires Go ≥ 1.26. Ensure $(go env GOPATH)/bin is in your $PATH.

To build from source:

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)

See deploy/helm/wardex/ for the full chart reference.

Quickstart

1. Evaluate vulnerability risk

# Convert Grype output to Wardex format
wardex convert grype test/usability/grype-results.json > vulns.yaml

# Evaluate with asset context
wardex evaluate \
  --evidence vulns.yaml \
  --config doc/examples/wardex-config.yaml

# Dry-run — preview without writing artefacts
wardex evaluate --evidence vulns.yaml --config doc/examples/wardex-config.yaml --dry-run

2. Generate and manage keys

# Generate Ed25519 keypair for the trust system
wardex keygen

# Key is created at ~/.crypto/trust/root.key
# Public key is ~/.crypto/trust/root.key.pub (send to admin)

3. Seal and verify provenance

# Seal artifact directory with Gleipnir (v2.4.0+)
wardex provenance seal \
  --dir ./dist \
  --output chain-seal.json \
  --label "release-v2.4.0"

# Verify integrity
wardex provenance verify <chain-hash>

Exit codes: 0 ALLOW · 3 Tampered · 4 Store inconsistent · 10 BLOCK · 11 Gap · 12 Actively exploited

Command Reference

Command	Description
`wardex evaluate`	Evaluate vulnerabilities against the release gate
`wardex assess`	Compliance gap analysis
`wardex convert grype/sbom`	Convert scanner output to Wardex format
`wardex enrich epss`	Enrich vulnerabilities with EPSS data
`wardex accept request/verify/list`	Risk acceptance management
`wardex art14 list/show/verify`	CRA Article 14 artefact lifecycle
`wardex provenance seal/submit/verify/status`	Cryptographic provenance anchoring with Gleipnir
`wardex config hash/seal`	CPL and sealed config
`wardex audit verify-chain/verify-link`	Chained audit log verification
`wardex trust init/add`	Trust store management
`wardex keygen`	Ed25519 keypair generation
`wardex pki init/issue`	PKI mode with Ed25519 CA
`wardex policy show`	Show configured risk policy
`wardex simulate`	Simulate gate decisions with historical data

Risk-Based Release Gate

Configuration

# wardex-config.yaml
release_gate:
  enabled: true
  risk_appetite: 0.20
  warn_above: 0.12
  mode: any               # "any" blocks if any vuln exceeds threshold; "aggregate" uses sum
  asset_context:
    criticality: 0.8
    internet_facing: true
    requires_auth: true
  compensating_controls:
    - type: waf
      effectiveness: 0.35

The same CVE, four contexts

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`

EPSS enrichment

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

CI/CD integration

# .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

Compliance Gap Analysis

Wardex compares what infosec has declared against what is operationally active, and identifies the delta against the framework.

Category	Meaning
Covered	Present in `implemented` layer, maturity >= 3, with operational evidence.
Policy without practice	Documented only. No corresponding implemented control.
Practice without governance	Implemented but without a documented policy.
Gap	Absent from both layers for a catalogue control.

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

# With asset inventory
wardex assess documented-controls.yaml implemented-controls.yaml \
  --assets assets.yaml \
  --framework iso27001 \
  -o json --out-file posture.json

CRA Article 14

The EU Cyber Resilience Act's active exploitation notification obligations enter into force in September 2026.

Active Exploitation Hard Stop: When a vulnerability is classified as actively exploited (actively_exploited: true), wardex evaluate exits with code 12 — distinct from the normal gate block (10). It cannot be overridden by risk acceptances.

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

# Active exploit acceptance
wardex accept active-exploit --cve CVE-2024-3094 --justification "..." --art14-artefact wardex-art14-....json

See the Governance Playbook for the full workflow.

EU AI Act (Artificial Intelligence Regulation)

Regulation (EU) 2024/1689 — the EU AI Act — is available as a controls framework in Wardex v2.4.0. 31 catalogued controls covering all obligations applicable to high-risk AI systems, general-purpose AI models (GPAI), and prohibited practices.

Controls by domain

Domain	Controls	Articles
Prohibited practices	1	Art 5
Governance & classification	4	Arts 6, 21, 49, 99
Risk management	1	Art 9
Data governance	1	Art 10
Documentation & records	4	Arts 11, 12, 18, 19
Transparency	2	Arts 13, 50
Human oversight	1	Art 14
Technical (accuracy, robustness, security)	2	Arts 15, 19
Provider obligations	2	Arts 16, 20
Quality management	1	Art 17
Deployer obligations	2	Arts 26, 27
Value chain (importer, distributor, rep)	4	Arts 22, 23, 24, 25
Conformity assessment	2	Arts 43, 47
GPAI (general-purpose AI)	2	Arts 53, 55
Post-market & incident reporting	2	Arts 72, 73

# Assess compliance with EU AI Act
wardex --framework eu_ai_act ./frameworks/eu_ai_act/*.yml

# List catalogue controls
wardex --framework eu_ai_act --output json ./frameworks/eu_ai_act/*.yml

Provenance with Gleipnir

Each release can be cryptographically sealed with the Gleipnir embedded consensus engine:

# Seal release artifacts
wardex provenance seal \
  --dir ./dist \
  --output chain-seal.json \
  --label "wardex-v2.4.0-eu-ai-act"

# Anchor a tag commit
wardex provenance submit $(git rev-parse v2.4.0) --label "git-tag-v2.4.0"

# Check chain status
wardex provenance status

Key Management & Governance

Cryptographic Keys

All Ed25519 keys are stored in ~/.crypto/ with subdirectories by purpose:

~/.crypto/
├── provenance/          # Provenance manifest signing
│   ├── signing.key      # Ed25519 private (mode 0400)
│   └── signing.key.pub  # Ed25519 public
└── trust/               # Wardex trust system
    └── root.key         # Root key (generated by wardex keygen)

Permissions: Directories 700, private keys 0400, public keys 0644.

Provenance Verification

For recent releases (v2.4.0+), use the embedded Gleipnir engine:

# Verify a release chain seal
wardex provenance verify <chain-hash>

# Check chain status
wardex provenance status

For earlier releases (v2.2.2), the public key below verifies the provenance manifest:

Signing public key (v2.2.2):
ed25519:HsD9e6BB2LlaeKODGqgWUZoflDgdUH1HWTdyWA7dGqE=

Root hash (BLAKE3, 113 files):

sha256:6f972edf99f5457f8fb13668c529f4343dab7a76d20b67ea746ebdf54d910fee

# Download the signed manifest from the release
gh release download v2.2.2 --pattern "provenance-manifest*"

# Verify (requires immutable-provenance binary from v2.3.0 branch)
immutable-provenance verify \
  --manifest provenance-manifest-v2.2.2-signed.yaml \
  --dir /path/to/wardex-v2.2.2

Trust Store & Sealed Config (WexState)

For DORA compliance and non-repudiable chains of custody:

Strong identity: Ed25519 keys for Admins, CISOs, and Analysts.
Sealed config: Risk policies cannot be altered without executive approval.
Append-only trust store: Central record of authorised keys and revocations.

# Seal the policy (CISO action)
wardex config seal --keyring ~/.crypto/trust/root.key --input config.yaml --out config.wexstate

# Evaluate with mandatory seal verification
wardex evaluate --config config.wexstate --evidence vulns.yaml --strict

PKI Mode

For environments that require certificate-based identity:

wardex pki init --org "Your Corp" --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

Variable	Default	Description
`WARDEX_ACCEPT_SECRET`	—	HMAC-SHA256 key for signing acceptances and Art14 artefacts (min 32 chars)
`WARDEX_ACTOR`	`cli`	Identity string recorded in audit entries
`WARDEX_SYSLOG_ENDPOINT`	—	`tcp://syslog.example.com:514` — forward audit events to central syslog
`WARDEX_SYSLOG_PROTO`	`tcp`	Syslog transport: `tcp`, `udp`, or `tls`
`WARDEX_SYSLOG_CERT`	—	TLS client cert path for `tls` proto
`WARDEX_SYSLOG_KEY`	—	TLS client key path for `tls` proto
`WARDEX_SYSLOG_CA`	—	Custom CA cert path for `tls` proto

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)

For the 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

Documentation

Licensing

Dual-licensed:

AGPL-3.0 (free): use in internal CI/CD pipelines or in open-source projects that make their source available.

Commercial licence (paid): embedding in proprietary products, SaaS platforms, or distribution without opening source. See the Commercial Terms or contact andre_ataide@proton.me.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

Chained Audit Log — Core Feature

What's New — v2.4.0

Supported frameworks

Installation

Docker

Helm (Kubernetes)

Quickstart

1. Evaluate vulnerability risk

2. Generate and manage keys

3. Seal and verify provenance

Command Reference

Risk-Based Release Gate

Configuration

The same CVE, four contexts

EPSS enrichment

CI/CD integration

Compliance Gap Analysis

CRA Article 14

EU AI Act (Artificial Intelligence Regulation)

Controls by domain

Provenance with Gleipnir

Key Management & Governance

Cryptographic Keys

Provenance Verification

Trust Store & Sealed Config (WexState)

PKI Mode

Environment & Syslog

SDK

Documentation

Licensing

FilesExpand file tree

README-en.md

Latest commit

History

README-en.md

File metadata and controls

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

Chained Audit Log — Core Feature

What's New — v2.4.0

Supported frameworks

Installation

Docker

Helm (Kubernetes)

Quickstart

1. Evaluate vulnerability risk

2. Generate and manage keys

3. Seal and verify provenance

Command Reference

Risk-Based Release Gate

Configuration

The same CVE, four contexts

EPSS enrichment

CI/CD integration

Compliance Gap Analysis

CRA Article 14

EU AI Act (Artificial Intelligence Regulation)

Controls by domain

Provenance with Gleipnir

Key Management & Governance

Cryptographic Keys

Provenance Verification

Trust Store & Sealed Config (WexState)

PKI Mode

Environment & Syslog

SDK

Documentation

Licensing