1,047Findings mapped
61.1%Of the portfolio
Memory-safety defects, injection, path traversal and deserialisation. One control domain carries nearly two-thirds of everything attackers are known to exploit.
TABLEAU / INFORMATION SECURITY RISK
ControlGap.
1,713 actively exploited vulnerabilities, mapped to the ISO/IEC 27001:2022 control whose failure each one represents.
Every entry in CISA's Known Exploited Vulnerabilities catalogue is, trivially, an A.8.8 failure — "management of technical vulnerabilities." Reporting that tells you nothing.
So I assigned each finding a second control: the preventive one whose failure the defect class actually represents. Aggregating on that turns a flat vulnerability list into a view of which control domains keep breaking.
Open the dashboard01 / THE DASHBOARDOpen on Tableau Public ↗
LIVE · TABLEAU PUBLICFour views · click any control to filter the rest
1,713Findings in portfolio
16Control domains touched
360Ransomware-linked
97.4%Mapping coverage
02 / THE PROBLEM
Everything is an
A.8.8 failure.
A security function that maps its findings to ISO 27001 ends up with a column that reads A.8.8 on every row. That is correct and useless. It says vulnerabilities are vulnerabilities.
The interesting question is which preventive control failed upstream. A path-traversal bug is a secure coding failure. A missing authentication check is a secure authentication failure. Incorrect default permissions are a configuration management failure. Assign that second control and the portfolio starts describing where an organisation's control environment is actually weak.
The finding tells you what
broke. The preventive control
tells you why it could.
03 / WHAT THE DATA SHOWSFigures computed directly from the extract of 17 September 2026
Four controls carry
most of the risk.
Of ninety-three Annex A controls, four account for 1,461 of 1,713 findings. Secure coding alone accounts for 1,047 — more than five times the next domain. The long tail is genuinely long: eleven further domains share 207 findings between them.
414Findings mapped
24.2%Of the portfolio
Application security requirements (184), secure authentication (117) and information access restriction (113). Together they still come to under half of secure coding alone.
Counts verified against the source feed. The KEV catalogue covers known exploited vulnerabilities, not all vulnerabilities, and is skewed toward internet-facing enterprise software — it is not a random sample of the defect population.
01The mix is stable —
The mix is stable —
with one exception.
Secure coding holds between 54% and 66% of every year from 2021 to 2026. Whatever is changing in security, the dominance of memory-safety and injection defects is not.
Secure authentication is the one domain with a direction: 17, 14, 15, 19, 20 and then 32 findings, with 2026 covering only nine months. As a share of each year's total that is roughly a tripling. A stable mix with one moving part is a more actionable finding than either a flat table or a noisy one.
02Volume does not predict
Volume does not predict
weaponisation.
Microsoft contributes 388 findings, more than the next three vendors combined. Apple (94) and Google (75) contribute substantial volume with no known ransomware campaign use at all. SonicWall, with 19 findings, carries the highest known-ransomware share in the top sixteen.
Counting findings by vendor mostly measures install base and researcher attention. Counting which findings get weaponised measures something else, and the two rankings disagree.
03Deadlines are short,
Deadlines are short,
and mostly past.
CISA publishes a remediation deadline with every entry, typically three to twenty-one days from the date added. 1,703 of 1,713 findings are past that deadline as of the extract date.
That figure is a property of the catalogue, not a measure of anyone's performance — the feed reaches back to November 2021 and carries no remediation status. It is included because omitting it would be a quieter kind of dishonesty than reporting it with the caveat.
04 / VALIDATING THE MAPPINGRules, then a model, then a human
The mapping is a
judgement call. So it
gets checked.
01
→Rule mapping
185 CWE rules
keyword fallback
02
→Model pass
LLM maps a random
sample, blind
03
→Adjudication
Every row labelled
by hand, blind
04
Routing rule
Auto-accept agreements
review the rest
Rules you can argue with
The CWE-to-control table covers all 185 distinct CWEs present in the feed and lives in source, not in a model. Several assignments are contestable — CWE-693, Protection Mechanism Failure, could reasonably sit under secure architecture or application security requirements. Those calls are visible rather than buried.
Nothing guessed
About 175 entries carry no CWE at all. A keyword pass over the vulnerability description resolves most; 45 findings are recorded as unmapped rather than assigned a plausible-looking control. They appear in the dashboard as their own category.
Label blind or don't bother
The adjudication sheet asks for a human control on every sampled row, not just the ones where the rules and the model disagree. Labelling only the disagreements inflates the score, because the easy cases never get tested.
05 / WHAT THIS DOES NOT SHOW
The caveats are part
of the analysis.
01
There is no remediation status in this data
The KEV feed publishes findings and deadlines. It does not publish whether anyone fixed anything. Every figure here describes the finding portfolio and its SLA posture — never completion. In a real second-line function this inventory would be joined to the organisation's own remediation tracker; that join is the missing half, and it is absent rather than simulated.
02
"Unknown" is not "no"
CISA records ransomware use as Known or Unknown. A vendor showing a zero rate has no known campaign use — which is absence of evidence, not evidence of absence. Reading those zeros as "this vendor's bugs aren't weaponised" would overstate what the field supports.
03
Vendor counts are not a quality ranking
Microsoft leads the catalogue by a wide margin. That reflects install base, attack surface and the volume of researchers looking, at least as much as it reflects code quality. Comparing absolute vendor counts without normalising for deployment is not a comparison the data supports.
04
Mapping 1,713 findings is not security expertise
This project taught me the structure of Annex A and where it is ambiguous. It did not make me an information security practitioner, and the case study does not claim otherwise. What it demonstrates is classification design, honest coverage reporting, and a validation method — which transfer. Domain judgement does not.
A control-failure view
of a vulnerability feed,
and a way to trust it.
Four of ninety-three controls carry 85% of the portfolio — and the classification behind that number is measured, not asserted.
The pipeline is stdlib-only Python, fetches live, and writes Tableau-ready extracts with an integrity check that reconciles every aggregate back to the fact table. The useful output was less the dashboard than the discipline around it: a disclosed coverage gap, a validation harness, and four documented limits on what the data supports.
NEXT ITERATION
Join to NVD for CVSS severity, so the concentration can be weighted by impact rather than count. Normalise vendor counts by a deployment proxy. And widen the validation sample beyond a hundred rows — at that size the confidence interval on the accuracy figures is wider than the differences being compared.
Source: CISA Known Exploited Vulnerabilities Catalog, a public-domain feed maintained by the United States Cybersecurity and Infrastructure Security Agency. Extract of 17 September 2026: 1,713 findings added between 3 November 2021 and 16 September 2026, across 283 vendors and 694 products. Control identifiers and titles are referenced from ISO/IEC 27001:2022 Annex A for classification purposes; the standard itself is copyrighted and is not reproduced here. 2026 covers 1 January to 17 September only, so its counts are partial while its percentages remain comparable.