Compliance & hardening

Netpilot can audit a device’s running-config against a security hardening baseline and produce a scored deviation report. For network gear there is no OpenSCAP/CIS-CAT equivalent, so Netpilot’s YAML baseline engine is the assessor: you upload a config, it checks every control, and tells you exactly what is non-compliant and how to fix it.

How it works

Back up the device (or drop a .cfg into the backup directory).
Run the compliance check against a vendor baseline.
Review the deviation report (CSV, or a formatted Excel checklist).
Remediate — each failed control ships the exact config to apply.

python -m src --baseline nexus

This loads config/compliance/baselines/nexus.yml, finds the latest backup for each device, evaluates every check, and writes SUMMARY/YYYY-MM/COMPLIANCE_timestamp.csv.

Baselines

A baseline is a YAML file at config/compliance/baselines/<name>.yml. The file name is the value you pass to --baseline. Each baseline is one vendor’s hardening standard expressed as machine-checkable controls.

name: Cisco NX-OS Hardening (SSOE2 v2.0)
categories:
  - name: Access Control
    checks:
      - id: NX-4.3.7
        name: Telnet feature disabled
        expect: 'feature telnet'
        expect_type: not_exists
        severity: critical
        ref: SSOE2 4.3.7
        rationale: Telnet is clear-text; credentials are interceptable.
        remediation: |
          no feature telnet

Check fields

Field	Required	Purpose
`id`	yes	Control ID, traceable to the benchmark clause
`name`	yes	Short control title
`expect`	yes	Config pattern to match
`expect_type`	yes	`regex`, `exists`, or `not_exists`
`severity`	yes	`critical` / `high` / `medium` / `low`
`applies_if`	no	Guard pattern — see Not Applicable
`ref`	no	CIS / standard clause reference
`rationale`	no	Why the control exists (shown in reports)
`remediation`	no	Exact config to apply the fix (push-ready)

The engine reads id/name/expect/expect_type/severity/applies_if. ref, rationale, and remediation are surfaced by the Excel report.

Match types

`expect_type`	Compliant when
`regex`	the pattern matches a line (multiline, case-insensitive)
`exists`	the literal string is present
`not_exists`	the literal string is absent (use for prohibited config)

Not Applicable controls

Absence in a config does not always mean non-compliance. A control for a feature the device does not run (EIGRP auth on a switch with no EIGRP) should be Not Applicable, not a failure.

Add applies_if with a guard pattern: the check only runs when the feature is present. Otherwise it is marked N/A and excluded from the score.

- id: NX-4.15.2
  name: OSPF authentication configured
  applies_if: '^feature ospf'      # only check if OSPF is enabled
  expect: 'ip ospf authentication'
  expect_type: regex
  severity: high

Excel report

For an auditor-ready checklist (one row per control, colour-coded result, rationale, and remediation), generate an Excel workbook:

python scripts/compliance_to_excel.py \
  --config config/compliance/pdf/DEVICE.cfg \
  --baseline nexus \
  --pdf "config/compliance/pdf/Benchmark.pdf"

The workbook mirrors the benchmark checklist columns, auto-fills the Deviation (Y/N/NA) column from the live result, and includes a Remediation column on every failed control. Pass the --pdf to also emit reference rows for benchmark items that are reviewed manually.

Result	Meaning
PASS	Control satisfied
FAIL	Deviation — apply the remediation
N/A	Feature not in use, excluded from score

Adding a vendor

Netpilot’s engine is vendor-agnostic — adding a vendor is just authoring its baseline:

Obtain the vendor’s hardening benchmark (CIS, vendor guide, or internal SOP).
Create config/compliance/baselines/<vendor>.yml following the schema above.
Calibrate the expect patterns against one known-good config for that vendor — inferred regexes need validation against real output.
Add applies_if guards to any feature-conditional controls.
Run python -m src --baseline <vendor> and confirm the score is sane.