CIS Benchmark Licensing Restriction#

Lead Section#

The CIS Benchmark Licensing Restriction is a critical project policy in the opnDossier firewall configuration auditing tool that prohibits the use, reference, or derivation of content from CIS (Center for Internet Security) Benchmarks. This policy was formally implemented in PR #274 (February 21, 2026), which systematically removed all existing CIS references from the codebase, documentation, and compliance frameworks.

The restriction stems from CIS Benchmarks' use of the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 (CC BY-NC-SA 4.0) license, which imposes commercial use restrictions and share-alike requirements incompatible with the project's goals for freely distributable, commercially usable security audit tooling. The policy explicitly directs developers and contributors to use approved alternatives: STIG (Security Technical Implementation Guide), NIST (National Institute of Standards and Technology), SANS security guidelines, and independently developed FIREWALL-NNN controls — all of which are public domain or carry no restrictive licensing terms.

This policy applies comprehensively across all project artifacts, including source code, code comments, documentation files, compliance plugin descriptions, audit report output, and project specifications. Enforcement mechanisms include code review checks, automated verification (grep searches for CIS references), and explicit disclaimers in compliance documentation stating that controls are "not affiliated with, endorsed by, or derived from any third-party benchmark organization."

Background and Rationale#

Initial CIS Implementation#

Between August 2025 and February 2026, opnDossier contained references to CIS Benchmarks in its compliance checking framework. These references included:

• Compliance framework metadata arrays containing "CIS" alongside other standards like NIST
• Test fixtures using CIS control identifiers like "CIS-1.1"
• A documentation file named cis-like-firewall-reference.md describing firewall security controls
• Code comments referencing "CIS" as an example compliance framework

The initial implementation appears to have been part of the project's plugin-based compliance framework architecture established in PR #28, which introduced modular compliance checking capabilities for security auditing.

Discovery of Licensing Conflict#

The project maintainers identified that CIS Benchmarks are distributed under the CC BY-NC-SA 4.0 license, which creates three specific legal conflicts:

1. NonCommercial Restriction: The license prohibits commercial use without explicit permission from CIS, creating barriers for organizations using opnDossier in commercial environments or selling security services based on the tool
2. ShareAlike Requirement: Any derivative works must be distributed under the same CC BY-NC-SA 4.0 license, potentially forcing opnDossier to adopt incompatible licensing terms
3. Attribution Requirements: Even indirect derivations require attribution and acknowledgment, creating administrative burden and potential trademark issues

These restrictions conflict with opnDossier's design as a freely usable, offline-capable security tool that can be deployed in any environment without licensing constraints.

The Removal Decision (PR #274)#

On February 21, 2026, PR #274 ("refactor: harden multi-device model, fix bugs, and remove CIS trademark references") systematically removed all CIS content from the project. The PR summary explicitly stated:

CIS trademark removal: Removed all references to CIS/Center for Internet Security to avoid CC BY-NC-SA 4.0 licensing exposure — renamed docs, updated compliance framework references to use independently developed FIREWALL-NNN controls, STIG, SANS, and NIST (all public domain or freely usable)

The decision prioritized licensing clarity and commercial usability over framework recognition, ensuring the project maintains full legal freedom for all users.

Scope of Restriction#

Prohibited Activities#

The CIS Benchmark restriction prohibits the following activities within the opnDossier project:

1. Direct Content Use: Copying control descriptions, test procedures, or remediation guidance from CIS Benchmark documents
2. Control ID References: Using CIS control identifiers (e.g., "CIS-1.1", "CIS Benchmark 5.2.3") in code, comments, or documentation
3. Derived Works: Creating compliance checks based on CIS Benchmark methodologies, even if reworded
4. Marketing Claims: Stating that opnDossier "supports CIS compliance" or "implements CIS controls" in any project materials
5. Trademark Usage: Referencing "CIS Benchmarks" or "Center for Internet Security" in ways that imply endorsement or affiliation
6. Documentation References: Linking to or recommending CIS Benchmark documents as authoritative sources for compliance

Permitted Activities#

The policy allows the following:

1. Factual Statements: Objective statements about CIS Benchmarks' existence and licensing restrictions in policy documentation (like this article)
2. Comparison Discussions: Comparing opnDossier's approach to CIS Benchmarks in architectural or design contexts, without copying content
3. User Questions: Responding to user inquiries about CIS support by redirecting to approved alternatives

Approved Alternatives#

The policy directs contributors to use the following compliance frameworks instead of CIS Benchmarks:

STIG (Security Technical Implementation Guide)#

Licensing Status: Public domain (US Government works)

Implementation: 4 controls implemented covering firewall security requirements from DISA (Defense Information Systems Agency):

• V-206694: Firewall must deny network communications traffic by default
• V-206674: Firewall must implement rate limiting for traffic
• V-206690: Firewall must block/restrict inbound traffic
• V-206682: Network devices must implement encryption for sensitive data

Source: DISA STIG Firewall Security Requirements Guide

NIST (National Institute of Standards and Technology)#

Licensing Status: Public domain (US federal government publications)

Implementation: Referenced in compliance frameworks array; used for foundational security principles

Source: NIST Cybersecurity Framework and Special Publications (SP 800 series)

SANS Security Guidelines#

Licensing Status: Freely usable

Implementation: 4 controls defined based on SANS Firewall Checklist (FW-001 through FW-004)

Source: SANS Institute firewall security guidelines

FIREWALL-NNN Controls (Independently Developed)#

Licensing Status: Original work by EvilBit Labs

Implementation: 8 controls implemented covering:

• FIREWALL-001: SSH security banner configuration
• FIREWALL-002: Configuration backup settings
• FIREWALL-003: Hostname configuration
• FIREWALL-004: DNS configuration validation
• FIREWALL-005: IPv6 settings
• FIREWALL-006: HTTPS web interface management
• FIREWALL-007: Additional firewall controls
• FIREWALL-008: Additional firewall controls

Documentation: Firewall Security Controls Reference with explicit disclaimer: "These controls are independently developed by EvilBit Labs based on general cybersecurity best practices for network firewalls and are designed for OPNsense configurations. They are not affiliated with, endorsed by, or derived from any third-party benchmark organization."

Implementation Details#

Code Changes in PR #274#

The CIS removal involved modifications across 17 files:

Compliance Framework Array Update#

File: internal/audit/mode_controller.go

Before:

r.Metadata["compliance_frameworks"] = []string{"CIS", "NIST"}

After:

r.Metadata["compliance_frameworks"] = []string{"STIG", "NIST", "SANS"}

This change updated the blue team audit mode's compliance framework metadata to exclude CIS and include the approved alternatives.

Test Fixture Updates#

File: internal/audit/mode_controller_test.go

Before:

Control: "CIS-1.1",

if finding.Control != "CIS-1.1" {
    t.Errorf("Finding.Control = %v, want %v", finding.Control, "CIS-1.1")
}

After:

Control: "STIG-V-206694",

if finding.Control != "STIG-V-206694" {
    t.Errorf("Finding.Control = %v, want %v", finding.Control, "STIG-V-206694")
}

Test cases were updated to use STIG control identifiers instead of CIS references.

Documentation File Rename#

Renamed: docs/cis-like-firewall-reference.md → docs/firewall-security-controls-reference.md

Content Changes:

• Title changed from "CIS-Inspired Firewall Security Controls Reference" to "Firewall Security Controls Reference"
• Added disclaimer: "These controls are independently developed by EvilBit Labs...not affiliated with...any third-party benchmark organization"
• Default hostname corrected from "pfSense" to "OPNsense"

Code Comment Updates#

Multiple files had comment updates:

• internal/processor/example.go: "Security framework compliance (CIS, NIST, etc.)" → "Security framework compliance (STIG, NIST, SANS, etc.)"
• project_spec/tasks.md: "STIG, SANS, CIS compliance checking" → "STIG, SANS, firewall best practice compliance checking"
• project_spec/ROADMAP_V2.0.md: "Modular compliance plugins (STIG, SANS, CIS, etc.)" → "Modular compliance plugins (STIG, SANS, Firewall, etc.)"
• .coderabbit.yaml: Updated code review guidelines from "STIG, CIS, etc." to "STIG, SANS, NIST, etc."

Verification Process#

The PR included a test plan requiring verification that zero \bCIS\b matches exist across:

• .go source files
• .md documentation files
• .yml and .yaml configuration files

Subsequent grep searches confirm no CIS references remain in the current codebase, with only false positive matches from words like "exercise," "precise," and "decision."

Enforcement Mechanisms#

Code Review Process#

The project's code review configuration (.coderabbit.yaml) includes explicit instructions for reviewers to check compliance framework references and ensure they use approved standards (STIG, SANS, NIST).

Contributor Guidelines#

The CONTRIBUTING.md document provides guidance for:

• Bug reports and feature requests: Use GitHub Issues with appropriate templates
• Compliance additions: Require maintainer approval; discussions in GitHub issues before implementation
• Architecture changes: Must include documented rationale with maintainer approval

When contributors suggest adding CIS content, maintainers redirect to approved alternatives (STIG, SANS, NIST, FIREWALL-NNN controls).

Automated Verification#

The project test plan includes verification steps to ensure no CIS references exist using regex pattern matching (\bCIS\b). This can be integrated into CI/CD pipelines to prevent regression.

Documentation Disclaimers#

All compliance-related documentation includes explicit disclaimers. The Firewall Security Controls Reference states:

These controls are independently developed by EvilBit Labs based on general cybersecurity best practices for network firewalls and are designed for OPNsense configurations. They are not affiliated with, endorsed by, or derived from any third-party benchmark organization.

This disclaimer protects against claims of CIS derivation or affiliation.

Compliance Plugin Architecture#

The restriction operates within opnDossier's plugin-based compliance architecture, which allows modular compliance framework support while maintaining licensing clarity.

Plugin Interface#

All compliance plugins implement the compliance.Plugin interface with standardized methods:

• RunChecks(): Execute compliance checks against firewall configuration
• GetFindings(): Return structured compliance findings
• Metadata(): Provide plugin metadata including framework name and version

Built-in Plugins#

The project includes three built-in compliance plugins that comply with the CIS restriction:

1. STIG Plugin (internal/plugins/stig/)
2. SANS Plugin (internal/plugins/sans/)
3. Firewall Plugin (internal/plugins/firewall/)

Plugin Registry#

Plugins are registered in a thread-safe registry using sync.RWMutex, allowing dynamic loading of external compliance frameworks via Go plugins (.so files).

Finding Structure#

Compliance findings use a standardized structure that includes:

• Control ID (e.g., "STIG-V-206694", "FIREWALL-001")
• Title and description
• Severity level
• Recommendations
• Component references
• Tags for categorization

This architecture prevents CIS control IDs from appearing anywhere in the compliance reporting chain.

Impact and Considerations#

Benefits of the Restriction#

1. Legal Clarity: Eliminates potential licensing disputes or commercial use restrictions for opnDossier users
2. Distribution Freedom: Allows unrestricted redistribution, modification, and commercial use of the tool
3. Independence: Establishes opnDossier as an independently developed tool not subject to third-party licensing terms
4. Public Domain Focus: Prioritizes compliance frameworks that maximize accessibility and reuse

Limitations#

1. Brand Recognition: CIS Benchmarks are widely recognized in the security industry; their absence may reduce immediate recognition
2. Coverage Gaps: Some CIS-specific controls may not have direct equivalents in STIG/SANS/FIREWALL frameworks
3. User Expectations: Organizations specifically seeking CIS compliance validation must use alternative tools or map controls manually

Handling User Requests#

When users request CIS Benchmark support, the project's response pattern (documented in contributor guidelines) includes:

1. Acknowledge the request: Recognize CIS Benchmarks' industry prominence
2. Explain the licensing restriction: Reference CC BY-NC-SA 4.0 concerns
3. Redirect to alternatives: Provide specific STIG, SANS, NIST, or FIREWALL control mappings
4. Document the conversation: Link to this policy documentation for future reference

Example response template:

"Thank you for your interest in CIS Benchmark support. opnDossier cannot include CIS content due to the CC BY-NC-SA 4.0 licensing restrictions that conflict with our commitment to freely usable, commercially unrestricted tooling. We recommend using our STIG, SANS, NIST, or independently developed FIREWALL-NNN controls, which cover similar security objectives. See CIS Benchmark Licensing Restriction for details."

Related Topics#

• Compliance Framework Selection: Criteria for evaluating and integrating security compliance standards in open source projects
• Software Licensing in Security Tools: Implications of restrictive licenses (CC BY-NC-SA, GPL, proprietary) on security tool adoption
• STIG Compliance Checking: Implementation details of DISA STIG controls in firewall auditing
• Plugin Architecture Patterns: Design patterns for extensible compliance checking systems
• Public Domain Security Standards: Government and freely available security frameworks suitable for unrestricted tool integration

Future Considerations#

While the current policy maintains a strict prohibition on CIS content, potential future scenarios include:

1. CIS Licensing Changes: If CIS Benchmarks adopt a more permissive license (e.g., CC BY 4.0 or public domain), the restriction could be reconsidered
2. User-Provided Plugins: External developers could create CIS-based plugins distributed separately from opnDossier core, assuming they accept the licensing terms
3. Mapping Documentation: Community-maintained mapping tables between CIS controls and STIG/SANS equivalents (published separately from the project)
4. Custom Rule Engine: The proposed custom compliance rule engine (Issue #205) could theoretically support CIS controls if users provide their own CIS-licensed content

Relevant Code Files#

References#

• PR #274: Remove CIS trademark references - Primary implementation of the CIS restriction policy
• PR #28: Finish version 1.0 requirements - Initial compliance plugin architecture
• Issue #205: Custom rule engine proposal - Future compliance extensibility discussion
• Creative Commons BY-NC-SA 4.0 License - CIS Benchmark license terms
• DISA STIG Firewall Security Requirements Guide - Public domain alternative to CIS
• SANS Firewall Checklist - Freely available alternative to CIS

Document Version: 1.0
Last Updated: February 2026
Policy Status: Active and enforced
Contact: @UncleSp1d3r or security@evilbitlabs.io