OpenSCAP → Rapid7 InsightVM compliance

OpenSCAP ↔ Rapid7 InsightVM compliance: integration to migration path.

OpenSCAP deploys alongside InsightVM Policy first, scanning the same Linux hosts against the same benchmark while InsightVM stays authoritative. Only once the two engines agree at the rule level across a full audit cycle does Linux evaluation cut over to OpenSCAP — one Asset Group at a time, with the InsightVM waiver workflow still running as system-of-record. No flag day, no fleet-wide agent reinstall, and every step rolls back in minutes.

This is a partial migration by design. InsightVM keeps Windows, network gear, macOS, the Policy Editor waiver workflow, and the FedRAMP and PCI-ASV posture that OpenSCAP cannot reproduce. We say so up front, because the rest of this only matters if you can trust it.

The idea

Scan in parallel first. Hand off Linux last.

The topology that makes this zero-downtime: OpenSCAP evaluates the SCAP datastream on the same Linux hosts InsightVM Policy already scans, with results landing in DefectDojo for dedup while InsightVM remains authoritative and keeps owning Windows, network devices, macOS, and the waiver workflow. Once rule-level agreement holds at 95% or better across a full audit cycle, Linux evaluation flips to OpenSCAP and DefectDojo, and InsightVM waivers export nightly as a tailoring file the next OpenSCAP run consumes. The Insight Agent and SKU stay attached, so any group re-enables in 15 minutes. You are never betting the audit on one cutover.

The phases

Seven steps. Each one reversible.

0

Baseline & inventory

We document every Linux asset by OS and version, the Policy attached, the last scan and result, and the full waiver inventory — rule, asset, justification, approver, expiry. We map each in-use InsightVM rule to its SSG equivalent; the gaps become the deferred-coverage list. Read-only against the InsightVM API.

Users see: No user impact.

Rollback: N/A — read-only.

1

OpenSCAP scan plane on a canary

The scap-security-guide RPM installs on a canary group of at least 20 hosts across RHEL and Ubuntu, scanning the same benchmark InsightVM already runs. Both engines scan the same hosts for at least one full audit cycle and rule-level agreement is measured. InsightVM stays authoritative.

Users see: None. Canary owners see one new cron and a log location.

Rollback: Uninstall the SSG RPM and remove the cron — the canary reverts to InsightVM only.

2

Expand OpenSCAP to the full Linux fleet

OpenSCAP rolls out to every in-scope Linux asset in low, medium, then high blast-radius waves, with results flowing to DefectDojo for dedup and finding lifecycle. The InsightVM Policy scan keeps running and stays authoritative; only InsightVM is consumed downstream.

Users see: None — both engines run in parallel.

Rollback: Per wave: revert config management, remove the cron. The evidence chain is unaffected.

3

Cut Linux evaluation to OpenSCAP

Linux compliance evidence flips to OpenSCAP and DefectDojo as authoritative; InsightVM Policy scans for Linux are paused at the Site level. The InsightVM waiver workflow stays system-of-record, exporting waivers nightly as a tailoring file the next OpenSCAP run consumes. The agent and SKU stay attached, so re-enable is fast.

Users see: InsightVM dashboards show "Policy: not evaluated" for Linux — a communicated change. A new Grafana or DefectDojo view gives the Linux compliance picture.

Rollback: Re-enable the Policy scan in the Site. Under 15 minutes per group.

4

Optional: move waivers off InsightVM

Waivers move to the chosen replacement — git PR on tailoring files, a GRC exception module, or ServiceNow GRC — with the open waiver inventory migrated in one batch and the nightly InsightVM export cut. This is a discrete workstream with a PM and UX, not a sub-task.

Users see: Waiver requesters and approvers move to a new UI, with training.

Rollback: Re-enable the nightly InsightVM export and revert the waiver UX. Under one day.

5

Right-size the Linux Policy SKU

After a clean soak, the Linux Policy entitlement is dropped at the next renewal (or compliance evaluation is disabled on the Linux Insight Agents). The agent stays for vulnerability scanning and inventory; InsightVM Policy remains for Windows and network. Whether this is a real saving depends on whether Policy is separable from the vuln SKU.

Users see: No user impact.

Rollback: Re-enable Policy evaluation and re-add the SKU at the next contract event — window is until renewal, not minutes.

6

Retire InsightVM Policy entirely (out of scope)

Full retirement of InsightVM Policy on a mixed fleet is a separate workstream — the realistic answer for Windows and network is CIS-CAT Pro or another commercial scanner, not OpenSCAP. We do not assume this migration retires InsightVM Policy outright.

Users see: Not in scope for this path.

Rollback: N/A — gated on Windows and network having a real replacement first.

Feature parity

Where OpenSCAP matches InsightVM — and where it doesn't.

CapabilityOpenSCAPRapid7 InsightVM complianceParity
SCAP / XCCDF / OVAL scanning oscap xccdf eval (SCAP 1.3: XCCDF + OVAL + CPE + OCIL + ARF) InsightVM Policy scan (CIS / DISA STIG / USGCB built-ins) At parity
STIG / CIS benchmark content scap-security-guide STIG + CIS profiles InsightVM Policy library (CIS / DISA STIG / USGCB) At parity
Vendor content cadence SSG RPM lags DISA quarterly by weeks; mirror ComplianceAsCode/content to close the gap Rapid7-driven, same-day to a few days on STIG quarterlies SaaS only
OS coverage (Linux) OpenSCAP + SSG across RHEL / Rocky / Alma / Ubuntu / Debian InsightVM Policy via Insight Agent or credentialed Scan Engine At parity
OS coverage (Windows / network) SSG Windows content thin; no network-device benchmarks InsightVM Policy for Windows + Cisco IOS / NX-OS / PAN-OS SaaS only
OS coverage (macOS) OpenSCAP via mSCP only; verify mSCP coverage against your baseline InsightVM macOS Policy Partial
Remediation (Ansible) oscap xccdf generate fix --fix-type=ansible emits an idempotent playbook InsightVM remediation text + Remediation Projects; not first-party Ansible OSS only
Reporting / scorecards oscap xccdf generate report HTML; rollup via DefectDojo / GRC InsightVM Policy dashboards + Asset Group reporting Partial
Waiver workflow XCCDF tailoring file (--tailoring-file); no approver, expiry, or justification in the file InsightVM Policy Editor waiver workflow (approver / expiry / justification / audit-trail) SaaS only
Evidence / audit export Native ARF (--results-arf) + tailoring + report.html InsightVM proprietary Policy result format; SCAP export of varying fidelity Partial
Agent vs credentialed scan Local oscap / oscap-ssh; no agent Insight Agent or credentialed Scan Engine Partial
API surface oscap CLI only; orchestration is your own InsightVM REST API (/api/3/policies, /api/3/assets, Remediation Projects) SaaS only
Deployment model Self-hosted cron / oscap-ssh jump box InsightVM Console + Scan Engines + Insight Agent fleet (or Cloud) Partial
Cost model Compute + ops; no per-asset licence Per-asset Policy SKU (often bundled with the vuln SKU) OSS only
PCI ASV / FedRAMP posture In your ATO; not an ASV (covers PCI 11.3.1 internal only) InsightVM Cloud FedRAMP Moderate; Rapid7 is a PCI Approved Scanning Vendor SaaS only

What we're honest about

The caveats most vendors leave out.

The waiver workflow has no OSS parity

InsightVM's Policy Editor gives you approver, expiry, justification, and an audit-trail UI; an XCCDF tailoring file has none of that in the file itself. Underestimating this rebuild is the single biggest reason these migrations fail. We keep InsightVM as the waiver plane through Phase 3, then build the replacement UX — git PR, GRC, or ServiceNow GRC — as a discrete Phase 4 workstream with its own PM and UX, never a bolt-on.

Windows and network compliance stays on InsightVM

SSG Windows content is thin and there are no network-device benchmarks in OpenSCAP, so InsightVM Policy keeps Windows, Cisco IOS / NX-OS, and PAN-OS permanently. macOS is partial — OpenSCAP covers it only via mSCP. We do not attempt a Windows or network migration in this scope; the honest answer there is CIS-CAT Pro or a commercial scanner, and it is paywalled.

Vendor content cadence and the PCI ASV are real Rapid7 advantages

Rapid7 ships STIG-quarterly content same-day to a few days; the distro SSG RPM lags weeks. For auditor-sensitive shops we mirror ComplianceAsCode/content upstream and rebuild in-house, pinning the SSG version per scan in the evidence packet. And Rapid7 is a PCI Approved Scanning Vendor — OpenSCAP is not. OpenSCAP can satisfy PCI 11.3.1 internal scanning, but you contract a separate ASV for 11.3.2 external.

The self-hosted scan plane becomes your reliability problem

InsightVM Cloud also carries a FedRAMP Moderate boundary that self-hosted OpenSCAP does not — you join your own ATO instead, and ARF needs external signing for FedRAMP ConMon since OpenSCAP does not sign natively. Once Rapid7's managed backstop is gone, a broken OpenSCAP cron, DefectDojo, or S3 chain means evidence stops. That is exactly why we run it: monitored scan-completion, alarms on missed scans, and a documented RTO.

Why this beats a flag day

Reversible at every step, soaked before any SKU is dropped.

Every integration phase rolls back in under 15 minutes while parallel scanning is still live — remove the cron, or re-enable the InsightVM Policy scan at the Site level, and Linux evidence returns to InsightVM-authoritative on the next cycle. We never right-size the Linux Policy SKU until the OpenSCAP-authoritative model has held clean for at least 30 days with the GRC control rollup unchanged, helpdesk ticket volume at or below baseline, and auditor sign-off in writing. The asymmetric, slow-to-reverse phases come only after that soak gate, never before.

See whether your Linux fleet migrates cleanly.

A 30-minute call with a senior compliance engineer. We map your InsightVM Policy rules to SSG equivalents, size the waiver-workflow rebuild, find the scope that has to stay on InsightVM — Windows, network, macOS, PCI ASV — and tell you honestly what the Linux handoff looks like before you commit.

Map my migration →