Skip to content

Compliance Framework Mapping

Shipped in v3.2.0 and extended with ORC 9.64 readiness in v4.1.0, the compliance mapping feature maps vulnerability findings to industry compliance frameworks, supporting audit readiness and remediation prioritization.

The mapper (scripts/compliance_mapper.sh) is gated behind the compliance license permission (business tier or higher). Without a business-or-higher license the whole step is skipped with a soft warning, and core scanning is never blocked. See License Provisioning.

Supported Frameworks

FrameworkJSON codeControls TrackedDescription
CIS Controls v8CIS20Center for Internet Security critical security controls
NIST CSFNIST22NIST Cybersecurity Framework core functions and categories
PCI-DSS v4.0PCI12Payment Card Industry Data Security Standard requirements
SOC 2SOC9Service Organization Control trust services criteria
ORC 9.64ORC5Ohio Revised Code political-subdivision cybersecurity program (opt-in, see below)

The stored .compliance[].framework value is the short code (CIS, NIST, PCI, SOC, ORC); the report and portal render that code directly. The "Controls Tracked" column is the total control count used for gap analysis (_CM_*_TOTAL constants in the script). ORC counts only the five technical divisions.

How It Works

The compliance mapper processes session findings through a three-step pipeline.

1. Finding-to-Control Mapping

Each finding's title and category are matched against curated lookup tables that map vulnerability patterns to compliance controls. For example, a "Weak SSL/TLS" finding maps to:

  • CIS 3.10 (Encrypt Sensitive Data in Transit)
  • NIST PR.DS-2 (Data-in-transit is protected)
  • PCI 4.2.1 (Strong cryptography for transmission)
  • SOC CC6.7 (Restrict transmission, movement, and removal)
  • ORC 9.64(C)(1) (Identify critical functions and cybersecurity risks)

The lookup tables cover common vulnerability categories including:

  • Encryption and TLS weaknesses (weak SSL/TLS, POODLE, RC4, self-signed certificates)
  • Cleartext protocols (Telnet, FTP, unencrypted services)
  • Authentication and credential issues (default or weak credentials, brute force)
  • SMB and service exposure (SMBv1, MS17-010, SNMP, unnecessary services)
  • Software vulnerabilities and patching (missing patches, EOL software, CVEs, Heartbleed)
  • Web application issues (HTTP methods, CORS, injection, XSS)
  • Access control and network segmentation (RDP, VNC, firewall, ACLs)
  • Email security (SPF, DKIM, DMARC), DNS zone transfers, and information disclosure

2. Deduplication

Mappings are deduplicated per control so that multiple findings mapping to the same control are consolidated. Each control entry lists all associated finding IDs (finding_ids, uniqued).

3. Gap Analysis

For each framework, the mapper compares mapped controls against the total control set to identify gaps, that is, controls that were checked but had no associated findings. This helps highlight where scan scope may need expansion or where the organization already has adequate coverage.

Output Format

The mapper produces two outputs in the session JSON (and, when enabled, a third .orc_964 readiness block).

.compliance[] Array

Each entry represents a deduplicated finding-to-control mapping:

json
{
  "framework": "CIS",
  "control_id": "3.10",
  "control_name": "Encrypt Sensitive Data in Transit",
  "finding_ids": ["finding_001", "finding_003"]
}

.summary.compliance_summary

Aggregate statistics per framework, including gap analysis:

json
{
  "total_mappings": 42,
  "by_framework": [
    {
      "framework": "CIS",
      "mapped_controls": 8,
      "total_controls": 20,
      "gap_controls": 12,
      "controls": ["3.10", "4.8", "5.2", "7.4"],
      "findings_count": 15
    }
  ]
}

ORC 9.64 Readiness (Ohio Political Subdivisions)

Ohio Revised Code 9.64 requires every Ohio political subdivision (counties, cities, townships, school districts, and other subdivisions) to adopt a cybersecurity program. NetVuln Tool maps scan findings to the five technical divisions of ORC 9.64(C) and records the policy and attestation items a scanner cannot observe, producing an at-a-glance readiness view for compliance deadlines.

Activation

ORC 9.64 mapping is opt-in and requires the compliance permission (business tier or higher). Enable it either way:

bash
# report_config.conf
ORC_964_ENABLED="true"
# or, equivalently, tag the engagement as a political subdivision:
CLIENT_TYPE="political_subdivision"

When ORC is not active, the mapper strips all ORC rows from .compliance and omits .orc_964 entirely, so non-Ohio clients never see ORC data.

Deadlines and Subdivision Class

Subdivision classORC_SUBDIVISION_CLASSAdoption deadline
Counties and citiescounty_city2026-01-01
All other subdivisions (default)other2026-07-01

Technical Divisions

Gap analysis for ORC counts only the five technical divisions (_CM_ORC_TOTAL = 5), so a subdivision is never penalized for the policy items a network scan cannot see.

DivisionRequirement
9.64(C)(1)Identify critical functions and cybersecurity risks
9.64(C)(2)Identify potential breach impacts
9.64(C)(3)Mechanisms to detect cybersecurity threats and events
9.64(C)(4)Incident analysis, communication, and containment procedures
9.64(C)(5)Post-incident infrastructure repair and recovery

Attestation Items

Four items cannot be observed by a scanner and are recorded from config as true, false, or unknown (default unknown):

ItemRequirementConfig variable
9.64(C)(6)Annual employee cybersecurity training scaled to dutiesORC_ATTEST_TRAINING
9.64(D)(1)Notify Ohio Homeland Security (Cyber Integration Center) within 7 days of discoveryORC_ATTEST_NOTIFY_HLS
9.64(D)(2)Notify the Auditor of State within 30 days of discoveryORC_ATTEST_NOTIFY_AUDITOR
9.64(B)Ransomware payment authorized only by legislative resolution or ordinanceORC_ATTEST_RANSOM_POLICY

TIP

The training item (9.64(C)(6)) carries a guidance note: Ohio Cyber Range Institute or state-provided training satisfies the requirement.

.orc_964 Block

When active, build_orc_964() writes a readiness object to the session JSON:

json
{
  "orc_964": {
    "enabled": true,
    "deadlines": { "county_city": "2026-01-01", "other": "2026-07-01", "applicable": "other" },
    "divisions": [
      {
        "id": "9.64(C)(1)",
        "name": "Identify critical functions and cybersecurity risks",
        "type": "technical",
        "mapped": true,
        "finding_ids": ["finding_002"],
        "finding_count": 1
      }
    ],
    "attestations": [
      { "id": "9.64(C)(6)", "name": "Annual employee cybersecurity training scaled to duties", "state": "unknown", "note": "Ohio Cyber Range Institute or state-provided training satisfies this requirement." },
      { "id": "9.64(D)(1)", "name": "Incident notification to Ohio Homeland Security (Cyber Integration Center) within 7 days of discovery", "state": "unknown" },
      { "id": "9.64(D)(2)", "name": "Incident notification to Auditor of State within 30 days of discovery", "state": "unknown" },
      { "id": "9.64(B)", "name": "Ransomware payment authorized only by legislative resolution or ordinance", "state": "unknown" }
    ],
    "coverage": { "technical_divisions_total": 5, "technical_divisions_covered": 3 }
  }
}

The portal (bullium-site v1.24.0+) extracts an orc964_summary (enabled, technical_covered, technical_total, attest_pending) for the ORC readiness panel. See the API Contract for the full field reference.

Report Integration

The HTML report includes a Compliance tab with:

  • Framework summary cards showing mapped vs total controls, gap count, and findings count per framework
  • Filter buttons to view mappings for a specific framework or all frameworks
  • Full mapping table with framework code, control ID, control name, and linked finding IDs

Compliance data is also exposed as template variables in the executive summary engine (lib/exec_template.sh), enabling compliance summaries in automated executive reports.

Portal Integration

The collection portal (bullium-site v1.11.0+, ORC panel in v1.24.0+) displays a compliance panel for sessions that include compliance data:

  • Framework cards with control coverage percentages
  • Filter buttons for per-framework views
  • A mapping table with sortable columns
  • CSV export of compliance mappings
  • An ORC 9.64 readiness panel when orc964_summary is present

CLI Usage

The compliance mapper runs automatically during the scan pipeline (Reporting phase). It can also be run standalone:

bash
source scripts/compliance_mapper.sh
map_compliance "/path/to/session_results.json"

Standalone runs still honor the business-tier gate and the ORC opt-in environment variables.

Testing

The compliance mapper has 49 BATS tests covering pattern matching for every supported category, multi-framework mapping accuracy, deduplication, gap analysis, summary statistics, ORC 9.64 activation and readiness math, and edge cases (empty findings, unknown categories, unlicensed downgrade):

bash
bats tests/test_compliance_mapper.bats

Source Files

FilePurpose
scripts/compliance_mapper.shCompliance framework mapper with lookup tables, gap analysis, and the ORC 9.64 readiness block
scripts/report_template.shCompliance tab rendering in HTML reports
lib/exec_template.shCompliance template variables for executive summaries
lib/license.shTier gate (nv_require_tier compliance)
tests/test_compliance_mapper.batsBATS test suite (49 tests)

Apache-2.0 licensed (appliance subtree proprietary)