How vulnerability management actually works.

01What is a vulnerability, in plain English

A vulnerability is a flaw in software or hardware that can be abused — most often, a way for an attacker to do something the system's designers didn't intend. Read a file you shouldn't be able to read. Run a command on a server you don't own. Reset someone else's password.

Every piece of code in the world has them. They come from many places: a programmer forgot to check whether a string is short enough before copying it into a buffer; a configuration option was left enabled when it should have been off; a library you depend on has a flaw that quietly poisons every product that uses it. The list never ends.

What changed in the last two years is not that bugs got worse — it's that finding them got dramatically cheaper. We'll come back to that.

02What is a CVE

When somebody finds a vulnerability that the world should know about, the convention is to give it a globally unique ID and publish a description. The system that does this is called the CVE program — Common Vulnerabilities and Exposures — and the IDs look like this:

CVE IDs are issued by MITRE — a US federally-funded research nonprofit — and a handful of authorized partners (Microsoft, Cisco, Google, Red Hat, etc., can each issue IDs for flaws in their own products). The full database where every CVE eventually gets a structured entry with severity scores and references is the National Vulnerability Database (NVD), maintained by NIST.

Two scores you'll see attached to every CVE:

You want both numbers because they answer different questions. A 10.0 CVSS with EPSS 0.01 is a theoretical disaster nobody's actually exploiting. A 7.5 CVSS with EPSS 0.91 is a moderate flaw being weaponized in the wild today. The second is what wakes people up.

03What is CISA KEV

The US Cybersecurity & Infrastructure Security Agency (CISA) maintains a curated list called the Known Exploited Vulnerabilities catalog — KEV for short. It is the single most important threat-intel feed in the US-government cybersecurity ecosystem.

The KEV catalog is short (around 1,600 entries as of mid-2026). It is hand-curated. Entry on the list is not based on severity; it's based on evidence that the flaw is being actively exploited in the real world today. If something hits KEV, you know — with high confidence — that attackers have working exploits and are using them.

Federal civilian agencies are legally required to remediate KEV-listed CVEs within tight deadlines (often 14–21 days). Most large private-sector enterprises mirror that policy voluntarily. Cyber-insurance underwriters increasingly check it during renewal.

Mythal pulls the live KEV catalog directly from CISA on every sync, matches it against the customer's asset inventory by vendor and product, and routes the matches through the agent pipeline. That's what the Live Feeds screen in the console is doing.

04Who's involved — the cast of characters

The vulnerability ecosystem has six kinds of actors. It helps to know who plays which part before you watch the play.

05A bug's lifecycle, end to end

Here's the typical path a single vulnerability takes from discovery to "patched everywhere":

Today, in a typical large enterprise, this entire lifecycle takes about 22 days from detection to verified fix. That number is the Mean Time to Remediate (MTR) — the single most important operational metric in this space, and the headline KPI on Mythal's Command Center.

06Who actually provides the fix

The vendor whose product contains the flaw. Always. Without exception.

Mythal does not invent patches. Neither does any other vulnerability platform. What an organization does — and what Mythal accelerates — is:

1. Locate the vendor's published fix (a Microsoft KB article, a Cisco IOS-XE software bundle, a Siemens firmware update, an Apache version bump).
2. Validate that the fix is the right one and is reliable. Vendor-issued? Tested by enough other deployments? Reversible? Mythal's Patch Hunter agent assigns a PatchReliabilityScore for this.
3. Schedule the deployment for the right time and the right cohort. Mythal's Change Risk agent recommends the window.
4. Apply the patch using the tools the organization already operates — SCCM for Windows, Ansible for Linux, Panorama for Palo Alto firewalls, Tenable OT Security for industrial firmware. Mythal's Executor agent drives these.
5. Verify the patch landed and nothing broke. Mythal's Verifier agent rescans and runs health probes.
6. Record the evidence for the next audit. Mythal's Compliance Reporter agent does this automatically.

The vendor builds the fix. The organization deploys it. Mythal coordinates the deployment — fast, gated, reversible, auditable.

07Inside the organization — who does what

At a large enterprise like a Class I freight railroad, the work is spread across multiple teams. Knowing which person worries about which step explains a lot about why the process is slow.

08Why the current approach is breaking

Five reasons the existing system can't keep up. Each one compounds the others.

Reason 1 — Volume

The NVD publishes 200+ CVEs every week. A single Microsoft Patch Tuesday in April 2026 addressed 163 CVEs in one day. The volume has roughly tripled in the last five years while sec-ops headcount has been flat.

Reason 2 — Velocity

The window between a vendor patch dropping and a working public exploit existing has collapsed from weeks to days, sometimes hours. AI tools can now diff a patched binary against an unpatched one and reconstruct the underlying vulnerability automatically. That's the Mythos thesis — we'll cover it next.

Reason 3 — Scarce windows on OT

You cannot patch a substation RTU during business hours. You cannot reboot a Positive Train Control wayside cabinet without coordinating with the dispatch team. OT maintenance windows are typically twice a year, four hours long, scheduled months in advance. There is no "just push the patch tonight" option.

Reason 4 — Audit pressure

TSA SD 1580-21-01, CISA Binding Operational Directives, NIST 800-82r3, IEC 62443 — every regulated organization has to prove they followed the rules. The evidence-gathering itself is a half-time job for somebody.

Reason 5 — The blast radius is operational

A misapplied patch on a corporate file server is an inconvenience. A misapplied firmware update on a wayside detector can derail a train. The bigger the consequence of a wrong move, the slower the process has to be — and the more humans get involved in every decision. It compounds.

09The Mythos thesis — what changed in the last 24 months

Until very recently, finding a new vulnerability was hard, manual work. A skilled researcher would spend weeks reverse-engineering a vendor's firmware, looking for one specific class of bug. Patches dropped at a manageable cadence. Companies had weeks to react.

Then a wave of AI tools — starting with Anthropic's Claude Mythos generation and contemporary reasoning models from OpenAI and others — made vulnerability discovery dramatically cheaper. These tools can:

• Diff a patched binary against an unpatched version and automatically reconstruct what the patch was fixing — turning hours of human reverse-engineering into minutes of automated analysis.
• Audit large open-source codebases at scale, flagging exploitable patterns humans would take months to find.
• Generate proof-of-concept exploits from CVE descriptions, dropping the skill floor for attackers dramatically.

The effect is two velocities changing dramatically while a third stays flat.

10Where Mythal fits

Mythal is the response layer that goes machine-speed too. Without losing the safety properties — rollback, audit, dual approval — that the human layer enforced.

What it does in one sentence

Mythal is twelve coordinated AI agents that sit above your existing scanners and patch tools, take a CVE from detection to verified fix while a deterministic policy gate prevents anything dangerous, and generate auditor-grade evidence as a byproduct.

What each agent does, plainly

• Supervisor — the orchestrator. Drives the per-finding state machine.
• Scanner Liaison — reads from every scanner you own (Qualys, Tenable, Wiz, Claroty, etc.) and normalizes the output into one schema.
• Threat Intel — adds context. CISA KEV listing? EPSS score? Ransomware actor known to use it?
• Patch Hunter — locates the vendor's fix and scores it for reliability.
• Impact Analyst — joins to the CMDB. How important is this asset? What depends on it?
• Change Risk — predicts whether the patch is likely to break something based on historical data.
• OT Safety Officer — for OT assets, vetoes direct patching by default. Proposes compensating controls (firewall ACL changes, IPS signatures) instead. Schedules firmware updates only inside planned windows.
• Remediation Planner — assembles the concrete plan with rollback.
• Executor — drives the patch tools your team already operates (SCCM, Ansible, Tanium, Panorama, vendor-native OT tools).
• Verifier — rescans, runs health probes, closes the loop or rolls back.
• Compliance Reporter — emits audit evidence tagged to TSA, NIST, IEC controls.
• Inventory Insights — the proactive one. Sweeps the estate continuously and surfaces risk before any CVE drops (EOL software, version sprawl, CCS without documented owner, identity hygiene gaps).

The policy gate

Between every agent decision and any side effect that changes a customer asset sits a deterministic policy engine with seven default rules. The agents propose. The policy gate disposes. Auto-apply / single-approval / dual-approval / deny — every decision routed by code, not by judgment. That separation is what lets you put an LLM in the pipeline without making it autonomous.

11What a real Patch Tuesday looks like with Mythal

Concrete walkthrough — what happens at a Class I rail company when a critical CVE drops at 06:00 on Patch Tuesday and Mythal is running.

1. 06:00:00 — Microsoft publishes a critical CVE affecting Exchange Server. Within seconds, the local Qualys scanner picks it up and emits a finding on corp-exchange-01.meridian.rail.
2. 06:00:02 — Mythal's Scanner Liaison normalizes the finding. Threat Intel checks CISA KEV (not yet, but EPSS already 0.71). Patch Hunter locates Microsoft KB-5052XXX with reliability 0.94.
3. 06:00:06 — Impact Analyst flags the asset as serving 4,000 internal users with regulated data. Change Risk scores historical failure for Exchange patches at 0.04 (low). Canary peer available.
4. 06:00:10 — Remediation Planner builds a six-step plan with tested rollback. Policy Gate evaluates rule SG-POL-004 → single security approval required (it's an IT asset, not OT/CCS).
5. 06:15:23 — Security on-call sees the alert, reviews the trace in the Mythal console (single page — they read the reasoning, not separate ticket fields), clicks approve.
6. 06:18:45 — Executor pushes the KB via SCCM. Verifier confirms: rescan clean, health probe HTTP 200, exploit retest blocked.
7. 06:18:46 — Compliance Reporter emits three evidence units (NIST CSF RS.MI-01, TSA SD §3.D, IEC 62443-2-3). State CLOSED.

Total elapsed: 18 minutes 46 seconds. Baseline at Class I scale: 22 days. Same patch. Same vendor. Same auditor expectations. Same safety guarantees.

The OT-path version

If the asset had been a Siemens RUGGEDCOM RTU at substation 14 instead of an Exchange server, step 6 would have gone differently. The OT Safety Officer agent would have vetoed direct patching by default. Instead it would propose three compensating controls — industrial firewall ACL tightening, an IPS signature deployed as a virtual patch, monitored isolation — and schedule the actual firmware update into the next planned OT maintenance window with dual approval (Security + OT Operations) and a tested rollback as preconditions.

That's not an exception path. It's the path. That single design choice is what wins OT operators.

12What to read next

Now that the concepts are loaded, the rest of the materials in this portal will make sense in their proper context.

• User Guide — every screen of the console explained from the operator's perspective.
• Primer for AI engineers — deeper technical onboarding if you're the one building or extending Mythal.
• Mythal positioning document — how Mythal answers a specific real-world buyer's inquiry, with the four-step workflow mapping.
• The Brief — executive editorial deck for VPs and directors.
• The Manual — technical field manual for engineering leadership.
• Glossary — every term, A–Z, in one place.

Or open the live console at localhost:3090 and click ⚡ Sync CISA KEV → agents. Watching the agent activity stream fill in real time as real CVE IDs from CISA's actual catalog get matched against the inventory and driven through the twelve agents is the moment everything in this document becomes concrete.