Content Pipeline
Working through the whole National Vulnerability Database is the easy half. Deciding which records are worth acting on, refusing the ones that cannot be checked on a real host, and being able to show your working — that is the half that takes a position and has to be defended. This page describes that pipeline, and gives the figures behind every claim on it, each with its source and the date it was measured.
Read This First
AuditToolkit ships two independent bodies of audit content. They answer different questions, are produced by different processes, and are counted by different units. If you have seen a figure from one and a figure from the other, they will not reconcile — and they are not supposed to.
| Static audit suite | Dynamic content packs | |
|---|---|---|
| Question it answers | Is this system configured safely? | Is a known-vulnerable version present? |
| What it probes | Config files, registry values, kernel parameters, service state, audit and security policy, file permissions | Installed package versions, registry uninstall entries, command version output |
| How it is written | Hand-built against hardening benchmarks and operational experience | Generated from public CVE feeds, then validated and signed |
| How it reaches you | Ships inside the product; versioned with the release | Delivered between releases as a separate signed pack |
| Counted in | Script files | CVEs, and the script files those CVEs generate |
| Current figure | 1,019 audit / 712 fix scripts | 20 CVEs → 117 audit / 117 fix scripts |
Because they are counting a different thing, at a different granularity, over a different time window. The suite is years of accumulated hardening content shipped as one corpus. A content pack is an increment — the CVEs that passed both the relevance lens and the actionability gate for that release. A pack containing 20 CVEs is not 20 checks: one CVE affecting twelve Windows builds yields a probe for each, which is how 20 CVEs become 117 audit scripts.
A combined figure would imply breadth that does not exist. Generating more CVE content does not increase hardening coverage at all — no CVE record contains a configuration expectation, so the two axes grow independently. Any vendor quoting one blended “total scripts” number is either counting both axes as though they were interchangeable or counting audit and fix scripts twice. We publish them separately so you can check either one on its own terms.
Principles
Every feed pull normalises to structured fields only — CVE ID, CPE, version ranges, CVSS, CWE, references, publication dates. Advisory prose is not carried into a generated script. Detection logic and remediation wording are written by us from those facts. That is a licensing control as much as a data-hygiene one: no vendor’s or standards body’s text is redistributed inside something we ship, and every decision downstream can be re-derived from a public feed rather than from somebody’s paraphrase.
Passing the relevance filter is not sufficient. A CVE must also resolve to a real probe — a registry key, an installed package version, a file, a config line, a command output. Where a detection would degrade to “check this manually,” generation is refused rather than shipping a script that restates the CVE description back to you and calls it a check.
The Pipeline
Each stage either emits evidence or refuses to continue. The whole run is headless — no editor, no human clicking through.
NVD 2.0 for CVE, CVSS and CPE data; CISA KEV for known-exploited status; EPSS (FIRST.org) for exploit probability. All three are public and free to use. Every generated script embeds a provenance block recording the source, source URL, CVE ID, retrieval timestamp and template version, and echoes it in the report for traceability.
This is the entire filter, as it appears in the orchestrator:
keep = KEV
OR (cvss >= 7.0 AND year >= 2020)
OR (epss >= 0.5)The load-bearing operator is the AND. Severity ORed with recency retains most of the corpus — a decade of high-scoring findings against software few people still run. ANDing them is what makes the funnel a funnel. It is a judgement call, which is why the reasoning sits in the source directly above the line rather than in a slide.
Note what the AND does not do: KEV overrides age entirely. Of the 1,631 CVEs on the CISA Known Exploited catalogue we last pulled, 551 — 33.8% — were published before 2020, and every one of them is retained. Actively exploited is actively exploited, whether it was disclosed last week or in 2014. The current pack carries CVE-2014-0160 for exactly this reason.
Nothing dropped is dropped silently. Each run reports how many records the lens filtered as not-relevant and how many fell past the batch cap.
Every surviving CVE must resolve to a host-checkable detection. If it cannot, the generator refuses it and logs it for enrichment with the reason and what would make it auditable — a concrete package, registry, file or command hint.
Detection quality travels with the content as a field you can filter on, not as a footnote. In the pack described below,
18 of 20 CVEs are marked high detection confidence and 2 are marked inferred, and
18 of 20 detect via an operating-system package or registry probe, the remaining 2 via a command-version
probe.
On the estate question we are deliberately modest: the funnel does not know your deployment. It ships a probe that asks the host. Absent component or absent version evidence, the script reports SKIP or indeterminate rather than asserting a vulnerability it cannot see.
A generated fix changes state only where the strategy is auto-applicable and every primitive it uses is on a known-safe, reversible allowlist — registry set, config-line ensure, package upgrade, sysctl, permissions, policy. Anything else, and anything marked manual-review, is report-only and emits upgrade steps instead of acting.
Every fix carries -WhatIf, rollback, backup capture, an applicability check, evidence logging and an indemnity
block. NVD supplies no remediation steps — so making a CVE auto-fixable is a deliberate, attributable human act, never
a default.
Each generated audit and fix pair is validated on nine named checks before it is allowed into a pack:
audit-syntax, audit-lint, audit-policy (read-only enforcement), audit-indemnityfix-syntax, fix-lint, fix-policy (safety enforcement), fix-indemnityprovenanceLint runs real engines — PSScriptAnalyzer, ShellCheck, Ruff and Bandit. Any failing check fails the whole report, and the run exits non-zero. Above that sits a behavioural stage that runs audits against a live test host so they return real results rather than merely parsing.
Packs are GPG-signed in CI against a single authoritative artefact-signing key, alongside a signed
SHA256SUMS file. The release job then does two things most pipelines do not: it
refuses to publish if any artefact is missing its signature, and it re-verifies every signature and checksum
the way a customer would, catching a wrong-key signature before it reaches anyone. Signing happens in CI, not
on a workstation.
A run that adds nothing does not become a release. Every build is fingerprinted against the previous pack, and one that is byte-identical is refused rather than published — it is recorded as a check run instead. You should never be asked to schedule a maintenance window, transfer a pack into a controlled site and install it, only to find it overwrote identical files and changed nothing. If a pack exists, it contains something new.
A pack ships with a per-file SHA-256 manifest, provenance for the feed snapshot and generation run, and a changelog naming what was added, removed or changed since the previous release. It installs through an updater that backs up first, gates on version, applies as an overlay and rolls back on any failure. The overlay writes only pack-owned content. And it is a file — so it crosses into an air-gapped site on controlled transfer, with no production host ever dual-homed to fetch content from the internet.
Freshness
We measure two clocks, and we are explicit about which one we hold ourselves to.
From the moment a CVE record becomes checkable — when NVD attaches the CPE data that identifies affected software and versions — to the moment we first ship a check for it. This is the part that is ours, and it is enforced as a build gate: the nightly pipeline runs the measurement with gating enabled, and a breach fails the job.
From NVD publication to the same point. This is what you actually experience, so we publish it — but it includes NVD’s own enrichment latency, which we do not control and cannot beat.
The split is not a convenience. A CVE is not checkable when it is published: until NVD says which software and versions are affected, there is nothing to probe, and our actionability gate correctly refuses to emit a script. Across our own corpus that enrichment takes a median of 68.9 hours — and up to 7 days. A 48-hour target measured from publication is therefore unachievable for the median CVE no matter how fast we work; it would grade us on someone else’s queue. So we gate the clock we own and publish the one you feel.
The clock is recorded once, when a CVE first gets a check, and is deliberately not reset when content is rebuilt. The gate judges the checks a given run actually shipped, rather than a lifetime average — a CVE that was once late stays late permanently, and gating on the lifetime figure could never go green and would create pressure to quietly discard history.
The Numbers
These are measurements, not projections. Where something is an estimate we say so, and we do not quote estimates as though they were counts.
| Figure | Value | What it measures | As at |
|---|---|---|---|
| NVD records traversed | 369,364 | Records seen in the last full-corpus pull | 2026-07-22 |
| NVD records normalised | 349,903 | Records written as structured inputs; 19,461 were skipped as unusable | 2026-07-22 |
| CISA KEV catalogue | 1,631 | Total actively exploited CVEs, all ages | 2026-07-07 |
| KEV entries pre-2020 | 551 (33.8%) | Retained in full — KEV overrides the recency floor | 2026-07-07 |
| Current content pack | 2026.08.01 | Pack identifier audittoolkit-content-2026.08.01 |
2026-08-01 |
| CVEs in the current pack | 20 | Distinct CVEs that passed both the relevance lens and the actionability gate | 2026-08-01 |
| Scripts in the current pack | 117 + 117 | Audit scripts and paired fix scripts; one CVE can yield several per affected platform build | 2026-08-01 |
| Package or registry detection | 18 of 20 | CVEs detected via an OS package or registry probe; the other 2 via command-version | 2026-08-01 |
| High detection confidence | 18 of 20 | Marked high; the remaining 2 are marked inferred and labelled as such in the pack |
2026-08-01 |
| NVD enrichment latency | 68.9 h | Median from publication to the record becoming checkable; range 3.9 h to 168 h. Not ours, but it bounds what any 48-hour publication-based claim could mean | 2026-08-01 |
| Freshness SLA target | 48 h | From checkable-from to shipped, gated in CI. Steady-state performance not yet published — see above | 2026-08-01 |
| Relevance thresholds | 7.0 / 2020 / 0.5 | CVSS floor, publication-year floor, EPSS floor as configured in the orchestrator | 2026-08-01 |
Feed-derived figures are snapshots. KEV is additive and updates several times a week, so the catalogue total will be higher than the figure above by the time you read this. Pack figures describe the named release only.
Legal Position
Content packs produce advisory output. No finding, score, report or generated remediation is guaranteed to be complete, current, or sufficient for any legal, regulatory or contractual purpose. All output must be independently validated by qualified personnel, and tested in a non-production environment, before any operational or remediation action is taken. Vulnerability tooling supplements a security programme; it does not replace qualified security personnel, penetration testing or formal risk assessment.
NVD, CISA KEV and EPSS are third-party sources. AuditToolkit Labs does not warrant the accuracy, completeness or currency of CVE, CVSS, EPSS or KEV data, nor the availability of those services, and is not responsible for outcomes arising from errors, delays or schema changes in them. Where a feed is wrong or incomplete, content derived from it inherits that limitation.
Full terms — including the limitation of liability, indemnity and the allocation of responsibility for acting on output — are set out in the Liability Disclaimer and Indemnity and the applicable product EULA, which govern in the event of any inconsistency with this page. Every generated audit and fix script additionally carries an embedded indemnity block, and its presence is one of the nine validation checks above.
Related
Every pack ships with its signatures, checksums, provenance, validation report and freshness evidence. Recompute any figure on this page from the pack you receive — that is what the evidence is for.