Why NVD Lies to OT Engineers — And the Tool Built to Fix It
There is a question every OT security engineer has asked at least once, usually at 11pm after a vendor advisory lands in their inbox.
“This CVE is a 10.0. But what does that actually mean for my plant?”
The answer NVD gives you: a wall of text written for a software developer, a CVSS vector string, and a list of affected CPEs. What it does not tell you is whether your Historian server is at risk. Whether your Engineering Workstation just became an attacker’s pivot point into Level 1. Whether you can even patch this without a vendor-approved maintenance window and a two-week change approval process.
The gap between how IT scores vulnerabilities and what OT engineers actually need to know is enormous. And almost no tooling exists to bridge it.
COIT is an attempt to close it.
The Problem in Concrete Terms
Take Log4Shell. CVE-2021-44228. CVSS 10.0 — the maximum score. Every security team in the world got an urgent ticket the week it dropped.
In IT, the response is relatively straightforward: find every Java application, patch Log4j, redeploy. Done.
In OT, the question is completely different. Which of my systems are running Java? Historian? My SCADA middleware? My MES? And if one of those is vulnerable — can I patch it? Can I even take it offline? What compensating controls work in a live operational environment where downtime has a dollar figure attached to it per hour?
NVD will not answer any of those questions. Neither will the CVE description. Neither will most vendor advisories, which are also written for IT audiences.
Now flip it. PrintNightmare. CVE-2021-34527. CVSS 8.8 — serious, but not maximum. In IT, it is a privilege escalation path primarily threatening domain controllers. Patch it, move on.
In OT, SYSTEM-level code execution on an Engineering Workstation is a categorically different threat. An EWS is the machine that programs your PLCs. SYSTEM access on that box is effectively physical access to every controller it manages. An attacker can modify ladder logic, adjust setpoints beyond safe operating limits, suppress SCADA alarms. The real-world severity of PrintNightmare in an OT environment arguably exceeds its CVSS score — but nothing in the NVD entry tells you that.
That asymmetry — CVEs that are less dangerous in OT than their CVSS implies, and CVEs that are more dangerous — is exactly the gap this tool addresses.
What the Tool Does
CVE-to-OT Impact Translator is an open-source Python CLI tool that takes any CVE ID, fetches the raw data from the NVD API, and feeds it to an LLM with a purpose-built OT/ICS analysis prompt. The output is a structured assessment that answers the questions an OT engineer actually needs answered.
For every CVE, it produces:
OT Relevance Score (1–10) — how applicable is this CVE to industrial environments, with a plain-language rationale.
Purdue Model mapping — which levels of the Purdue Reference Model (0 through 4) are affected, and which specific components at each level are at risk. Not “servers” — Historians, EWS, SCADA platforms, safety PLCs.
Per-system operational impact — broken down across plant availability, Safety Instrumented Systems, SCADA/HMI, Historian/DCS, and Engineering Workstations. Each entry starts with a severity indicator (Critical / High / Medium / Low) before the explanation.
OT Severity Rating — an independent severity assessment for the OT context, which may differ significantly from the CVSS base score. The tool explicitly calls out and explains any divergence.
Realistic ICS attack scenario — a 2-3 sentence attacker narrative specific to OT environments, not the generic “remote code execution” boilerplate from NVD.
MITRE ATT&CK for ICS mapping — technique IDs and names from the ICS-specific ATT&CK matrix, with relevance notes for this particular CVE.
IEC 62443 compliance implications — which specific requirements are affected and how, relevant for product security teams and asset owners operating under IEC 62443.
OT-safe mitigations — compensating controls that work in live operational environments, not just “apply the patch immediately.”
Patching caution — the part most IT-focused advisories completely skip. In OT, patching has prerequisites: vendor approval, compatibility testing, maintenance windows, and sometimes the honest answer that no patch path exists at all.
The Architecture
The tool is intentionally simple. Three stages.
Stage 1 — NVD fetch. A clean call to the NVD API v2, pulling description, CVSS metrics, CWEs, and affected product CPEs. No scraping, no third-party aggregators.
Stage 2 — LLM analysis. The fetched data is assembled into a structured prompt and sent to either Anthropic Claude or a local Ollama instance. The system prompt encodes deep OT/ICS context: Purdue model, IEC 62443, MITRE ATT&CK for ICS, industrial protocols, SIS architecture. The output is enforced as structured JSON.
Stage 3 — Rich terminal output. The JSON is rendered into a colour-coded terminal report with panels for each section, plus optional JSON export for integration into other workflows.
CVE ID │ ▼ NVD API v2 │ ▼ LLM (Claude or Ollama) + OT/ICS system prompt │ ▼ Rich terminal output + JSON export
Two Backends: Cloud and Air-Gapped
The tool supports two LLM backends, and the choice matters for OT security practitioners specifically.
Anthropic Claude produces the highest quality output. If you have an API key, this is the default. For occasional use — running a few CVEs after a vendor advisory — the cost is negligible, around $0.01–0.03 per CVE.
Ollama runs entirely locally. Nothing leaves your machine or your network. This is not just a convenience feature. In OT security assessments, sending CVE analysis requests to external cloud APIs may raise legitimate concerns: NDAs with asset owners, client data handling agreements, or simply the security posture of the environment you are assessing. The air-gapped mode removes those concerns entirely.
# Cloud mode
python3 coit.py CVE-2021-44228
# Fully offline mode — nothing leaves your network
python3 coit.py CVE-2021-44228 --backend ollamaFor Ollama, mistral is the recommended model — it has the best JSON instruction-following reliability of the commonly available models, which matters because the entire output depends on well-formed structured JSON.
Three CVEs That Tell the Story
The clearest way to demonstrate what this tool does differently is to run three CVEs and look at where the OT severity diverges from the CVSS score.
Log4Shell (CVE-2021-44228) — CVSS 10.0 → OT High
The most hyped CVE in recent memory is not a Critical in OT — if your DMZ egress filtering is correctly configured. The direct blast radius is Level 3 systems: Historians, MES, Java-based SCADA middleware. Getting from there to Level 0/1 requires multi-step lateral movement. If your Purdue zone segmentation is enforced and outbound JNDI callbacks are blocked at the DMZ, Log4Shell stays contained.
The tool surfaces this explicitly. Most advisories do not.
PrintNightmare (CVE-2021-34527) — CVSS 8.8 → OT Critical
This is the more interesting case. PrintNightmare is upgraded in OT context, not downgraded. The assessment explains exactly why: SYSTEM-level access on an Engineering Workstation is not a privilege escalation story in OT — it is a story about someone gaining the ability to modify PLC logic, adjust physical process parameters, and suppress operator alarms. The CVSS score was calibrated for IT. In OT, the consequence category is entirely different.
libcurl SOCKS5 Heap Overflow (CVE-2023-38545) — CVSS 9.8 → OT High
The patching caution section here is unlike anything you will find in a standard advisory. libcurl is embedded in the firmware of IIoT gateways, field devices, and protocol converters. The asset owner has no direct patch path — firmware updates depend entirely on OT vendors, many of whom will never release one for legacy devices. The mitigations therefore focus entirely on compensating network controls: blocking SOCKS5 traffic at OT zone firewalls, network isolation, anomalous outbound connection monitoring. The tool generates this guidance automatically, calibrated to the OT context.
Getting Started
# Install dependencies
pip3 install rich requests anthropic # anthropic only needed for cloud mode
# For offline mode: install Ollama from https://ollama.ai, then:
ollama pull mistral
# Run
python3 coit.py CVE-2021-34527
python3 coit.py CVE-2021-44228 --backend ollama
python3 coit.py CVE-2023-38545 --json report.jsonThe tool is available on GitHub. Start with PrintNightmare (CVE-2021-34527) — it produces the most striking output, and it is the clearest illustration of why OT severity and CVSS severity are not the same number.
What This Is Not
This tool does not replace a qualified OT security assessment. The LLM output is a starting point for analysis, not a final word on risk. CVE impact in a specific OT environment depends on asset inventory, network architecture, zone segmentation, and operational context that no automated tool has access to.
What it does replace is the 45 minutes an engineer currently spends manually cross-referencing a CVE description against Purdue model documentation, ATT&CK for ICS, and IEC 62443 requirements to produce an assessment that should take five minutes. It replaces the IT-focused advisory that gets forwarded to the OT team with a shrug and a “figure out if this applies to you.”
It makes the right questions easier to ask. The answers still require a human.
A Note on the Gap This Fills
There are excellent vulnerability databases, threat modelling frameworks. There are excellent OT security standards.
Almost nothing connects them automatically, in plain language, from the perspective of an engineer standing in front of a control system trying to make a risk decision before the next maintenance window.
That is the gap. This is one attempt to close it.
The tool is open source. Use it, break it, improve it. If COIT produces an assessment you think is wrong for a specific CVE, open an issue — these edge cases directly improve the prompt engineering.
Github Repo :- https://github.com/iosec-shekhar/COIT (Please Star if you like it)