Compliance Scanning

ChainLaunch Pro ships a built-in compliance scanner that audits each network against a curated set of best-practice checks for Hyperledger Fabric and Hyperledger Besu. Run it on demand or on a schedule to surface configuration drift, expiring certificates, missing backups, and consensus risk before they cause an incident.

What gets checked

The scanner derives a per-network health status (HEALTHY, DEGRADED, AT_RISK, or CRITICAL) from individual check results. Every check returns one of PASSED, WARNING, or FAILED plus a remediation hint.

Fabric checks

Besu checks

Each check is a pure function over NetworkInfo (network + nodes + backup-schedule presence). New checks are added by ChainLaunch upgrades; you don't need migrations.

Permissions

All compliance endpoints require system:monitor permission, available to ADMIN, OPERATOR, and VIEWER roles by default. See RBAC & Permissions.

Run a scan

Per network

chainlaunch compliance scan 5

Truncated response:

{
  "networkId": 5,
  "networkName": "supply-chain-mainnet",
  "platform": "FABRIC",
  "status": "DEGRADED",
  "summary": { "total": 7, "passed": 5, "failed": 1, "warning": 1 },
  "checks": [
    {
      "name": "Orderer Quorum",
      "category": "Consensus",
      "status": "PASSED",
      "message": "5 orderers — tolerates up to 2 failures."
    },
    {
      "name": "Cert Expiry",
      "category": "Cryptography",
      "status": "WARNING",
      "message": "1 certificate expires within 90 days",
      "details": { "expiring": [
        { "node": "peer0-org2", "type": "TLS", "expiresIn": "63d" }
      ] },
      "remediation": "Renew before expiry; see /vault-integration or the cert-renewal runbook."
    },
    {
      "name": "Backup Compliance",
      "category": "DR",
      "status": "FAILED",
      "message": "No backup schedule covers this network",
      "remediation": "Configure a daily schedule under /backups for the org's nodes."
    }
  ],
  "scannedAt": "2026-05-06T08:14:23Z"
}

Whole organization

chainlaunch compliance summary

Returns one OrgWideScanResult with per-network breakdown plus an aggregated summary. Use this for the executive dashboard or a daily Slack post.

Scan history

Every scan is persisted, so you can prove "we scanned every Wednesday" to an auditor:

# Recent scans across all networks
curl -s "https://chainlaunch.example.com/api/v1/compliance/scans?limit=50" | jq
 
# Per-network history
curl -s "https://chainlaunch.example.com/api/v1/networks/5/compliance/history?limit=20" | jq

Endpoint reference

All endpoints support ?limit= and ?offset= for pagination on listing endpoints.

Status semantics

OverallStatus is derived from the worst check:

Use these in dashboards and alert routing — CRITICAL should page, AT_RISK ticket, DEGRADED email.

Automating scans

The scanner is just an HTTP endpoint, so any scheduler works. Two patterns:

Cron + Slack

#!/usr/bin/env bash
# /etc/cron.daily/chainlaunch-compliance
RESULT=$(chainlaunch compliance summary --output json)
 
STATUS=$(echo "$RESULT" | jq -r .status)
FAILED=$(echo "$RESULT" | jq '.summary.failed')
 
if [[ "$STATUS" != "HEALTHY" ]]; then
  curl -X POST "$SLACK_WEBHOOK" -H 'Content-Type: application/json' \
    -d "{\"text\":\"⚠️ ChainLaunch compliance: $STATUS — $FAILED failed checks\"}"
fi

Webhook subscription

If you've configured Webhooks, every scan emits a compliance.scan.completed event with the full result. No polling needed.

Terraform

The Terraform provider exposes compliance results as a data source. See chainlaunch-terraform.

data "chainlaunch_compliance_scan" "supply_chain" {
  network_id = chainlaunch_fabric_network.supply_chain.id
}
 
# Fail terraform plan if status is critical
resource "null_resource" "compliance_gate" {
  triggers = {
    status = data.chainlaunch_compliance_scan.supply_chain.status
  }
  lifecycle {
    precondition {
      condition     = data.chainlaunch_compliance_scan.supply_chain.status != "CRITICAL"
      error_message = "Compliance scan critical — refusing to apply."
    }
  }
}

Common findings & fixes

Limits & gotchas

• The scanner does not verify on-chain state — it inspects ChainLaunch's view of nodes, certs, and policies.
• Cert expiry checks read the PEM stored in ChainLaunch. If you renewed the cert directly on disk without updating ChainLaunch, the scanner will lie.
• Backup Compliance only verifies a schedule exists — it doesn't verify that the most recent backup actually succeeded. For that, watch the backup.failure event in Webhooks or Notifications.
• Org diversity check uses MSP IDs as the org identifier. Multiple peers under the same MSP count as one org.

Next steps

• Audit Logging — every compliance scan and config change is logged.
• Backups — schedule the backups the scanner expects to find.
• Webhooks — subscribe to compliance.scan.completed events.
• Configure Monitoring — pair compliance with ongoing health metrics.