Compliance Reporting

Gadriel Code maps its findings onto recognized security and AI-governance frameworks and produces per-framework compliance reports. The reports state, for each control, whether the evidence gathered from your source code supports a PASS, a PARTIAL, a FAIL, or whether the control simply cannot be judged from source and needs manual review.

This page documents the supported frameworks, how to generate reports, how findings map to controls, what each control state means, and — importantly — how coverage honestly varies from framework to framework.

Related pages: Reports & outputs · SBOM · Troubleshooting.

Supported frameworks

Ten frameworks are supported. Use the slug in the --compliance flag.

Several common aliases are accepted (e.g. nist, soc-2, pci, owasp-llm, iso42001, cmmc, cyber-insurance), but the slugs above are canonical.

Generating reports

bashCOPY
# One framework
gadriel code report --compliance soc2

# Several frameworks
gadriel code report --compliance soc2,pci-dss,hipaa

# All ten
gadriel code report --compliance all

# Choose output formats
gadriel code report --compliance all --format pdf,markdown,html

The command reads .security/findings.json, so run a scan first.

Output location

Per-framework files are written into .security/compliance/, one set per framework, named by slug:

For example, gadriel code report --compliance all --format all writes ten sets of {.md, .typ, .pdf}. The same command run also refreshes the HTML bundle in .security/reports/ (including the compliance view) and appends a row to the compliance-history.rvf store. See Reports & outputs.

Exit codes

When --fail-on verdict (the default), the report command exits:

--fail-on render-only collapses 1 and 2 to 0 (only true render failures fail). See the exit-code reference.

How findings map to controls

Each rule in the Gadriel Vulnerability Library (GVL) carries a compliance_mapping — a set of framework keys, each naming the control that rule provides evidence for. The available keys are:

owasp_llm, owasp_web, cwe, eu_ai_act, nist_ai_rmf, iso_42001, soc2, pci_dss, hipaa.

Each key holds a single control id, for example:

yamlCOPY
compliance_mapping:
  eu_ai_act: Article_9
  nist_ai_rmf: GOVERN-1.1
  soc2: CC6.1
  cwe: CWE-20

A finding produced by that rule inherits the mapping, and the aggregator ties it to the corresponding control in three tiers (first non-empty tier wins per control):

1. Direct — the finding carries an explicit compliance_mapping entry for that framework's control.
2. Pattern match — the control declares rule_id_patterns that match the finding's id. (This tier feeds the evidence table shown in the report but does not currently drive the verdict.)
3. Pillar fallback — the finding's pillar overlaps the control's declared pillars (only when the control opts in).

What a control's state means

A single control is evaluated as follows:

1. If the control is manual_only, it short-circuits to NOT ASSESSABLE before any predicate runs, and carries the control's own narrative as its note.
2. Otherwise predicates are evaluated with strict precedence — fail_when > partial_when > pass_when, first match wins.
3. If nothing matches, the control defaults to PARTIAL with the reason "evidence not collected".

Framework rollup. A framework's overall verdict is PASS / PARTIAL / FAIL: any FAIL makes the framework FAIL; else any PARTIAL makes it PARTIAL; else PASS. NOT ASSESSABLE controls are neutral — they are excluded from the rollup and never counted as a deficiency. A framework whose only non-PASS controls are manual-only will roll up to PASS.

Coverage varies by framework — read this

Automated coverage is genuinely uneven across frameworks. Some frameworks are almost fully automatable from source; others are mostly or entirely manual-assessment. The table below reflects how many controls each framework defines and how many are manual_only (i.e. NOT ASSESSABLE by design).

Additional honesty notes:

• SOC 2 / HIPAA / PCI-DSS corpus annotation is still thin. The framework keys exist and the vacuous-PASS bug that once let these frameworks pass controls without evidence has been fixed — so unevidenced controls now correctly show as "not yet evidenced" (PARTIAL) rather than silently PASS. However, direct rule-to-control annotation for these three is still largely pending, so many of their controls report PARTIAL until the corpus catches up.
• ISO/IEC 42001 is all-manual in v1. Existing iso_42001 data in the corpus is largely mislabeled ISO 27001 content and is deliberately not used to drive verdicts.
• OWASP Agentic and ISO 42001 emit zero automated verdicts today — every control is manual review.
• CMMC Level 1 (~8/17 predicated) and Cyber Insurance Readiness (2/12 predicated) are mostly manual.

The practical takeaway: a PASS is meaningful evidence, a FAIL is a real deficiency, PARTIAL means "not yet evidenced from source," and NOT ASSESSABLE means "bring a human." Always read a framework's report alongside the coverage figures above rather than treating an overall PASS as a certification.