Anyone got a sane way to track firmware CVEs across a Fortinet/Cisco fleet or is it just me + a spreadsheet

Just use one of the many available RSS feeds and filter to your liking.

We deal with a lot of switching and firewall systems. We have a decent amount of Unifi and Edgeswitches. They're not a perfect fit for every environment, but every year they get better and better. The completely automated and rolling updates we have on them are amazing - it's basically set it and forget it. Five years ago with Ubiquiti that would have freaked me out and now it just works. I wish Edgeswitches would see an update, but UNMS/UISP gets better and better. After that, Meraki and Aruba Central are pretty good. Everything else I mostly hate.

this is such a clean way to think about it, turning "did we check?" into an artifact instead of a vibe check once a quarter also makes it way harder for management/insurance to play dumb later when you can literally point at dated reports and say "here’s what we knew and when"

Yeah. The part that actually saves you is recording the decision, not just the finding. "We knew" on its own is a liability; "we knew, deferred it, here is who signed off" is what holds up.

what does everyone else do? We standardize on a MANAGED network stack and then manage it. IMHO, any other method ends up with exactly where you are now. It solves all your other questions: "every month I'm basically manually checking PSIRT advisories against a spreadsheet" "Missed a FortiOS SSL-VPN one by like three weeks last year,,,because...nothing yelled at me about it" "that's the kind of thing that keeps me up." "If you're dealing with cyber insurance renewals, how are you proving you're on top of patching " bonus from me: "how do you automate patching, patch reporting, hotfixes, etc when something does drop" IMHO, regardless of what a bunch of people are about to say: we all say something like "Proactive network monitoring, management, and security" in our marketing, sales convos, and hopefully SoW. But if you don't have some kind of network stack standards AND PROCESSES, you don't. If a big thing hits and you can't instantly see what you have affected and bulk manage it (you know, management and monitoring) then you can't be doing the last part (security). It doesn't matter WHAT network stack you use (i use sophos firewalls and ubnt switching/wifi specifically for the manageability of both but you could do the same with other gear), it matters that you have REAL management in place and processes to handle when these things happen. If you allow clients to run unmanaged firewalls or whatever network equipment they have because you don't want to migrate them to what you're deploying these workflows and processes and tools on, you are not doing "proactive network monitoring, management, and security" and frankly should take it out of your marketing and agreements. But anyway, yeah, you need to standardize and then build your workflows to address/perform/simplify those exact things.

The spreadsheet thing is basically universal, most RMMs log the version and leave the CVE correlation to you, which is exactly the gap you hit. A couple of things that help without a big spend. FortiGuard PSIRT has an RSS feed and a GraphQL API, and Cisco has the openVuln PSIRT API that takes a product and version and returns matching advisories, so you can script "here's my fleet inventory, here's what's vulnerable" as a weekly job instead of eyeballing PSIRT by hand. Pair that with runZero or even a tagged Auvik export for the current version inventory and you've got both halves. For a single fleet the API plus cron route is cheap and catches the SSL-VPN type stuff before it bites. Full disclosure, I work on a security platform (VORXOC Helxon) so I'm in this space, happy to go deeper in the promo thread rather than derail here.

I run API's to pull in details for the CVEs and have an automation hub that filters out to items that matter to us, with APIs into our RMM solutions to check if devices have been patched against them or not, plus we run our own SIEM for Fortigates so we have the information of the version the fortigates are running, so we can get notified wihen a CVE affects them and gets a list of the affected devices, plus logging to watch for such exploits actively happening etc. Makes it quick to see what's affected by the latest CVEs and remediate them.

Fortinet and Cisco are not the same thing. One needs a database to keep track of cve, the other needs a csv

Everyone's answers here are solving the half of the problem you control, tracking what you know is deployed. The other half is confirming nothing fell off that list. Boxes get replaced or reconfigured and the firmware-tracking spreadsheet doesn't always keep up, so something can quietly drop off internal tracking while still sitting there exposed. An external scan run periodically against your own client base catches that blind spot, it tells you what's actually reachable from outside regardless of whether internal inventory agrees. Worth running alongside whatever CVE-tracking process you land on, not instead of it.

you’re not behind. most tools are decent at inventory and weak at connecting versions to the specific advisory, exposure, and safe upgrade path. that last bit is why the spreadsheet survives. the practical middle ground is a clean asset inventory plus vendor PSIRT subscriptions and a monthly review tied to an owner and deadline. think of it like a quest tracker. knowing where every box is matters, but someone still has to flag which ones are carrying a live grenade

you can make a script that pulls the PSIRT feed, match it against the version each box runs, and have it ping you only when something you actually run goes vulnerable. Same data doubles as your patch proof for the insurance renewals. Built stuff like this before, PM me if you wanna talk

We follow a few RSS feeds and automate out what doesn't affect us.

The feed half is the easy half. Both Fortinet and Cisco PSIRT publish affected and fixed version ranges in structured form, so matching them against your inventory is plain comparison logic, not something that needs judgment, and it should live as code you re-run rather than a query you eyeball once a month. Where this bites people is that the job never writes anything down, so at renewal there is no record of what was checked on which date and you rebuild it by hand anyway. Have the run emit a dated file: every device, its version, every advisory considered, and the verdict for each. That file is your insurance answer and it costs nothing once the check already runs.

I've had some chats with our support teams, and we believe you can do what you're trying to achieve with Domotz and especially thanks to our new dedicated MCP server. We (Domotz) can get the (sysDescr) SNMP OID for each device when you have them unlocked for SNMP monitoring. We can get the vendor, model, OS, and firmware version in a single string. Through our new dedicated MCP server we can get this info over to the AI agent of your choice for any managed devices. Also we now have dedicated apps for Claude and ChatGPT. Your work flow could be something like the following: Your AI agent uses the Domotz MCP Server to collect the device inventory and sysDescr information. On a scheduled basis, your AI agent checks the detected firmware versions against the latest vendor PSIRT advisories, CVEs, and firmware releases. It identifies vulnerable or outdated devices and determines the recommended firmware version or upgrade path. It generates a report or triggers a notification/ticket for devices requiring attention. We can get the current device/firmware data and your AI agent runs the ongoing firmware and vulnerability analysis. Hope that is clear! And if any more questions you could ask on r/domotz as well we will try our best to help. Free trial details here: Bonus our per site pricing is back!