What CISA ICS Advisories Actually Tell You (and What They Don't)

Every week, CISA drops a fresh batch of ICS advisories. They land in inboxes, appear on the CISA website, and get cross-posted across a dozen other platforms. Most OT practitioners I've talked to have a complicated relationship with them: they know they should read them, they feel guilty when they don't, and when they finally do sit down with one, they often finish without knowing what to actually do next.

That's not a laziness problem. It's a structural problem with how the advisories are written. Understanding what's in them, and what's deliberately not in them, is half the battle.

CISA publishes ICS advisories in CSAF 2.0 format (Common Security Advisory Framework), a standardized JSON schema. When you read one on the website, you're looking at a rendered version of that underlying data. Here's what's actually inside:

The basics: Advisory ID, affected vendor, affected product names and firmware versions, CVE IDs, CVSS score and vector, CWE classification, and a link to the vendor's own advisory.

The vulnerability description: A technical explanation of what the vulnerability is, written for someone with a security engineering background. It covers the vulnerability class (buffer overflow, improper authentication, and so on) and what an attacker could theoretically do if they exploited it.

The remediation section: What to do about it. Usually "update to version X.Y" or "apply vendor patch." Sometimes a compensating control if no patch exists yet.

Affected product versions: Which specific firmware and software versions are vulnerable. This is the most immediately useful section for triage. You pull it up, check it against what's running in your environment, and you either have a problem or you don't.

This is where most practitioners get stuck. The advisory tells you what the vulnerability is. It does not tell you:

Whether it's actually exploitable in your environment. A CVSS 9.8 on a Siemens SCALANCE switch means something very different depending on whether that switch sits on an air-gapped OT network or is reachable from your corporate network through a VPN gateway. The advisory has no idea what your network looks like. CVSS doesn't either. It's measuring theoretical severity in a vacuum, not your actual exposure.

Whether anyone is actively exploiting it. A critical CVSS score does not mean anyone out in the world is targeting that vulnerability right now. CISA maintains a separate Known Exploited Vulnerabilities catalog for that. If the CVEs in an advisory aren't in KEV and the EPSS score is low, the theoretical risk and the practical risk are living in completely different zip codes.

What a real attack would actually look like. "Remote code execution" is a vulnerability class, not an attack scenario. What exploitation looks like in practice, what an attacker would need before they even got there, what they could reach afterward, what the operational impact would be on running processes. None of that is in the advisory. That analysis has to come from somewhere else.

How urgent it is relative to everything else on your plate. CISA publishes dozens of advisories every week and they're all formatted identically. A CVSS 9.8 with no known exploitation and a patch that's been available for three months sits right next to a CVSS 7.5 affecting a product that's actively listed in KEV. The scores tell you one thing. The context tells you the opposite. Without a layer of analysis on top, the formatting actively obscures prioritization.

When a new advisory lands, here's the triage sequence that gets you from raw advisory to a decision in minutes:

1. Check the affected products first. Does the vendor and product match anything running in your environment? If it doesn't, you're done in 30 seconds. Move on.

2. Cross-reference the CVEs against KEV. CISA's KEV catalog lives at cisa.gov/known-exploited-vulnerabilities-catalog. If any CVE in the advisory shows up there, it jumps to the front of your queue regardless of what the CVSS score says. Active exploitation changes the calculus completely and immediately.

3. Pull EPSS scores. The Exploit Prediction Scoring System gives each CVE a probability of being exploited in the wild within the next 30 days. It's not infallible, but it's a meaningfully better prioritization signal than CVSS alone. Anything above 10% is worth a closer look. Anything above 50% deserves your attention today, not next sprint.

4. Read the remediation section carefully. Is there a patch? Is it available now? Has it been sitting available for months while deployment got deprioritized? Is there a compensating control while you wait on a vendor fix? This tells you whether you have a concrete action to take or whether you're in a holding pattern.

5. Read the CVSS vector, not just the score. A 9.8 with AV:N/PR:N/UI:N is a fundamentally different animal than a 9.8 with AV:L/PR:H. The score is a headline. The vector is the actual story.

Here's the honest frustration with the current state of ICS advisory consumption: even if you follow the triage sequence above perfectly, you're still doing a lot of manual lifting. You're bouncing between the CISA advisory, the KEV catalog, an EPSS lookup tool, the vendor advisory, and your asset inventory. All to answer a question that should take 60 seconds: does this actually matter to me right now, and what do I do about it?

The advisories are the canonical source of record. The CVE IDs, the affected versions, the vendor attribution: that data lives there and it's authoritative. But the decision layer, the analysis that translates raw advisory data into a prioritized action with OT operational constraints in mind, has to be built on top of it. Most teams are building that layer manually, in spreadsheets, or not building it at all.

That's the gap OTPulse was built to fill: urgency tiers that weight KEV status and EPSS alongside CVSS, plain-English attack path context written for OT environments, and remediation recommendations that account for the reality that you often can't just push a firmware update to a running PLC on a Tuesday afternoon.

Start with the advisories. They're your ground truth for affected versions and CVE IDs. Then use an analysis layer to decide what to do and when. The two together are what actually gets you somewhere.