OpenSCAP / Lynis → Tenable.sc compliance

OpenSCAP / Lynis ↔ Tenable.sc compliance: integration to migration path.

Compliance scanning rarely retires the incumbent cleanly. So OpenSCAP and Lynis deploy alongside Tenable.sc first, scanning the same Linux hosts against the same profiles, while Tenable.sc stays the evidence-of-record. Only once rule-level agreement is proven does OpenSCAP take over Linux scope, one audit cycle at a time — no flag day, no re-keyed evidence chain, and every step rolls back in minutes.

This is a partial migration by design. Tenable.sc keeps Windows, macOS, the FedRAMP-authorized scan service, and the ARC executive layer that your audit committee already reads. 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 runs the SCAP datastream and Lynis runs daily drift checks on the same Linux hosts Tenable.sc already scans, both writing ARF and report artifacts to your evidence bucket while Tenable.sc remains authoritative. Tenable.sc keeps owning the Windows fleet, macOS, the FedRAMP-boundary scan service, and the ARC dashboards throughout. Once the two engines agree at the rule level across a full audit cycle, the signed OpenSCAP ARF becomes the evidence-of-record for Linux — and only for Linux. You are never betting the audit on one cutover.

The phases

Seven steps. Each one reversible.

0

Baseline & inventory

We classify every host by OS family, map each compliance policy (CIS L1/L2, STIG version, custom) to a target SCAP profile, and record which ARC tile and evidence destination each scan feeds. Read-only against the Tenable.sc API. Nothing changes.

Users see: No user impact.

Rollback: N/A — read-only.

1

OpenSCAP + Lynis on a canary ring

OpenSCAP and Lynis stand up on a canary group of at least 30 Linux hosts across two-plus distros, scanning in parallel against the same XCCDF profile Tenable.sc already runs. Tenable.sc stays the evidence-of-record for the canary throughout.

Users see: None for hosts. The SRE team gets new dashboards.

Rollback: dnf remove openscap-scanner lynis — Tenable.sc untouched.

2

Parallel scanning across the Linux fleet

Both engines roll out to every Linux host via your existing config-management tool and run for at least one full audit cycle. A comparison dashboard tracks per-rule pass/fail agreement and dispositions every net-new finding. Tenable.sc remains evidence-of-record.

Users see: Two scan windows per host per cycle; a short CPU and I/O spike during each scan.

Rollback: Disable the OpenSCAP timers via Ansible — the Tenable.sc evidence chain is untouched.

3

Linux evidence-of-record moves to OpenSCAP

Once rule-level agreement holds at 95% or better, the signed OpenSCAP ARF becomes the evidence-of-record for Linux compliance. Tenable.sc keeps scanning Linux for ARC continuity, but its Linux output is no longer cited in audit packages. Windows, macOS, and appliance scope is unchanged.

Users see: None for hosts — an auditor-facing change only.

Rollback: Revert evidence pointers to Tenable.sc Linux scans. Under 15 minutes (parallel scanning is still live).

4

Downscope Tenable.sc Linux to read-only

Tenable.sc Linux compliance scans keep running but write to a shadow repository only — not consumed by audit, not on the ARC. Seats are not reduced yet; we hold parallel for one more cycle as insurance. Windows, macOS, and FedRAMP-boundary scope stays active and authoritative.

Users see: ARC dashboards are re-skinned; we communicate to audit-committee consumers at least 30 days ahead.

Rollback: Re-promote the Linux repository and revert ARC rewiring. Under 60 minutes (ARC editing involved).

5

Optional: drop Linux seats, consolidate to GRC

After a clean soak, Linux hosts come out of the Tenable.sc asset lists and seat count drops to non-Linux scope. Optionally an OSS or commercial GRC stands up as the cross-control rollup layer, with auditor sign-off on the GRC view as system of record.

Users see: None for hosts; audit-committee dashboards are finalised.

Rollback: Re-add hosts and re-enable scans — hours, not minutes. This is the asymmetric phase; never enter it without a clean 30-day Phase 4 soak.

6

Retain Tenable.sc for residual scope

Steady state. Tenable.sc owns Windows, macOS, FedRAMP-boundary compliance, and the residual ARC tiles. OpenSCAP and Lynis own Linux. Both run indefinitely, with the scope split re-baselined every 12 months.

Users see: No user impact.

Rollback: N/A — this is steady state.

Feature parity

Where OpenSCAP matches Tenable.sc — and where it doesn't.

CapabilityOpenSCAP / LynisTenable.sc complianceParity
SCAP / XCCDF / OVAL scanning OpenSCAP oscap xccdf eval (SCAP 1.3 datastream, XCCDF + OVAL + ARF) Tenable.sc compliance plugin family + Nessus audit files (SCAP-import capable) At parity
STIG / CIS benchmark content scap-security-guide (SSG) STIG + CIS L1/L2 profiles Tenable.sc DISA STIG / CIS audit files At parity
Vendor content cadence SSG RPM lags DISA quarterly by days to weeks; mirror ComplianceAsCode/content to close the gap Tenable audit-file library updated same-day on DISA drops, plus out-of-cycle SaaS only
OS coverage (Linux) OpenSCAP + SSG across RHEL / Rocky / Alma / Ubuntu (USG) / Debian; Lynis test categories Tenable.sc Linux compliance scans At parity
OS coverage (Windows) SSG Windows content is thin; no formal SCAP datastream parity Tenable.sc Windows STIG / CIS compliance plugins SaaS only
OS coverage (macOS) OpenSCAP via mSCP content only; verify mSCP profile coverage against your baseline Tenable.sc macOS audit files Partial
Remediation (Ansible) oscap xccdf generate fix --fix-type=ansible plus ansible-hardening Tenable.sc fixtext + vendor KB links; no playbook emission OSS only
Reporting / scorecards oscap xccdf generate report HTML + Lynis Hardening Index Tenable.sc Assurance Report Cards (ARC) executive rollup SaaS only
Waiver workflow XCCDF tailoring file (--tailoring-file) git-tracked; no built-in approver or expiry Tenable.sc compliance audit-file edits in the UI; no formal waiver UX either Partial
Evidence / audit export Native ARF (--results-arf) + tailoring + signing manifest Nessus .nessus result file + signed PDF; ARF export not native Partial
Agent vs credentialed scan Credentialed local oscap / oscap-ssh; no agent Tenable.sc credentialed scan via Nessus scanners At parity
Cost model Compute + ops; no per-asset licence Per-IP / per-asset licensing OSS only
FedRAMP / ATO posture Self-hosted; joins the customer's own ATO boundary Tenable FedRAMP-authorized scan service SaaS only

What we're honest about

The caveats most vendors leave out.

The ARC executive layer has no OSS parity

Tenable.sc's Assurance Report Cards are genuinely best-in-class for board-level compliance reporting, and OpenSCAP plus Lynis do not reproduce that rollup. We keep Tenable.sc ARC for the retained scope; only if you already run a GRC (OpenRMF, eMASS, Archer, ServiceNow GRC) do we rebuild the rollup there — and only with auditor sign-off before any downscoping.

Windows and macOS compliance stays on Tenable.sc

SSG Windows content is thin and there is no formal SCAP datastream parity, so OpenSCAP cannot own the Windows fleet — that coverage gap persists for the life of the topology and we budget for it. macOS is partial too: OpenSCAP covers it only via mSCP content, which may not match your baseline. Tenable.sc keeps both, permanently.

Vendor same-day STIG content is a real Tenable advantage

DISA ships STIGs quarterly with out-of-cycle critical updates, and Tenable's audit-file library lands them on day zero. The distro SSG RPM lags by days to weeks. For FedRAMP-boundary hosts we mirror ComplianceAsCode/content upstream and rebuild to close the gap; for everything else we document the lag in the SSP risk register honestly.

Waivers and the FedRAMP scan service need building or keeping

XCCDF tailoring is the SCAP-formal equivalent of a waiver and is git-reviewable, but it has no built-in approver, expiry, or ticketing — we build that on PR review and a scheduled re-baseline. And Tenable's FedRAMP-authorized scan service has no OSS replacement: self-hosted OpenSCAP joins your own ATO boundary, so we keep Tenable.sc for FedRAMP-boundary hosts rather than pretend otherwise.

Why this beats a flag day

Reversible at every step, soaked before anything is cancelled.

Every integration phase rolls back in under 15 minutes while parallel scanning is still live — uninstall the OSS engines, or flip the evidence pointers back to Tenable.sc, and your audit chain is exactly where it started. We never reduce a Tenable.sc seat until the OpenSCAP-as-evidence model has held clean for at least 30 days with no audit issue, no FedRAMP deviation, and no ARC consumer complaint. The asymmetric, hours-not-minutes 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 classify your hosts by OS family, map your Tenable.sc policies to SCAP profiles, find the scope that has to stay on Tenable.sc — Windows, macOS, FedRAMP, ARC — and tell you honestly what the Linux handoff looks like before you commit.

Map my migration →