Vulnerability management

Skans runs an offline, air-gap-capable vulnerability feed on the appliance itself. It syncs the public CVE List and MITRE ATT&CK into an on-box store, matches them against your live per-host inventory, and produces CVSS-scored, ATT&CK-tagged findings — the match runs entirely on the appliance, with no cloud scanner in the loop. This is how Skans supports the risk-assessment control (NIST RA-5) for an isolated enclave.

The credibility anchor: the match uses a strict version-range gate, not a name lookup. A host that is actually patched shows zero findings — proven in a live drill, a fully-patched host produced 0 hits — so a green result means green, not unscanned.

How the pipeline works #

A first-party worker, Skans.VulnFeed, owns the whole path:

1. Sync — it pulls the CVE List from cve.org (cvelistV5, CVE Record Format 5.0) and MITRE ATT&CK Enterprise (STIX), and loads them into on-box reference indices.
2. Match — it joins your live inventory against each CVE’s affected-version ranges. A broad product-and-version match finds candidate hits; a strict version-range check then gates every candidate, so software that has been patched past the affected range stays quiet.
3. Write — each surviving hit becomes a finding carrying a severity / CVSS score, a fix target (the fixedIn version), a prioritized remediation summary, and the matching ATT&CK technique tags.

Everything lives in the appliance’s on-box search store (OpenSearch, reached locally). Nothing about this pipeline leaves the wire.

Air-gap integrity: the signed feed bundle #

For an air-gapped site, the CVE + ATT&CK (and related) feeds arrive as PackSigner-signed .skb bundles. SyncBundleSvc CMS-verifies each pack against the held pack anchor before any indexing — a tampered or unsigned bundle is refused, and nothing is ingested. This is the authenticated path for sites with no internet.

Connected sites can pull the same signed packs through the Skans Update Service (SUS) (sus.skanslabs.com) with Skans.ControlPlane.exe --sus-apply, which downloads entitled threat-feed packs and applies them via VulnFeed ingest. A direct-internet pull to upstream publishers is not required once SUS is enabled and applying.

Related live feed classes on SUS include KEV, CVE, ATT&CK (Enterprise + ICS), EPSS, and Sigma — see the SUS content table.

What findings look like #

Each finding on a host is CVSS-scored and tells you the fix target — the version that clears it. Alerts are enriched with ATT&CK technique IDs (for example T1110, brute force) so a finding reads as adversary behavior, not just a number.

A Critical CVE match rule watches the findings index; when it fires, AlertSvc raises an on-box alert and dispatches it to your configured sinks (SMTP, webhook, SIEM-forward) alongside every other Skans alert — see Alerts & notifications.

Threat-intel fusion: KEV + EPSS #

Matched findings are enriched with two public threat-intelligence feeds, so triage can rank by real-world exploitation rather than CVSS alone:

• CISA KEV — the Known Exploited Vulnerabilities catalog syncs into an on-box index (skans-kev); a finding whose CVE is in the catalog is stamped kev=true, so actively-exploited vulnerabilities sort to the top.
• FIRST.org EPSS — each matched CVE carries its EPSS exploit-prediction score, an estimate of the probability the CVE will be exploited in the wild.

The ATT&CK technique tags on findings come from a CVE → CWE → ATT&CK join: the weakness class a CVE belongs to links it to the adversary techniques that exploit that class.

Where you see it in the console #

• Security → Vulnerabilities — the CVE / CVSS matches across the enclave, or an honest 0 when nothing matches.
• Each device’s Vulnerabilities tab — that host’s findings, with an Open remediation request action that routes the fix into the patch-approval flow.
• ATT&CK tags on every finding — each hit carries its mapped technique IDs (for example T1110), so you can read a finding as adversary behavior.
• Attempt fix — on a finding for a host that has an approved enrolled agent, the operator can confirm Attempt fix (cap:device.manage). That queues a signed agent command only — nothing runs until the agent checks in.

Attempt fix (operator-gated host remediation) #

Scripts are Skans first-party only (no third-party remediation packs). The engine never auto-queues Attempt fix from a rule fire or CVE discovery. Results land in agent job status (script:vuln-… / install ids) and surface on the expanded finding when present.

The honest boundary #

Read this before you treat Skans as a full auto-remediation or IDS tool — it is neither, by design.

For admins: run model #

The feed runs on a schedule, not on demand. The in-process periodic-jobs engine inside the always-on control-plane service runs the sync-and-scan (--sync --scan) weekly as one of its supervised jobs — there is no OS scheduled task and no separate scheduler service to maintain.

Compliance framing #

This capability supports NIST RA-5 (vulnerability monitoring, primary) and SI-2 (flaw remediation, via the patch hand-off), and feeds SI-4 / SI-5 posture. That is an enabler, never a certification — see NIST 800-171 / CMMC evidence for what Skans owns technically versus the organizational controls that remain yours.

Next #

• Patching & update rings → — where a finding’s remediation actually lands
• Detection content & response → — agentless Respond vs host Attempt fix
• Alerts & notifications → — how a critical CVE match reaches you
• NIST 800-171 / CMMC evidence → — RA-5 / SI-2 in the evidence pack