The control language

describe, it, expect, resources.

InSpec’s language is a readable Ruby DSL built around three ideas: a resource (something on the system — a file, a package, a port, a service), a matcher (a check about it — installed?, listening?, its content), and the describe/it block that ties them into an assertion. The result reads almost like the requirement itself, which is the point: control code doubles as documentation of the policy.

control 'ssh-01' do
  impact 1.0
  title 'SSH must not permit root login'
  desc 'Direct root SSH login must be disabled (CIS 5.2.x).'
  describe sshd_config do
    its('PermitRootLogin') { should eq 'no' }
  end
  describe port(22) do
    it { should be_listening }
  end
end

Controls, impact, and metadata

A control wraps one or more describe blocks with metadata: a unique id, an impact (0.0–1.0 severity — a failed 1.0 control is critical, a 0.0 is informational), a title, and a desc. This metadata is what makes reports useful and auditable — the id maps to a requirement, the impact drives prioritization, and the title/desc explain the intent. You can write bare describe blocks, but real profiles wrap them in controls with full metadata.

control 'pkg-01' do
  impact 0.7
  title 'Telnet must not be installed'
  describe package('telnet') do
    it { should_not be_installed }
  end
end