Докази CIS benchmark

CIS Benchmarks  are consensus-developed secure-configuration recommendations. CIS describes Level 1 as broadly usable baseline and Level 2 as defense in depth that can affect utility or performance. Apply either profile in test environment first.

OpenFactory can apply selected controls and run catalog of machine checks. Passing run is evidence about that artifact, benchmark version, profile, point in time. It is not CIS certification, guarantee about deployment settings, or proof of compliance with another framework.

Current remediation boundary

cis-benchmarks feature has one full, pinned remediation path:

Ubuntu path deliberately disables or adapts selected upstream rules to fit offline-first-boot and image environment. Generated manifest records provenance and selected settings. These adaptations make exact evidence and exceptions essential.

security-hardening and os.security.hardening_level are separate general-hardening controls. They do not map automatically to complete CIS Level 1 or Level 2 profile.

Benchmark execution

Scenarios can select exact catalog and level:

{
  "id": "ubuntu-cis-evidence",
  "name": "Ubuntu 24.04 CIS evidence",
  "enabled": true,
  "tests": ["boot", "login", "packages", "services"],
  "cis_benchmark": "CIS_Ubuntu_Linux_24.04_LTS_Benchmark_v1.0.0",
  "cis_level": "L1"
}

Runner also has catalogs for Debian 12 and Debian 13 and internal GxP-oriented check set. Catalog name not proof of official CIS content or currentness. Confirm catalog provenance, license, version, control definitions before using in audit.

Do not use older OS benchmark as conformance claim for newer release. Resolver currently has approved same-family fallbacks for some newer Ubuntu and Debian targets so tests can run, but output must be labeled as compatibility assessment against older catalog, not as conformance to benchmark for newer OS.

Reading a result

Retain at least:

• artifact and build IDs;
• image digest and source snapshot;
• base OS identity and version;
• benchmark/catalog ID, profile, digest;
• applicable, passed, failed, skipped, not-applicable controls;
• raw command output and timestamps;
• remediation provenance;
• documented exceptions with owner and approval; and
• environment in which checks ran.

Percentage alone hides applicability and severity. Run with zero failed applicable checks still says nothing about controls outside catalog, deployment-time changes, credentials, networks, physical hardware, later drift.

Safe workflow

1. Select benchmark that exactly matches target release.
2. Review profile and every OpenFactory adaptation.
3. Build artifact and wait for first-boot remediation readiness.
4. Run complete applicable check set in clean guest.
5. Investigate failures; do not silently convert to not applicable.
6. Test application and operational behavior after hardening.
7. Have accountable security owner approve exceptions.
8. Re-run after any package, recipe, deployment change.

Use CIS own profile guidance  as normative starting point and obtain applicable benchmark through authorized CIS distribution channel.