CIS Ubuntu Benchmark 2204

Technical Details

The workspace builds one filtered result from the local benchmark catalogue, the current form state, and the selected control. The same result drives the summary cards, Controls table, Sections table, selected Script view, CSV export, and JSON output.

The technical scope stays tied to benchmark and operating-system sources. Center for Internet Security (n.d.-a) anchors the benchmark family, Canonical (2021) anchors the Ubuntu 22.04 LTS release scope, and Center for Internet Security (n.d.-b) keeps the boundary clear between a browser catalogue and a live host assessment.

1. Copied benchmark inventory

The catalogue is generated from the copied scripts under templates/content/tools/cis/assess-ubuntu-2204-cis/assets/bin/ and embedded through assets/custom.json.twig. The current inventory describes 297 shell scripts across 71 section paths and 7 top-level families.

2. Filter and URL state

The browser state is derived from the visible controls and synchronized into URL query parameters such as cis_query, cis_family, cis_section, cis_criticality, cis_control, cis_sort, and cis_rows. This supports shareable filtered views without introducing JSON import or restore behavior.

3. Selected script loading

The script body is not embedded into the catalogue payload. When a script is selected, the browser posts the relative script path to the Symfony endpoint at /api/cis/assess-ubuntu-2204-cis/script. The endpoint normalizes the path, rejects traversal, limits reads to .sh files under assets/bin/, and returns the selected source body.

4. Metadata limits

Some copied scripts declare CRITICALITY; others do not. The workspace labels missing values as unspecified so review gaps stay visible. It does not infer severity, remap controls, or certify benchmark coverage.

5. How to read the catalogue

Read this workspace as a navigation and review layer over a local script set. It helps you find controls, inspect script bodies, group sections, compare metadata, and export a filtered view. It does not decide whether an Ubuntu host is hardened. It does not execute benchmark scripts. It does not inspect packages, services, kernel settings, audit rules, file permissions, users, groups, or running configuration on a server.

That boundary matters. A copied shell script can describe an intended check or remediation, but the host result still depends on the target machine, current package versions, local policy, exceptions, compensating controls, and how the script is run. The browser view gives you order and visibility. Evidence still has to come from the host or from a controlled assessment process.

6. Filter discipline

The filter controls are meant to narrow a large benchmark catalogue into a reviewable set. Search is useful when you know a control name, title, command, package, or keyword. Family and section filters are better when the review follows the benchmark structure. Criticality filters are useful for triage, but they should not be treated as a complete risk model because some source scripts have unspecified values.

Sorting and row limits change the visible table, not the underlying catalogue. If a filter returns fewer rows than expected, clear the query before assuming a section has no controls. If a selected control disappears after filter changes, select it again from the current result set so the script view and export match the review context.

7. Script body handling

The selected script body is loaded only when requested. The backend endpoint normalizes the submitted relative path and limits reads to local shell files under the tool package. That keeps the page lighter and avoids embedding every script body into the initial catalogue payload. It also keeps path handling explicit instead of trusting arbitrary browser input.

Script display is for reading, copying, and downloading. Treat copied shell as operational material. Review variables, assumptions, package names, service names, filesystem paths, and any command with destructive or persistent effects before use. A script written for one benchmark context may still need local change control, backup, test execution, or approval before it belongs on a production host.

8. Assessment boundaries

This workspace does not replace a benchmark scanner, configuration management run, audit program, or compliance platform. It does not compare a live server against every CIS recommendation. It does not prove pass or fail status. It does not know which controls are out of scope for a workload, which exceptions are approved, or which compensating controls an organization accepts.

Use it for preparation and review. A platform engineer can find relevant scripts, inspect shell bodies, and export a filtered list for a change. A security reviewer can identify missing metadata, unspecified criticality, or areas needing evidence. An operations team can use the section table to plan work by benchmark family. Those are useful tasks, but they are not the same as certification.

• Catalogue rows do not prove that packages, services, files, users, groups, permissions, or kernel settings match a benchmark target.
• Copied scripts can still be destructive, persistent, environment-specific, or wrong for the host class under review.
• Exported rows are useful work notes, not audit evidence until a controlled assessment records real host output.

9. Export and handoff behavior

CSV is useful for filtered control lists, section summaries, and review notes. JSON is useful when the active filters, selected control metadata, visible rows, and summary counts need to be preserved together. Neither export proves that a host was scanned or remediated. They preserve the workspace state and catalogue view.

When handing off a filtered set, include the target context outside the export: Ubuntu version, host class, environment, exception policy, maintenance window, reviewer, and evidence location. If a control will be executed, pair the copied script with a test plan and rollback plan. If a control is informational, pair it with the evidence expected from the host.

10. Human review workflow

Start at the section level. Confirm which top-level benchmark family is in scope, then narrow to the relevant section path. Use search only after the structural scope is clear. Select scripts deliberately and read the source body before copying. The fastest way to misuse a hardening script is to trust a title without reading the command.

Next, separate catalogue completeness from host readiness. Missing criticality metadata is a catalogue issue. A failed package check is a host issue. An approved exception is a governance issue. The workspace can help keep those categories separate by showing filters, sections, selected script content, and export payloads in one place.

11. Practical review checklist

Before using a script from the workspace, answer the review questions in the same place as the selected row:

• Scope: Confirm the Ubuntu release, host class, benchmark family, section path, and selected control.
• Script: Decide whether the body is an audit check, remediation action, helper, or mixed shell workflow.
• Evidence: Define what output should be captured before and after any controlled execution.
• Change: Name the approval path, maintenance window, rollback plan, and exception owner when needed.
• Decision: Mark the next action as inspect, test, remediate, defer, except, or close with evidence.

The final output should make the next action clear: inspect more scripts, export a filtered evidence list, copy a specific script for controlled testing, record a metadata gap, or hand a section to the owner. That is the useful level for this tool. It turns a large local benchmark tree into a reviewable working surface without pretending to be the host assessment itself.

12. Change-control context

Hardening work touches running systems, so catalogue review should be connected to change control. Before a script is used outside a lab, record whether it only checks state or whether it modifies packages, files, services, kernel parameters, audit rules, users, groups, permissions, or authentication behavior. That distinction determines who must approve the action and what evidence should be captured.

Some controls are straightforward on a fresh server and risky on a long-lived workload. A service that should be disabled in a baseline might still support a legacy process. A filesystem option might require a reboot or maintenance window. A permission change might affect application startup. The workspace cannot know those local dependencies. It can only make the script easy to inspect before someone applies it.

13. Evidence and exception handling

When a control is accepted, rejected, or deferred, keep the reason near the exported row. Good notes say whether the decision came from successful evidence, approved exception, compensating control, business constraint, or missing data. Weak notes say "not applicable" with no owner and no date. Future reviewers deserve better than that.

Use unspecified criticality as a signal to inspect, not as an excuse to ignore. If the control matters to the environment, assign a local severity or review priority during the assessment process. If it does not apply, record why. The tool is strongest when it helps the team separate real security work from catalogue noise.

Final review should end with an owner, a decision, and an evidence path. If the row is ready for testing, say who tests it, where they test it, and what output proves success. If the row is deferred, say why and when it returns. If the row is an exception, link the approval and expiry date. Catalogue work becomes useful when it leaves fewer unnamed decisions behind for the next engineer who has to trust the record during audit or change.

14. Result and export model