Using CISA KEV to prioritize STIG work.
The CISA Known Exploited Vulnerabilities catalog answers a question CVSS scores cannot: what is being exploited right now. kevstig turns that catalog into priorities for the DISA STIG baselines you maintain.
Why exploited beats CVSS
A CVSS 10.0 with no exploit in the wild can wait a patch cycle. A 7.5 with an active exploitation entry in KEV is already being used against someone. When the question is what to harden first, the catalog's known exploited signal is the one worth routing against — and the STIG baselines are the natural counterweight, because they enumerate exactly the configuration surface of each platform you run.
The live checker
The checker page refreshes daily at 05:37 UTC from the current KEV catalog and republishes the routing. This page deliberately does not copy its numbers — the catalog shifts every day by design, so the checker page is the single home of the live counts and this page carries the method.
What it routes — and what it refuses to guess
The checker matches each KEV entry against the products covered by the maintained STIG baselines. The semantics are deliberately narrow:
- Literal product matching — a KEV entry routes only when its product string actually matches the platform, and the mapping's version ranges are honored. No fuzzy matching, no "probably the same thing".
- Per-generation VMware rows — the vSphere/ESXi family is routed per STIG generation rather than merged, because the baselines differ meaningfully between generations.
- Empty-platform guards — a KEV entry without a resolvable platform is excluded rather than guessed onto a baseline, so lookalike products do not create false coverage.
The JSON API
The checker publishes two static JSON surfaces beside itself — the full routing and a headline summary:
curl -s https://bedimsecurity.com/capabilities/kevstig/api/headline.json | jq .
curl -s https://bedimsecurity.com/capabilities/kevstig/api/coverage.json | jq '.[0]'The checker page itself is a client-side filter over the same
coverage.json — no accounts, no tracking, plain static files,
so the same URLs work from a script without touching the site's dynamic parts.
Routed is not remediated
A routed KEV entry does not mean the vulnerability is fixed by the STIG. STIG baselines harden configuration; the parsed STIG XMLs carry zero CVE references (verified in the repository). Routing answers which platforms have live KEV pressure against maintainable configuration baselines — a prioritization signal, not a patch report.
The uncovered gap is the artifact
The KEV entries that fall outside the maintained baselines are published as deliberately as the covered ones — the crosswalk page carries that analysis. A gap list is honest in a way a green dashboard is not: it names what would need a baseline next.
Cadence: the checker pulls the KEV catalog daily at 05:37 UTC and republishes the routing and both JSON surfaces. Counts drift day to day by design — always read them on the checker itself; anything static quoting them (this page included) goes stale on purpose.
Source
- github.com/dmrobbi/kevstig — the repository (MIT): the checker, the mapping state, and the refresh pipeline.
- Three ways to work a STIG checklist — where the baselines kevstig prioritizes come from.