DEV Community: Adam Lewandowski

How to Read a Cisco Security Advisory: Fixed Releases, the Gold Star, and the FMC/FTD Compatibility Trap

Adam Lewandowski — Fri, 31 Jul 2026 00:26:37 +0000

A Cisco security advisory lands in your inbox. Somewhere between "we should look at this" and an approved change request, a surprising number of teams go wrong: they patch to the wrong version, they schedule the firewall upgrade before the manager upgrade, or they burn a maintenance window on a Medium while an actively exploited Critical waits in the queue.

None of that comes from laziness. A Cisco PSIRT advisory is a dense document with its own vocabulary, and the pieces you need for a change request are spread across three places: the advisory itself, the Software Download portal, and the compatibility guide for your product line. This article walks through how to read all three, using Cisco Secure Firewall (FTD/FMC), ASA, and ISE as the working examples, and ends with a reusable checklist.

The anatomy of a Cisco PSIRT advisory

Every advisory published by Cisco's Product Security Incident Response Team (PSIRT) follows the same structure. The sections that matter for a change request:

Security Impact Rating (SIR) vs CVSS. Cisco publishes both a CVSS base score and its own four-level Security Impact Rating: Critical, High, Medium, Low. The SIR usually tracks the CVSS qualitative bands, but not always. Per Cisco's own terminology documentation, PSIRT will apply a SIR that is higher or lower than the CVSS score would indicate when ease of exploitation or how widely the technology is deployed warrants it. Practical takeaway: read both, but treat the SIR as Cisco's editorial judgment on top of the raw score. Note also that Low-SIR bugs usually skip standalone advisories entirely and live in release note enclosures in the Bug Search Tool.

Affected and not-affected products. Cisco is unusually explicit here, and the "not affected" list saves real work. Advisories name specific products and, critically, specific release trains. A bug in the FMC web interface may not touch FTD or ASA at all. Confirm your exact product before you open a ticket.

Fixed releases. This is the table most people jump to, and the one most people misread. More on it in the next section.

Workarounds and mitigations. Cisco draws a hard line: a workaround only counts as a workaround if it can be applied locally on the vulnerable device and eliminates the vulnerability. Anything less is a mitigation. Either way, Cisco's stated position is that software updates are the preferred resolution, and a workaround that gets accidentally removed during later changes silently reopens the attack surface. If the advisory says "there are no workarounds that address this vulnerability" (a common sentence on the serious ones), your only real option is the upgrade.

Exploitation status. Advisories get updated after publication. The line "Cisco PSIRT is aware of attempted or successful exploitation" can appear two weeks after initial disclosure. Check the current version of the advisory, not the copy someone pasted into a ticket on day one.

First fixed release is not the release you should install

The fixed software section of an advisory answers one narrow question: for each affected release train, what is the earliest build that contains the fix? That is the "first fixed release."

It does not answer the question you are actually asking, which is "what should I upgrade to?" Those are different questions for three reasons:

First fixed is per-train. A vulnerability affecting 7.0.x, 7.2.x, 7.4.x, and 7.6.x will have a separate first fixed release for each train. The advisory will not tell you whether staying on your old train is wise; it only tells you the minimum build on that train that closes this one hole.
First fixed closes one advisory. The first fixed release for today's advisory may still be exposed to last month's advisory, or next month's. This is why Cisco pushes the Software Checker tool (on sec.cloudapps.cisco.com), which lets you enter a product and release and get back every advisory that applies, with the release that clears all of them. Run the Checker, not just the single advisory table.
Recommended releases are chosen for stability, not just security. Cisco separately maintains suggested or recommended releases per product, selected for software quality, stability, and longevity across the whole install base. The first fixed release for an advisory might be a build that is three days old; the suggested release is one Cisco has watched behave in production.

The sane pattern for a change request: use the advisory and Software Checker to establish the floor (any build below this is unacceptable), then pick the actual target from the suggested release, as long as it is at or above that floor. When a fresh Critical drops, the suggested release usually catches up within days because Cisco knows everyone is about to upgrade.

What the gold star actually means, and what it does not

On the Cisco Software Download portal, the suggested release for a product is marked with a gold star next to the version number. For Secure Firewall, the star also surfaces in the compatibility guide, which names a current suggested release for FTD and for FMC (at the time of writing, 7.6.4 for threat defense and 7.6.5 for the management center).

The star is genuinely useful. It is Cisco's public answer to "which build would you run?" and it reflects field experience, not just recency. But it has three limits worth knowing before you build process around it:

It is login-gated. Browsing downloads for some product lines requires a Cisco.com account with entitlement (ASA images are a classic example). Tooling that scrapes public pages may never see the star at all.
It moves without notice. There is no RSS feed or changelog for "the star moved from 7.6.3 to 7.6.4." If your baseline document says "we standardize on the suggested release," someone has to actually check the portal on a cadence, or you are standardizing on a memory.
It is one star per product, not per constraint. The starred release does not know about your hardware, your managed-device versions, or a feature you depend on that changed behavior. It is an input to your decision, not the decision.

Treat the gold star as a strong default and a tiebreaker, and record the date you observed it in the change request, because six months later nobody will be able to reconstruct why 7.6.4 was chosen.

The FTD/FMC compatibility trap

Here is the rule that turns a one-device change request into a two-device project, straight from Cisco's upgrade documentation: a customer-deployed management center must run the same or a newer version as its managed devices. You cannot upgrade a device past its FMC, and this applies even to maintenance (third-digit) releases. The FMC gets upgraded first, always.

The same rule bites during onboarding: try to register an FTD running a newer version than the FMC and registration fails outright. Cisco has a dedicated troubleshooting document just for that error.

Why this matters for advisory response:

An FTD advisory is implicitly an FMC change too. If the first fixed FTD release is newer than your FMC version, the real change request is "upgrade FMC, then upgrade FTD," with two maintenance windows, two rollback plans, and a compatibility check between the new pair.
An FMC advisory can often ship alone. Because FMC is allowed to run ahead of its devices, an FMC-only fix (patch the manager, leave the sensors) is usually the fastest Cisco firewall change you can make. This is worth internalizing, because some of the worst recent Cisco vulnerabilities have been FMC-side.
The compatibility guide is a first-class source. Before any version lands in a change request, check the Secure Firewall management center compatibility guide for the exact FMC/FTD pairing. Not every FMC version can manage every FTD version, and hardware support gets dropped at major releases. "The advisory says 7.6.x is fixed" is not the same as "my FMC 7.2 estate can manage 7.6.x devices."

ISE is different: patch trains, not point releases

ISE does not follow the FTD model. An ISE version (3.3, 3.4) receives numbered cumulative patches, and Cisco's ISE documentation is explicit that patches are cumulative: installing patch 5 gives you everything in patches 1 through 4. So an ISE advisory's fixed release column typically reads like "3.3 Patch 6" or "3.4 Patch 3," and the change request is a patch install, not a version upgrade, which is a much smaller change.

Two ISE-specific wrinkles:

Hot patches exist. For urgent issues, Cisco has shipped targeted hot patches ahead of the next cumulative patch. The 2025 ISE unauthenticated RCE cluster (CVE-2025-20281, CVE-2025-20282, CVE-2025-20337) is a real example: Cisco published hot patch files tied to a specific bug ID for 3.3 and 3.4 while the cumulative patches caught up. A hot patch is a bridge, not a destination; plan the cumulative patch behind it.
Patch level is part of your version. "We run ISE 3.4" is not enough information to evaluate an advisory. Track the patch level as inventory data, or every ISE advisory triage starts with logging into the admin portal to find out.

A worked example: the March 2026 FMC pair

Here is how this played out on a real advisory set. On March 4, 2026, Cisco disclosed two Critical vulnerabilities in Secure Firewall Management Center: CVE-2026-20079, an authentication bypass rooted in a boot-time process misconfiguration that let crafted HTTP requests execute scripts as root, and CVE-2026-20131, an unauthenticated remote code execution flaw from insecure Java deserialization in the web management interface. Both scored CVSS 10.0. Both carried the sentence you never want to read: no workarounds.

Reading them with the framework above:

Affected products: on-premises FMC only. FTD, ASA, and cloud-delivered firewall management were not affected, and Cisco patched its own cloud environments with no customer action needed. Anyone who burned time assessing their ASA fleet skipped the "not affected" list.
Fixed releases: each FMC train got its own first fixed release, and the two CVEs' fixed lists were not identical. That is exactly the situation the Software Checker exists for: check both CVEs at once and get one release that clears both.
Compatibility: because FMC may run ahead of managed FTDs, this was patchable as a manager-only change. Teams that knew the compatibility rule shipped it fast; teams that assumed "firewall upgrade" scoped it like a fleet project and lost weeks.
Exploitation: on March 18, Cisco updated the advisory to note active exploitation, and on March 19, CISA added CVE-2026-20131 to the Known Exploited Vulnerabilities catalog with a federal remediation deadline attached. An advisory that was "urgent" on March 4 became "this weekend, emergency change" two weeks later. Only teams re-checking the advisory and KEV caught the escalation.

The checklist: advisory to change request

Check CISA KEV first. If the CVE is listed, exploitation is confirmed and your timeline is now measured in days. Note the KEV due date in the ticket.
Read the advisory's affected products section against your actual inventory, including the not-affected list. Stop here if you are not affected, and write down why.
Record the SIR, the CVSS score, and the exploitation status line, with the date you checked, since all three can change after publication.
Check for workarounds. If one exists, note it as a bridge option only; if the advisory says none exist, say so explicitly in the change request to justify urgency.
Run the Cisco Software Checker for your product and current release to get the release that clears all open advisories, not just this one. That is your floor.
Look up the suggested (gold star) release on the download portal or compatibility guide. If it meets the floor, it is your target. Record the star position and date.
Firewall estates: verify the FMC/FTD pairing in the compatibility guide. If a device fix requires a newer FMC, the FMC upgrade is a prerequisite task in the same change request. FMC upgrades first, always.
ISE estates: confirm the required patch level, remember patches are cumulative, and treat any hot patch as temporary with a follow-up task for the cumulative patch.
Write the change request with the floor, the target, the source links, and the observed dates, so the decision is reconstructible at audit time.
Set a re-check reminder for seven days. Advisories get updated, KEV grows, and stars move.

Closing thought

Cisco gives you everything you need: a structured advisory, a checker tool, a curated release recommendation, and detailed compatibility documentation. The failure mode is treating the advisory as the whole story. It is one of four documents, and the change request writes itself once you read all four in the right order: KEV, advisory, Software Checker, compatibility guide. Teams that internalize that order patch faster, and they never again schedule an FTD upgrade their FMC cannot manage.

About the author: Adam Lewandowski is a network and security engineer (CompTIA Security+, CCNA, VMware VCP-DCV) working with Cisco FTD/FMC/ISE, Windows Server/MECM, and VMware environments. Connect on LinkedIn.

I write The Patch Window, a free 5-minute weekly brief on which enterprise patches can't wait - Cisco, Windows Server, VMware. Subscribe: https://the-patch-window.beehiiv.com

CISA KEV catalog: a working sysadmin's guide to actually using it

Adam Lewandowski — Fri, 31 Jul 2026 00:24:51 +0000

Most enterprise teams know the CISA Known Exploited Vulnerabilities catalog the same way they know the weather: a headline scrolls past ("CISA adds three vulnerabilities to KEV catalog"), someone forwards it, and everyone nods. That is a waste of the single most operationally useful list in vulnerability management. The KEV is small, machine-readable, updated near-daily, and every entry on it has one property your scanner output cannot give you: a real attacker has already used it against a real network.

This is a guide to the catalog itself: what it promises, what it doesn't, how the feeds are structured, how to map entries to your own estate without fooling yourself, and how to combine it with EPSS and vendor advisories into a defensible patch-ordering rule. Everything here is verified against the live feed and CISA's own pages as of late July 2026.

What the KEV is, and what it is not

CISA describes the KEV as the authoritative source of vulnerabilities that have been exploited in the wild. Entry is gated by three criteria, all of which must hold:

The vulnerability has an assigned CVE ID.
There is reliable evidence of active exploitation in the wild.
There is a clear remediation action, such as a vendor-provided update.

Read those criteria as exclusions and the catalog's real shape appears. No CVE assigned yet? Not in the KEV, even if exploitation is rampant. Exploitation reported but CISA's evidence bar not met? Not in the KEV. Actively exploited but no fix or mitigation exists? Not in the KEV. The catalog is a curated floor, not a census. As of the 2026.07.29 release the feed contains 1,656 entries, against an ecosystem publishing tens of thousands of CVEs per year. Absence from the KEV is not evidence of safety; presence is close to proof of danger. That asymmetry is the whole point, and it is why the correct reading of the list is "everything on here is urgent" rather than "everything urgent is on here."

The distribution is also worth knowing before you build anything on top of it. Microsoft dominates with 382 entries, followed by Cisco (95), Apple (93), Adobe (80), Google (72), then the appliance vendors that have defined the last few years of mass exploitation: Ivanti (35), Fortinet (29). 332 entries, about one in five, carry a known-ransomware-campaign flag. If you run a typical enterprise stack, a large slice of this catalog is aimed directly at you.

The due dates: BOD 22-01 is gone, and its replacement raised the stakes

The KEV was created by Binding Operational Directive 22-01 in November 2021, which required US federal civilian agencies to remediate each listed CVE by a per-entry due date. If your mental model of KEV deadlines still comes from that era ("two or three weeks for new entries"), it is out of date. On June 10, 2026, CISA issued BOD 26-04: Prioritizing Security Updates Based on Risk, which supersedes and revokes BOD 22-01 outright. The KEV catalog itself continues, with the same inclusion criteria, but due dates are now set by a four-variable risk model: public exposure of the asset, KEV status, exploit automatability, and technical impact (partial versus total control). Remediation timelines run from three calendar days, with mandatory forensic triage for the worst combinations, down to fix-on-next-upgrade for vulnerabilities that trip none of the variables. CISA's Vulnrichment program publishes answers for three of the four variables for every CVE; only asset exposure is yours to determine.

You can see the regime change directly in the feed. Of the 39 entries added since June 10, 34 carry a three-day deadline and the rest fourteen days. Under the old directive, three weeks was routine. A concrete example from the day I pulled the data: CVE-2026-20316, a hard-coded password vulnerability in Cisco Secure Firewall Management Center, was added on 2026-07-29 with a due date of 2026-08-01. Three days, for an FMC bug, over a weekend.

Why should you care if you are not a federal agency? Two reasons. First, the due dates are free triage: they encode CISA's judgment about exploitation velocity and impact, computed by people with incident data you will never see. When a directive built on that data says "three days," treating your own internet-facing FMC as a 30-day ticket is a choice you should at least make consciously. Second, the KEV increasingly shows up in places with teeth: cyber-insurance questionnaires, audit frameworks, and customer security reviews commonly ask how you track and remediate KEV-listed vulnerabilities. "We monitor the catalog and apply the federal timelines to exposed assets" is a clean, defensible answer that costs very little to make true.

The feeds: skip the webpage, consume the data

The browsable catalog page is fine for humans, but the operational interfaces are the feeds, all free and unauthenticated:

JSON: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
CSV: https://www.cisa.gov/sites/default/files/csv/known_exploited_vulnerabilities.csv
JSON schema: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities_schema.json

The JSON document has a small envelope (title, catalogVersion, dateReleased, count) and a vulnerabilities array. Each entry carries: cveID, vendorProject, product, vulnerabilityName, dateAdded, shortDescription, requiredAction, dueDate, knownRansomwareCampaignUse (the string Known or Unknown), notes (semicolon-separated advisory URLs), and cwes.

Here is a minimal watcher in plain Node.js (18 or later, no dependencies) that pulls the feed and prints recent additions matching your vendors. I ran this exact script against the live feed while writing this article:

// kev-watch.mjs - Node 18+ (native fetch, top-level await)
const FEED = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json";
const KEYWORDS = ["cisco", "vmware", "broadcom", "windows server", "solarwinds"];
const DAYS_BACK = 30;

const res = await fetch(FEED);
if (!res.ok) throw new Error(`KEV feed returned HTTP ${res.status}`);
const { catalogVersion, count, vulnerabilities } = await res.json();

const cutoff = new Date(Date.now() - DAYS_BACK * 86_400_000);
const matches = vulnerabilities.filter((v) => {
  const haystack = `${v.vendorProject} ${v.product}`.toLowerCase();
  const recent = new Date(v.dateAdded) >= cutoff;
  return recent && KEYWORDS.some((k) => haystack.includes(k));
});

console.log(`KEV ${catalogVersion} (${count} total entries)`);
console.log(`${matches.length} matches added in the last ${DAYS_BACK} days:\n`);

for (const v of matches.sort((a, b) => a.dueDate.localeCompare(b.dueDate))) {
  const flag = v.knownRansomwareCampaignUse === "Known" ? "  << RANSOMWARE" : "";
  console.log(`due ${v.dueDate}  ${v.cveID}  ${v.vendorProject}: ${v.product}${flag}`);
}

Real output from 2026-07-29:

KEV 2026.07.29 (1656 total entries)
2 matches added in the last 30 days:

due 2026-07-16  CVE-2008-4128  Cisco: IOS
due 2026-08-01  CVE-2026-20316  Cisco: Secure Firewall Management Center (FMC)

Schedule that however you like and pipe it to email or chat. If you want the fuller version of this idea, a daily brief that also folds in Microsoft's MSRC feed and checks your firmware versions for compliance drift, I walked through that build in a separate article: Build a 5-minute morning security brief. This piece stays on the catalog itself.

Mapping KEV to your estate: the false-negative trap

Keyword matching on vendorProject and product is where every homegrown KEV consumer starts, and where most of them quietly rot. The fields are human-written strings, not a controlled vocabulary, and they will betray a naive filter in at least three ways.

First, vendors change names. VMware entries added before the Broadcom acquisition sit under vendorProject: "VMware"; newer ones, including vCenter Server and Aria Operations entries, sit under "Broadcom". A filter that matches only vmware silently misses new vCenter KEVs. The same class of problem applies to renamed products: the Cisco FMC entry above helpfully notes "formerly known as Firepower Management Center" in its description, but nothing forces future entries to do that.

Second, vague product strings. Entries like Zyxel's product: "Multiple Products" match no sensible product keyword. If you filter on product names alone, these vanish.

Third, your inventory lies. Matching the feed is the easy half; the hard half is knowing that the thing in the entry actually exists on your network, including the appliance someone racked in 2019 that never made it into the CMDB.

Practical rules that keep the approach honest: match on the concatenation of vendor and product, not product alone; include acquirer names alongside legacy vendor names (VMware and Broadcom, SolarWinds and N-able, and so on); treat your keyword list as config that gets reviewed when the catalog surprises you; and once a week, eyeball the full list of new additions regardless of matches, which at current volume (172 additions so far in 2026) is a two-minute skim. The keyword filter is a tripwire, not a coverage guarantee. If you need a guarantee, that is what a scanner with CPE-based matching is for, and even those disagree with each other.

A ranking rule: KEV, then EPSS, then the vendor advisory

The KEV answers exactly one question: is this being exploited? It says nothing about how likely exploitation of everything else is, and nothing about how bad exploitation would be for you. So combine three signals, in this order:

KEV membership is a gate, not a score. Anything in the KEV that exists in your estate goes to the front of the queue, full stop. Within that set, order by dueDate and put knownRansomwareCampaignUse: "Known" entries first. Exposure decides the calendar: for internet-facing assets, treat CISA's due date as your due date; for internal-only assets, the next scheduled window is usually defensible. That is exactly the spirit of BOD 26-04's exposure variable.
EPSS ranks everything the KEV is silent on. The Exploit Prediction Scoring System from FIRST estimates the probability a CVE will be exploited in the next 30 days, and the free API is one GET request per CVE. It complements the KEV precisely because it is predictive where the KEV is confirmatory. Know its blind spot at the seam, though: brand-new KEV entries often have no meaningful EPSS score yet. On the day CVE-2026-20316 hit the catalog, EPSS had no score for it at all, while the 2008-vintage Cisco IOS entry scored 0.33, higher than 98 percent of all CVEs. KEV first, EPSS second is not just a slogan; the ordering is load-bearing.
The vendor advisory decides what you actually do. Every KEV entry links its advisory in the notes field. The advisory tells you the fixed version, whether a workaround exists, and whether your specific configuration is affected. In a Cisco shop, the KEV tells you FMC is under active attack; only the Cisco advisory tells you whether your release train has a fixed build and what the mitigation is until your window opens.

As a one-line policy: KEV match on an exposed asset means patch now on CISA's clock; KEV match internal-only means next window, ransomware-flagged first; no KEV match means rank by EPSS and severity and handle in normal cadence, with the vendor advisory as the source of truth for the fix itself.

Honest limitations

The KEV is the best free signal in vulnerability management, and it will still fail you in specific, predictable ways.

It lags by design. Evidence of in-the-wild exploitation has to exist and reach CISA's bar before an entry appears. For a zero-day being exploited before the patch exists, criterion three blocks listing until a fix ships, and by the time the entry lands you may be days behind attackers. The KEV can never be your early-warning system for your crown-jewel products; vendor PSIRT feeds and emergency advisories own that window. It also lags in the other direction: that Cisco IOS entry added in July 2026 is CVE-2008-4128, an eighteen-year-old vulnerability. Exploitation evidence arrives when it arrives.

It carries no severity or applicability context. Entries are not scored, and the due date reflects CISA's risk model for federal networks, not your exposure. Two entries with identical due dates can differ wildly in what they mean for you. The catalog cannot know whether you have the product, whether it is reachable, or whether a compensating control already blocks the exploitation path. It is an input to prioritization, not a prioritization.

Some entries are dead weight, and rarely one is just dead. A catalog that only grows accumulates entries for products that went end-of-life years ago; those still matter if the EOL gear is still racked, but they clutter naive dashboards. And the evidence bar, while high, is not infallible: CISA removed CVE-2022-28958 from the catalog in December 2023 after the D-Link "vulnerability" was found not to exist at all and the CVE was rejected. Removals are rare enough to be news, which is itself a good sign, but sync deletions, not just additions, if you mirror the feed into anything downstream.

None of this argues against the catalog. It argues against treating it as a complete risk picture rather than what it is: a short, high-confidence list of proven attacker behavior, refreshed almost daily, in a format a sysadmin can consume with thirty lines of code. Most organizations have not done even that. Be the one that has.

Adam Lewandowski is a network and security engineer (CompTIA Security+, CCNA, VMware VCP-DCV) working with Cisco FTD/FMC/ISE, Windows Server, MECM, and VMware environments. Connect on LinkedIn.

I write The Patch Window, a free 5-minute weekly brief on which enterprise patches can't wait - Cisco, Windows Server, VMware. Subscribe: https://the-patch-window.beehiiv.com

Stop Sorting the Patch Queue by CVSS: Exploitation Evidence Should Decide What You Patch First

Adam Lewandowski — Tue, 28 Jul 2026 19:17:03 +0000

Most enterprise patch programs still run on a rule written a decade ago: criticals and highs inside 30 days, mediums inside 90, lows when someone gets around to it. The sort key for all of it is a CVSS base score. I think that rule is now actively harmful, and I'll go further: any patch-prioritization process that starts with severity instead of exploitation evidence is optimizing the wrong variable, and 2026 is the year the data made that undeniable.

CVSS answers one question: how bad would it be if this vulnerability were exploited? It says nothing about whether it will be. Those are different questions with wildly different answers, and the gap between them is where patch programs go to die. NVD's own documentation is blunt about this: CVSS is not a measure of risk. We took a technical severity metric and quietly promoted it into a scheduling algorithm. Nobody who publishes the standard ever asked us to do that.

The arithmetic stopped working

Start with volume. The CVE ecosystem published over 48,000 new CVEs in 2025, and the pace is still accelerating: NIST reports that submissions grew 263% between 2020 and 2025, with early-2026 volume running about a third higher again. Zafran's analysis of the 2025 numbers puts it at a record year even after you control for reclassification noise.

Now the killer stat. Across the entire history of the CVE program, only about 5% of published vulnerabilities are ever observed being exploited in the wild. That's not vendor marketing; it's the finding of the Cyentia Institute and FIRST's joint study of exploitation data, the people who run EPSS. Meanwhile, more than half of all scored CVEs land at CVSS 7.0 or above.

Put those together and the math is brutal. FIRST publishes a direct comparison of remediation strategies: a "patch everything CVSS 7+" policy forces you to remediate 57.4% of all scored CVEs to catch 82.2% of the ones that get exploited, and only about 4% of what you patched urgently ever sees exploitation activity. Ninety-six percent of your emergency effort is spent on vulnerabilities attackers never touch. An EPSS-driven threshold on the same data catches a comparable share of real exploitation for a fraction of the effort.

In an enterprise, that wasted effort isn't abstract. Change windows are the scarcest resource in operations. Anyone who has scheduled an FTD upgrade through an HA pair, or coordinated an ISE patch across a deployment that authenticates every switchport in the building, knows a maintenance window is a negotiated, finite, politically expensive thing. Spending one on a CVSS 9.1 that has no exploit, no proof of concept, and no exposure, while a "7.2 with active exploitation" waits its turn in the 30-day queue, is malpractice by spreadsheet.

2026 is the year the bill came due

If severity-sorted patching worked, we'd see it in breach data. We see the opposite.

The Verizon 2026 DBIR reported that exploitation of vulnerabilities is now the number one initial access vector in breaches, at 31% of initial access, up from 20% the year before. That's the first time in the report's 19-year history that exploitation has beaten credential abuse and phishing for the top spot. The same report's remediation numbers are worse: organizations took a median of 43 days to remediate known-exploited vulnerabilities, up from 32, and only 26% of KEVs were fully remediated at all, down from 38%.

Read that again. The industry is getting slower at patching the small set of vulnerabilities we know attackers are using, while drowning in a queue sorted by a number that doesn't predict attacker behavior.

The attacker side of the ledger is moving the other direction. VulnCheck's 2026 exploit intelligence reporting found that 28.96% of vulnerabilities known to be exploited in 2025 were exploited on or before the day their CVE was published, up from 23.6% in 2024. Google's Mandiant team measured average time-to-exploit going negative across vulnerabilities disclosed in 2024: on average, exploitation now begins before disclosure. Against that reality, a tiered SLA of "criticals in 30 days" isn't a control. It's a ritual.

Even the institution at the center of the scoring pipeline has conceded the point. In April 2026, NIST announced that the NVD will no longer attempt to enrich every CVE. It now prioritizes enrichment for CVEs in CISA's Known Exploited Vulnerabilities catalog (targeting one business day) and for critical federal software; everything else is marked lowest priority. The organization that assigns the scores triages its own workload by exploitation evidence. Your patch program should take the hint.

The steelman: what CVSS defenders get right

The strongest objection to evidence-based prioritization is that evidence is a lagging indicator. By the time a CVE lands in CISA's KEV catalog, someone has already been compromised with it, and if a third of exploitation starts at or before disclosure, waiting for confirmation means you're structurally late. That's true, and it's the best argument in the room.

But it cuts against CVSS too, and harder. A base score computed on day zero can't distinguish the 9.8 that will be mass-exploited within 48 hours from the 9.8 that will never be weaponized; both sit identically in your queue. Exploitation evidence at least converges on the truth as signals arrive: vendor advisories confirming in-the-wild activity, public proof-of-concept code, EPSS movement. EPSS v4, released in March 2025, exists precisely to close the lag problem, producing a daily-updated probability of exploitation for every published CVE before confirmation ever arrives. It's imperfect and probabilistic, and it still beats a static severity number at the only question that matters for scheduling: what happens next.

Two more objections deserve honest answers. First, compliance: plenty of audit frameworks and customer contracts are written in CVSS SLAs, and you can't unilaterally ignore them. Fine. Report in CVSS, prioritize by evidence; the two are not in conflict, because the evidence-driven queue will comfortably beat a severity SLA on the vulnerabilities auditors actually care about. Second, EPSS and KEV know nothing about your environment. Also true. No global score does, including CVSS. Exposure and asset criticality are your inputs, and they were always your job.

Where CVSS genuinely earns its keep is as an impact term. Once exploitation likelihood puts a vulnerability on the urgent list, severity helps decide whether the response is "next window" or "wake people up." That's a demotion from sort key to tie-breaker, and it's the right job for the metric.

What to run instead

Here's the structure I'd defend for a typical enterprise stack, the Cisco FTD/FMC/ISE, Windows Server, MECM, VMware world I work in:

Tier 0, out-of-band, days not weeks: anything on your stack that appears in the KEV catalog, in a vendor advisory confirming active exploitation, or that is internet-facing with a high EPSS score. This list is small by construction. The entire KEV catalog held 1,655 entries as of late July 2026, accumulated over five years, across every vendor on earth. Filtered to one organization's products, a KEV match is a rare, unambiguous, drop-everything signal. Federal agencies are already required to work this way under BOD 22-01; the due dates ship free with the catalog.

Tier 1, current cycle, pulled forward: elevated EPSS, or public PoC plus reachable exposure. Watch the trajectory, not the snapshot; a score jumping an order of magnitude overnight is telling you something.

Tier 2, the monthly wave: everything else rides your normal cadence. This is where the long tail gets handled, and it's why evidence-based prioritization isn't an excuse to stop routine patching. MECM doesn't care about your opinions on scoring; a healthy monthly baseline quietly remediates most of the 95% that never gets exploited, without ever consuming an emergency window.

Special case: edge devices. Firewalls, VPN concentrators, anything with a management plane near the internet. The last two DBIRs document attackers converging on exactly this class, and these are the boxes where "we'll patch next month" has repeatedly meant "we were exploited last week." If an edge product you run lands on KEV, that's a Tier 0 event with a same-week window, HA pair or not.

The tooling cost of all this is close to zero, which removes the last excuse. The KEV catalog is a public JSON feed; EPSS scores are a free daily CSV. I run a small script each morning that diffs the KEV feed against the product list I'm responsible for and flags anything new, and building it took less time than a single well-attended CAB meeting. You do not need a risk-based vulnerability management platform to start, although the good ones are essentially selling this exact join at scale.

Severity tells you how hard the punch would land. Evidence tells you a punch is coming. Only one of those should decide what your team does this weekend.

I write The Patch Window, a free 5-minute weekly brief on which enterprise patches can't wait - Cisco, Windows Server, VMware. Subscribe: https://the-patch-window.beehiiv.com

Adam Lewandowski is a network and security engineer (CompTIA Security+, CCNA, CCNP, VMware VCP-DCV) with several years of hands-on enterprise operations across Cisco FTD/FMC/ISE, Windows Server, MECM, and VMware. He builds automation that takes the repetitive judgment calls out of security operations — without taking the humans out of the loop. Find him on LinkedIn.

Build a 5-Minute Morning Security Brief: CISA KEV + Microsoft MSRC to a Compliance-Drift Report in Node.js

Adam Lewandowski — Tue, 28 Jul 2026 19:15:59 +0000

If you run a Cisco/Windows/VMware estate, your morning vulnerability check probably looks like mine used to: open the CISA KEV catalog, open the MSRC update guide, open Cisco's software download pages to see if the gold-star release moved, skim a couple of news feeds, and try to remember what version of FTD is actually deployed. Twenty minutes of tab-juggling, most of it re-reading things that didn't change overnight.

This is a tutorial for automating that into a single dated HTML report that lands before you sit down. The tool is called sec-watch. It's around 600 lines of plain Node.js, no npm dependencies, and it answers three questions every morning:

Is anything in my stack being actively exploited? (CISA Known Exploited Vulnerabilities catalog)
What did the latest Patch Tuesday drop on my Windows Server and Configuration Manager estate? (Microsoft MSRC CVRF feed)
Am I drifting off Cisco's recommended releases? (gold-star compliance for FTD, FMC, ISE, ASA, Secure Client)

Two of those come from clean, free, no-auth JSON feeds. The third does not, and the workaround for that is half the reason this article exists. There's also a scheduling trick at the end that I haven't seen used much: the script signals "action needed" to the scheduler through its exit code.

Architecture

config.mjs (your estate)      targets.json (last-known Cisco targets)
        │                              │
        ▼                              ▼
index.mjs ──▶ kev.mjs ────┐
          ──▶ msrc.mjs ───┼──▶ compliance.mjs ──▶ report.mjs ──▶ reports/YYYY-MM-DD.html
          ──▶ intel.json ─┘                                      reports/latest.html
                                                        └──▶ exit code 0 or 2

Everything is a plain .mjs module. fetch and AbortSignal.timeout are built into Node 20+, so package.json is just metadata:

{
  "name": "sec-watch",
  "type": "module",
  "scripts": { "start": "node index.mjs", "open": "node index.mjs --open" },
  "engines": { "node": ">=20" }
}

Step 1: Describe your estate in one config file

Everything downstream keys off a single config.mjs. Each tracked product gets a current version (what you actually run), plus keywords used to match it against the two feeds:

export const config = {
  lookbackDays: 3,      // how far back "new" vulns count
  kevTrackedDays: 90,   // actionable KEV window for tracked products

  tracked: [
    {
      key: "ftd",
      name: "Cisco Secure Firewall Threat Defense (FTD)",
      vendor: "Cisco",
      goldStar: true,
      current: "FILL ME e.g. 7.4.2.1",
      kevKeywords: ["firepower threat defense", "secure firewall threat defense", "ftd"],
    },
    {
      key: "winsrv2022",
      name: "Windows Server 2022",
      vendor: "Microsoft",
      goldStar: false,
      current: "FILL ME e.g. latest CU 2026-05",
      msrcKeywords: ["Windows Server 2022"],
    },
    {
      key: "esxi",
      name: "VMware ESXi",
      vendor: "VMware",
      goldStar: false,
      current: "FILL ME e.g. 8.0 U3",
      kevKeywords: ["esxi"],
    },
    // ...FMC, ISE, ASA, Secure Client, Server 2019/2025, MECM, SolarWinds, vCenter
  ],

  // Vendors you don't version-track but want KEV visibility on
  watchKeywords: [
    "ios xe", "fortinet", "pan-os", "citrix", "netscaler", "ivanti",
    "exchange server", "veeam", "vcenter", "solarwinds", "manageengine",
    // ...the full list in my config is ~60 entries
  ],
};

Two deliberate choices here. First, kevKeywords and msrcKeywords are separate, because the two feeds name products differently (KEV says "Firepower Threat Defense", MSRC product names are long strings like "Windows Server 2022 (Server Core installation)"). Second, watchKeywords casts a wide net over adjacent infrastructure. You don't run FortiGate, but if a pre-auth RCE on a competing firewall goes into KEV, you want to know, because the same attacker attention tends to rotate through the whole edge-device category.

Step 2: Pull the KEV catalog

CISA publishes the entire Known Exploited Vulnerabilities catalog as one JSON file. No API key, no rate-limit dance:

const KEV_URL =
  "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json";

export async function fetchKev() {
  const res = await fetch(KEV_URL, { signal: AbortSignal.timeout(30000) });
  if (!res.ok) throw new Error(`KEV fetch ${res.status}`);
  const json = await res.json();
  return json.vulnerabilities || [];
}

Matching is a lowercase substring check across the fields KEV gives you:

function matches(vuln, keywords) {
  const hay = `${vuln.vendorProject} ${vuln.product} ${vuln.vulnerabilityName} ${vuln.shortDescription}`.toLowerCase();
  return keywords.some((k) => hay.includes(k.toLowerCase()));
}

The useful part is what happens after matching. Tracked products get split into a recent actionable window and an all-time count:

const recentCutoff = Date.now() - (config.kevTrackedDays || 90) * 86400000;
const trackedRecent = trackedUniq.filter((v) => new Date(v.dateAdded).getTime() >= recentCutoff);
const trackedOlder = trackedUniq.length - trackedRecent.length;

Why bother? Because ASA and ISE have KEV entries going back years. If you're current on patches, those are history, not work. Showing "2 new in the last 90 days, plus 11 older entries you should already have covered" keeps the report honest without drowning the signal. Watch-list vendors get an even tighter filter: only entries added within lookbackDays (3 days) appear at all.

Step 3: Parse Patch Tuesday from the MSRC CVRF feed

Microsoft's CVRF API is also free and unauthenticated. You list the monthly documents, grab the newest, and walk its vulnerability array:

const UPDATES_URL = "https://api.msrc.microsoft.com/cvrf/v3.0/updates";

The non-obvious part is that severity and exploitation status live in a Threats array, tagged by numeric type:

// Threat Type per MSRC CVRF: 0=Impact, 1=Exploit Status, 3=Severity
function severityOf(vuln) {
  const t = (vuln.Threats || []).find((x) => x.Type === 3);
  return t?.Description?.Value || "";
}

Each CVE lists affected products by ID, so you build an ID-to-name map from the document's ProductTree, then match names against your msrcKeywords. A monthly document covers hundreds of CVEs across everything Microsoft ships; after filtering to Windows Server and Configuration Manager, a typical month leaves 40 to 80 relevant entries. Those get sorted so the report reads top-down in priority order:

// Sort: critical/exploited first, then by CVSS
const rank = (s) => (/critical/i.test(s) ? 2 : /important/i.test(s) ? 1 : 0);
findings.sort((a, b) => rank(b.severity) - rank(a.severity) || b.cvss - a.cvss);

That exploited-and-critical-first ordering repeats everywhere in sec-watch. The report renderer applies the same idea to research highlights ((b.exploited - a.exploited) || (sevRank(b.severity) - sevRank(a.severity))), and rows with known ransomware campaign use get a red row tint. A morning brief you read in five minutes must put the item that ruins your week on line one.

Step 4: Gold-star compliance drift

Cisco marks a "Suggested Release" with a gold star on its download pages. In a typical FTD/ISE shop that star is the de facto patch-level standard: an auditor asks whether you're on it, and change requests reference it. But there is no API for it. The star lives in web pages, and occasionally moves.

sec-watch handles this with a two-layer design. targets.json stores the last-known-good target per product, with the source URL and the date it was seen:

{
  "cisco_gold_star": {
    "ftd": {
      "suggested_release": "7.6.4",
      "source": "https://www.cisco.com/.../threat-defense-compatibility.html",
      "seen": "2026-05-27"
    }
  }
}

Each run, fresh research results merge into this file, but only when the lookup actually returned a version:

export async function mergeAndSaveTargets(targets, webGoldStar, dateStr) {
  targets.cisco_gold_star = targets.cisco_gold_star || {};
  let changed = false;
  for (const g of webGoldStar || []) {
    if (!g.key) continue;
    if (g.suggested_release && g.suggested_release.trim()) {
      targets.cisco_gold_star[g.key] = {
        suggested_release: g.suggested_release.trim(),
        source: g.source || "",
        notes: g.notes || "",
        seen: dateStr,
      };
      changed = true;
    }
  }
  // ...persist if changed
  return targets;
}

So a failed lookup degrades to "compare against the last version we verified" instead of losing compliance data. The report notes the fallback so you know the target might be stale.

Version comparison itself is deliberately dumb. Cisco writes versions as "7.4.2.1", "Version 7.4.2.1", or "3.3 Patch 4" depending on the page, so both sides get normalized before an equality check:

function normalize(v) {
  if (!v) return "";
  return String(v)
    .toLowerCase()
    .replace(/version|release|patch/g, (m) => (m === "patch" ? "p" : ""))
    .replace(/[^0-9a-z.]/g, "")
    .replace(/\.+/g, ".")
    .replace(/^\.|\.$/g, "");
}

Equal means COMPLIANT, different means DRIFT, and an unfilled current means UNKNOWN_CURRENT. No greater-than or less-than logic, on purpose: gold-star compliance means being on the suggested release, and being ahead of it is still a state worth flagging to a human.

Step 5: The research step, and the intel.json escape hatch

The gold-star lookup and a "notable new vulnerabilities" section both need live web research. My first version shelled out to an LLM CLI (Claude Code) with web-search tools enabled, prompted it for strict JSON, and parsed the result. It works, and the code is in the repo, but a nested CLI call that browses the web can take minutes and occasionally times out. That's a bad property for the one step of your morning pipeline that runs unattended.

So the workflow I actually use is the --intel flag. Any research process, human or AI, writes a plain intel.json file, and the report renders from that:

if (USE_INTEL) {
  // Manual daily workflow: read intel.json populated in-session
  // from live web research. No nested CLI -> no timeouts / contention.
  const intel = JSON.parse(await readFile(new URL("./intel.json", import.meta.url), "utf8"));
  web = {
    cisco_gold_star: intel.cisco_gold_star || [],
    highlights: intel.highlights || [],
    analyst_note: intel.analyst_note || "",
    web_ok: true,
  };
}

Each highlight is a structured record: category, product, CVE, severity, an exploited boolean, a summary, a recommended action, and a real source URL. In practice I do the research in an interactive AI session each morning (with a strict instruction: only items from the last 3 days, every item needs a source URL you actually visited), it writes intel.json, and then node index.mjs --intel --open renders everything in a few seconds. The file format is the contract; where the research comes from is swappable. If you want zero AI involvement, run node index.mjs --no-web and you still get KEV, MSRC, and compliance against the stored targets.

Step 6: Schedule it, and make the exit code mean something

The last lines of index.mjs are my favorite part of the project:

// Exit non-zero if there's drift or an actively-exploited tracked product, so
// a scheduler can flag the run as "action needed".
const actionNeeded = compliance.summary.drift > 0 || (kev.tracked || []).length > 0;
process.exitCode = actionNeeded ? 2 : 0;

Exit 0 means the estate is quiet: no drift, no fresh KEV entries against tracked products. Exit 2 means the report contains something that needs a human. Windows Task Scheduler records the last run result per task, so a glance at the console (or any monitoring that watches task results) distinguishes "ran fine, nothing urgent" from "ran fine, go read the report" without opening the HTML. The same convention plugs straight into cron plus an alerting wrapper, or a CI job that fails visibly on exit 2. Reserving 2 keeps it distinct from exit 1, which the fatal-error handler uses, so crashes and findings never look alike.

Registration is a short PowerShell script using the native scheduled-task cmdlets. The settings matter more than the trigger:

$Settings = New-ScheduledTaskSettingsSet -StartWhenAvailable -RunOnlyIfNetworkAvailable `
  -ExecutionTimeLimit (New-TimeSpan -Minutes 20) -DontStopIfGoingOnBatteries -AllowStartIfOnBatteries

-StartWhenAvailable is the one people forget: if the machine was asleep at 07:00, the task runs at wake instead of silently skipping the day. -RunOnlyIfNetworkAvailable avoids a run full of fetch errors on a cold boot. The script also resolves the full path to node.exe before registering, because Task Scheduler does not reliably inherit your interactive PATH.

Every run writes both a dated file (reports/2026-05-27.html) and a stable reports/latest.html, so you can bookmark one URL and also keep an audit trail of what you knew on a given morning.

Honest limitations

Keyword matching is crude. Substring matching against KEV text can over-match (short keywords like "ftd" hitting unrelated descriptions) and under-match (a vendor renames a product line). Keep keywords specific and skim the raw catalog occasionally to check your filters.
The gold-star target is only as good as the research. There is no Cisco API for the suggested release, and the star sometimes lags or differs between the compatibility matrix and the download portal. The report footer says it plainly: verify against Cisco.com before acting. This tool is a prompt, not an authority.
MSRC coverage is the latest monthly document only. Out-of-band releases usually revise the current month's document, but a revision to an older month would be missed.
Version comparison is string equality. "7.6.4" versus "7.6.4.1" is DRIFT even though you might be deliberately ahead. That's a feature for compliance reporting and an annoyance otherwise.
It watches feeds, not your boxes. The current versions in config are hand-maintained. If you upgrade FTD and forget to update the config, the report lies to you. Wiring it to pull versions from FMC's API or your CMDB is the obvious next step.
KEV and Patch Tuesday are not the whole threat picture. Vendor advisories (Cisco PSIRT, VMware VMSA) publish before things reach KEV. The research step partly covers this gap, but a feed-only run has a blind spot measured in days.

None of that stops the tool from doing its actual job: replacing twenty minutes of tab-juggling with five minutes of reading, every morning, with a paper trail. Build the boring version first. The feeds are free, the whole thing is dependency-free Node, and once the report is landing daily you'll know exactly which of the limitations above is worth fixing for your estate.

I write The Patch Window, a free 5-minute weekly brief on which enterprise patches can't wait - Cisco, Windows Server, VMware. Subscribe: https://the-patch-window.beehiiv.com

Stop Piping Raw Alerts into an LLM: Building a SOC Triage Agent That Correlates First and Escalates Last

Adam Lewandowski — Tue, 28 Jul 2026 01:01:36 +0000

Every few weeks another demo lands on my feed: someone pipes a security alert into a large language model, gets back a paragraph that sounds like a SOC analyst, and declares Tier-1 automated. Having spent years on the receiving end of enterprise alert queues — Cisco FTD intrusion events, Defender detections, sign-in risk alerts — I can tell you why those demos fall apart in production:

Alerts in isolation are noise. The signal is the story across alerts: the same actor showing up in a risky Entra ID sign-in, then AWS recon, then a persistence action. An LLM triaging one alert at a time can't see the campaign.
Cost scales with alert volume, and alert volume is enormous. If every event costs an API call, your triage bill grows linearly with your noisiest sensor.
Free-text verdicts aren't actionable. "This looks suspicious" doesn't page anyone. You need structured output a downstream system can route on.

If you haven't worked a queue like this, the ratios are hard to believe. A single FTD intrusion policy tuned one notch too aggressive will emit thousands of IPS events a day, most of them the same few signatures firing on scanner traffic that never reached anything vulnerable. A MECM patch wave lights up endpoint AV with detections on installer behavior that looks exactly like the droppers the heuristics were trained on. In most shops the alert-to-incident ratio is measured in orders of magnitude, not percentages. So the interesting engineering problem was never "can a model write a plausible paragraph about one alert." It's what you do with everything else.

So I built Aegis, a working AI SOC analyst, to demonstrate what I think the right shape is: normalize → correlate → then decide whether an LLM is even needed → structured verdict → gated containment. It ingests synthetic telemetry from four sources (AWS GuardDuty, CloudTrail, Entra ID sign-in logs, Microsoft Defender), stitches 17 raw events into incidents, auto-suppresses the false positives without spending a token, and hands only the genuinely ambiguous or dangerous cases to a Claude tool-use agent that must investigate before ruling.

The whole thing runs offline with zero dependencies (a deterministic rule engine stands in for the LLM), and upgrades to the live agent the moment an ANTHROPIC_API_KEY is present. In the demo run, 3 of 4 incidents cost $0.00. Only the real attack touches the API.

This article walks through the architecture and the design decisions, with real code from the repo.

The pipeline at a glance

   ingest  ─▶  correlate  ─▶  AI triage  ─▶  response playbook  ─▶  report
 (4 sources)  (mini-SIEM)   (Claude agent)  (Graph / PS / AWS)   (HTML + console)

ai-soc-analyst/
├─ run_demo.py                 # one-command entry point
├─ data/                       # synthetic telemetry (one file per source)
├─ src/aegis/
│   ├─ schema.py               # normalized SecurityEvent / Incident model
│   ├─ ingest.py               # source-specific normalizers → common schema
│   ├─ correlate.py            # union-find correlation engine (the mini-SIEM)
│   ├─ enrich.py               # threat-intel + identity enrichment (pluggable)
│   ├─ agent.py                # Claude tool-use agent + heuristic fallback
│   ├─ playbooks.py            # incident → containment actions
│   └─ report.py               # console + self-contained HTML report
└─ powershell/
    ├─ Invoke-EntraContainment.ps1   # Graph API identity containment
    └─ Get-SecureScoreDelta.ps1      # Secure Score posture job

Step 1: Normalize everything into one schema

GuardDuty findings, CloudTrail records, Entra sign-in logs, and Defender alerts all have wildly different JSON shapes, and worse, different severity vocabularies. GuardDuty gives you a 0–10 float; Microsoft gives you strings like "Informational." If you don't collapse those early, every downstream component grows source-specific branches.

Aegis flattens everything into one SecurityEvent dataclass, and severity coercion happens in exactly one place:

class Severity(IntEnum):
    INFO = 0
    LOW = 1
    MEDIUM = 2
    HIGH = 3
    CRITICAL = 4

    @classmethod
    def from_any(cls, value: Any) -> "Severity":
        if isinstance(value, Severity):
            return value
        if isinstance(value, (int, float)) and not isinstance(value, bool):
            # GuardDuty numeric severity: 0-3.9 low, 4-6.9 medium, 7-8.9 high, 9+ critical.
            if value >= 9:
                return cls.CRITICAL
            if value >= 7:
                return cls.HIGH
            if value >= 4:
                return cls.MEDIUM
            if value >= 1:
                return cls.LOW
            return cls.INFO
        text = str(value).strip().lower()
        return {
            "critical": cls.CRITICAL,
            "high": cls.HIGH,
            "medium": cls.MEDIUM,
            "moderate": cls.MEDIUM,
            "low": cls.LOW,
            "informational": cls.INFO,
            "info": cls.INFO,
            "none": cls.INFO,
        }.get(text, cls.MEDIUM)

One deliberate choice: unknown severity strings fall back to MEDIUM, not INFO. If a source starts emitting a vocabulary you didn't anticipate, you want those events above your triage floor, not silently dropped below it.

Adding a source is one normalizer function. The CloudTrail normalizer is a good example of encoding operational knowledge at ingest time. It scores write and defense-evasion API calls higher than read-only recon, so the correlation layer naturally weights persistence and tamper actions:

high_impact = {
    "CreateAccessKey", "StopLogging", "DeleteTrail", "PutUserPolicy",
    "AttachUserPolicy", "CreateUser", "UpdateAssumeRolePolicy",
}
recon = {"GetCallerIdentity", "ListUsers", "ListBuckets", "ListRoles", "DescribeInstances"}

Step 2: Correlate by actor, not just alert

This is the part most "LLM SOC" demos skip, and it's the part that actually matters. Aegis clusters events with a union-find over shared identity or shared source IP within a sliding time window, then unions overlapping clusters transitively — because attackers pivot:

for i in range(len(ordered)):
    for j in range(i + 1, len(ordered)):
        if ordered[j].timestamp - ordered[i].timestamp > window:
            break  # ordered by time; nothing further is in-window
        if _linked(ordered[i], ordered[j]):
            union(i, j)

The subtle bug most first attempts hit: the same human shows up under different identity strings in different control planes. A user's Entra UPN and their AWS IAM CLI user are, to the correlation engine, different principals — unless you teach it otherwise:

def _same_identity(p1: str, p2: str) -> bool:
    # 'j.okafor@corp.example', 'j.okafor-cli', and 'j.okafor'
    # all refer to the same human — a real attacker pivots across these.
    if not p1 or not p2:
        return False
    a = p1.split("@")[0].replace("-cli", "").replace("-", ".")
    b = p2.split("@")[0].replace("-cli", "").replace("-", ".")
    return a == b

Is this heuristic naive? Absolutely. It encodes one org's naming convention, and in production you'd back it with an identity graph (Entra ID ↔ AWS SSO mappings). But the architectural point stands: cross-control-plane identity resolution is a first-class correlation feature, not an enrichment afterthought. In the demo, this is exactly what stitches the Tor sign-in → MFA fatigue → AWS recon → CreateAccessKey persistence → StopLogging tamper → endpoint loader → mailbox-rule exfil chain into one P1 incident instead of seven mediums scattered across four consoles.

And this isn't a cloud-only problem. In a typical Cisco-and-Microsoft enterprise, one administrator exists as j.okafor@corp.com in Entra sign-in logs, CORP\jokafor in Windows Security events, a bare jokafor in the ISE live-session table (or only an endpoint MAC address, if the session authenticated via MAB), a local account name in FMC audit records, and CORP.LOCAL\jokafor to vCenter SSO. Five control planes, five spellings, zero agreement on a canonical key. A correlation engine that treats those strings as five different people will hand you five medium alerts where there is one story. SIEM vendors sell identity resolution as an enrichment add-on; I'd argue it belongs in the correlation key itself.

Step 3: Decide whether the LLM is even needed

Here's the cost-control lever that separates a demo from something deployable. Aegis runs tiered triage: a deterministic pre-filter auto-resolves the obvious cases for free, and only escalates incidents that carry a malicious indicator, a high-signal ATT&CK technique, or genuine ambiguity:

def _should_escalate(incident: Incident) -> bool:
    reputations = [enrich.lookup_ip(ip) for ip in incident.src_ips]
    has_bad_ip = any(r.reputation in {"malicious", "suspicious"} for r in reputations)
    high_signal = bool(set(incident.mitre) & HIGH_SIGNAL_TECHNIQUES)
    if has_bad_ip or high_signal:
        return True
    # No malicious indicators: auto-resolve service accounts and low-severity noise.
    if enrich.user_context(incident.principal)["is_service_account"]:
        return False
    if incident.max_severity <= Severity.LOW:
        return False
    # Ambiguous medium+ with no clear signal — worth a judgment call.
    return incident.max_severity >= Severity.MEDIUM

HIGH_SIGNAL_TECHNIQUES is a short, opinionated set — persistence (T1098.001), cloud-log tampering (T1562.008), PowerShell execution (T1059.001), mailbox-rule exfil (T1114.003), MFA fatigue (T1621), Tor proxying (T1090.003). These are the techniques where a wrong auto-suppress is expensive, so they always get a judgment call.

The suppressions every shop ends up writing are the same ones this pre-filter encodes: the internal vulnerability scanner tripping IPS signatures on schedule, the EICAR file the AV team drops every quarter, backup and CI service accounts authenticating from datacenter egress at 3 a.m. doing exactly what they're supposed to do. The failure mode is also the same everywhere. Suppression rules written broadly ("ignore this signature," "ignore this subnet") keep matching long after the environment changes, and one day the real thing rides in under an old exception. That's why _should_escalate is structured the way it is: suppression requires the absence of malicious indicators plus a positive reason to close (known service account, low severity), while the high-signal technique list is an always-escalate override no suppression can beat. Suppress by evidence, escalate by category — the inverse of how most alert-tuning debt accumulates.

In the demo run, three incidents (the research scanner, the EICAR test, the CI/CD service account) are closed by the free engine, and the API is invoked only for the actual intrusion.

Step 4: A tool-use agent that must investigate before ruling

When an incident does escalate, it isn't a single prompt. The Claude agent gets a SOC-analyst system prompt and four tools:

Tool	Purpose
`lookup_ip`	Threat-intel reputation for a source IP
`get_user_context`	Is this principal privileged? A service account?
`get_mitre_technique`	Resolve an ATT&CK ID to name + tactic
`submit_verdict`	Strict-schema final ruling — the only way to finish

The trick that makes the output dependable is submit_verdict. It's a tool with "strict": True and a closed schema; the model can't finish the loop without committing to typed fields:

{
    "name": "submit_verdict",
    "description": "Submit the final triage verdict. Call exactly once, after investigating.",
    "strict": True,
    "input_schema": {
        "type": "object",
        "properties": {
            "is_true_positive": {"type": "boolean"},
            "severity": {"type": "string", "enum": ["Critical", "High", "Medium", "Low", "Info"]},
            "priority": {"type": "string", "enum": ["P1", "P2", "P3", "P4"]},
            "confidence": {"type": "integer", "minimum": 0, "maximum": 100},
            "attack_narrative": {"type": "string", ...},
            "reasoning": {"type": "string", ...},
        },
        "required": ["is_true_positive", "severity", "priority", "confidence",
                     "attack_narrative", "reasoning"],
        "additionalProperties": False,
    },
}

No parsing prose, no regexing severity out of a paragraph. The verdict routes straight into playbook selection and the report. The agent loop also records every tool call into a human-readable trace, so the analyst reviewing the verdict can see how the machine investigated:

AI agent investigation (via claude-haiku-4-5):
    lookup_ip(185.220.101.47) -> malicious (tor-exit-node, anonymizer, c2-adjacent)
    get_user_context(j.okafor@...) -> standard user
    get_mitre_technique(T1562.008) -> T1562.008 — Impair Defenses: Disable Cloud Logs
    ✓ submit_verdict -> Critical/P1 (TRUE positive)

That trace is not a gimmick. If you're going to let a model influence incident priority, "show your work" is the minimum bar for analyst trust, and for the post-incident review when it gets one wrong.

Two more production-shaped details in the agent path:

Fail safe, always. The public triage() entry point wraps the live agent in a try/except; any API error or step-limit overrun falls back to the deterministic engine and annotates the verdict with what happened. One API hiccup never stalls the alert queue mid-shift.
Cost is visible, not a mystery. Every run tracks token usage per incident and prints an estimated dollar cost, with a cheap default model (Haiku-class) and an env-var override (AEGIS_MODEL) for deployments that want deeper reasoning on escalated incidents only.

Step 5: Containment that names its control plane

A triage verdict that ends in "investigate further" is a demo. Aegis maps verdicts to concrete containment actions, and every action names the real automation that would carry it out:

actions.append(Action(
    name="Disable compromised account & revoke sessions",
    target="Microsoft Graph (Entra ID)",
    automation=(
        f"pwsh ./powershell/Invoke-EntraContainment.ps1 "
        f"-UserPrincipalName {upn} -DisableAccount -RevokeSessions"
    ),
    rationale=(
        "Risky/failed MFA sign-in from a malicious IP indicates account "
        "takeover; disabling the account and revoking refresh tokens cuts "
        "active attacker sessions immediately."
    ),
    destructive=True,
))

The destructive=True flag is load-bearing: every account-disable, session-revoke, MFA-reset, and endpoint-isolation action is gated behind human approval, and the companion PowerShell (Invoke-EntraContainment.ps1) runs in simulation unless -Execute is explicitly passed.

Auto-containment earns trust slowly, and it should. The classic failure is an action keyed on the wrong attribute. Quarantine-by-identity in a NAC deployment like ISE will happily kill every session the account holds, including the endpoints nobody remembered were authenticating with it. Auto-disabling a "compromised" account that turns out to be a service identity takes down every integration that depends on it, usually at the worst possible hour. Aegis encodes one small defense against this class of mistake directly in the playbook layer: when it recommends perimeter blocks, it filters to reputationally-bad IPs only, so the actor's legitimate corporate egress — which the identity linkage correctly pulled into the incident — never lands on a deny-list.

What I'd tell you before you build one

What worked:

Normalize-first paid for itself immediately. Correlation, enrichment, triage, and reporting share one schema; adding a fifth source is one function.
Tiered escalation is the difference between a toy and a bill you can defend. The LLM is a scarce senior analyst, not a firehose destination.
Strict tool schemas beat prompt-engineering for structured output. Forcing the final answer through a closed-schema tool call eliminated an entire class of parsing failures.
Building the heuristic fallback as a real second implementation (not a stub) meant the demo works offline and gave the live agent a benchmark: both engines reason over identical enrichment, so their disagreements are informative.

Honest limitations:

The telemetry is synthetic and small. Seventeen hand-crafted events prove the architecture, not the recall. Real environments bring malformed timestamps, delayed log delivery, and volumes where the windowed pairwise correlation pass needs streaming or bucketing.
Identity matching is a naming-convention heuristic. Production needs a real identity graph (Entra ↔ AWS SSO ↔ HR system), and it will still be the hardest data-quality problem in the pipeline.
The threat-intel and identity enrichment are local lookups. They're pluggable by design — swapping in GreyNoise/AbuseIPDB is the intended path — but reputation-driven verdicts are only as good as the feed behind them.
The LLM's verdicts haven't been evaluated at scale. Before trusting it with suppression decisions, you'd want a labeled incident corpus and a measured false-negative rate. An "it sounded right on four incidents" evaluation is exactly the trap this article warns about.

My bottom line: I'd deploy this pattern today, but not with this blast radius. Start with the agent as an enrichment-and-draft layer — it investigates, writes the narrative, proposes severity and priority, and a human confirms every verdict. Suppression authority, the right to close an incident unseen, comes last and only per alert class, after the agent has run in shadow mode against human tier-1 decisions long enough to measure a false-negative rate you'd sign your name to. Agreement rate is the vanity metric; the number that matters is how often the machine says "benign" when the human said "incident." Until you can put a measured value on that, the correlate-first architecture is doing most of the heavy lifting anyway. And that part costs nothing.

I write The Patch Window, a free 5-minute weekly brief on which enterprise patches can't wait - Cisco, Windows Server, VMware. Subscribe: https://the-patch-window.beehiiv.com