The CVE Your Vendor Never Told You About
Vendors are not, generally, in a hurry to tell you about the vulnerabilities in their own hardware. That's not usually malice — it's a mix of slow disclosure processes, firmware update notes nobody reads, and the plain fact that "there's a known exploit for the router you sold three years ago" is not a sentence any manufacturer is eager to volunteer. Which leaves an uncomfortable gap: the vulnerabilities are documented, publicly, searchable by anyone — and
almost nobody responsible for the affected device is actually looking.
The CVE database is public. Watching it isn't.
Common Vulnerabilities and Exposures — CVEs — are catalogued, dated, and rated the moment they're disclosed. In theory, anyone can check whether a device on their network has a known issue. In practice, almost nobody does, because it requires knowing exactly what's running on every device, cross-referencing that against a constantly updating public database, and repeating the exercise regularly enough to catch anything new. That's not a task most IT teams have the time to do by hand, on every device, on a recurring basis — and it's exactly the kind of task that's easy to intend to do "properly, eventually" and never quite get to.
The result is a lot of networks running hardware with disclosed, documented vulnerabilities that nobody's checked for, not because anyone was careless, but because the checking never became anyone's actual job.
How NetMon actually finds them
NetMon fingerprints what's running on a device by examining its open ports and the services answering on them — the same kind of information a competent attacker would gather during reconnaissance, except gathered here on your behalf, continuously, as part of ordinary monitoring rather than a one-off audit. That fingerprint gets checked against known CVEs, and anything that matches gets surfaced — not buried in a report nobody reads, but flagged as part of the same dashboard already showing you everything else about that device.
This catches the vulnerabilities that live in the gap vendors leave open: the NAS running firmware from two versions ago with a documented remote-access flaw, the forgotten management interface still listening on a port nobody remembers enabling, the device whose vulnerability was disclosed eighteen months ago and never made it into anyone's inbox. None of that requires a person to go looking. It requires a person to glance at a dashboard that's already looking.
Where honesty matters more than confidence
Here's the part worth being straightforward about, because vendors of security tools rarely are: fingerprint-based CVE matching isn't infallible, and treating it as gospel is its own kind of risk. A device's open ports and services are a strong signal of what it's running, but signals aren't certainty. Occasionally a match will point at the wrong product family — a device from one vendor surfacing a CVE that actually belongs to a completely different piece of software that happens to share a fingerprint. That's not a reason to distrust the scan. It's a reason to treat every flagged CVE as a strong, worth-investigating lead rather than an
automatic verdict, and to have a person confirm what's actually running before acting on it.
We'd rather say that plainly than let a tool imply more certainty than fingerprinting can honestly deliver. A false positive that gets double-checked and dismissed costs five minutes. A real vulnerability that never gets flagged at all, because a tool overpromised and someone learned not to trust it, costs considerably more. Continuous, imperfect, honestly-labelled scanning beats no scanning by an enormous margin — but it beats blind trust in any single scan
result too.
Why continuous beats periodic
The other place vendor silence hurts is timing. A vulnerability disclosed today doesn't retroactively announce itself on hardware that was scanned clean last month. A once-a-year security audit — the traditional way most small and mid-sized organisations "handle" this — is a snapshot, accurate on the day it was taken and steadily less accurate every day after, right up until the next one. Continuous scanning doesn't have that gap. A newly disclosed CVE that matches something already on the network gets caught the next time that device's fingerprint is checked, not whenever the next scheduled audit happens to fall.
For a network that's genuinely stable and unchanging, that difference might not matter much. For any real network — where firmware ages, devices get added, configurations drift — it's the difference between security posture as an ongoing fact and security posture as a document that was true once.
What this actually buys you
The honest pitch here isn't "NetMon finds every vulnerability with perfect accuracy" — no fingerprint-based scanner can promise that, and any that claims to is worth being sceptical of. The honest pitch is: the gap between what vendors disclose and what anyone actually checks gets a lot smaller, continuously, without requiring anyone to remember to run an audit, read a changelog, or manually cross-reference a device list against a public database by hand. That's not the same as guaranteed security. It's a genuinely large improvement over the realistic alternative, which for most organisations isn't "a thorough manual process" — it's nothing at all.
A client-ready report showing what was found, when, and on which device turns that ongoing work into something you can actually demonstrate, rather than a private assurance nobody can verify. Whether that's for your own peace of mind or for a client asking what you're actually watching for, that's the real value: not certainty, but a documented, continuous, honest attempt at it — which turns out to be far more than most networks get.
What to do with a flagged CVE
When something does get flagged, the right response isn't panic and it isn't dismissal — it's a quick, specific check. What's the device, what's the exact vulnerable version or configuration the CVE describes, and does what's actually running match closely enough to take seriously. Most of the time it will, and now you have a documented, dated starting point for patching or mitigating it, instead of finding out the hard way months later. Occasionally it won't, and now you've spent five minutes confirming that instead of finding out never.
Either outcome is strictly better than the alternative most networks are actually running on, which isn't "we've confirmed nothing's vulnerable" — it's "we've never checked." A flagged CVE that turns out to be a false positive still cost you almost nothing. A real one that never got flagged at all could cost considerably more, and that asymmetry is exactly why continuous, imperfect scanning is worth having even on the days it gets something wrong.
Born in Colwyn Bay North Wales, Steve's introduction IT & Computers was at secondary school in 1974. That first year, Machine Code was hand written onto gridded paper and sent to Connah's Quay Technical College where is was copied to punch card and then entered into a mainframe computer. The results printed out were sent back for the following week! Yes Steve was around before the Internet and was coding the hard way.
Steve left School in 1976, or as he prefers to say, “I ran away from home and joined a flying circus” - joining the Royal Air Force to work as an Electronics Engineer on analogue and digital RADAR and communications equipment. His last 5 years in the RAF he worked in an Automatic Test Equipment (ATE) department on the System Management Team and also writing models for Microchips. It was a good job that he had kept up with computers which had become rather a passion by the time he started in ATE. After 8 specialist programming courses for ATE Programming and a Cluster Start Course for System Administration, Steve was one of the most flexible people in the department.
During that time the main Mainframe we replaced in a £3.9 million upgrade reducing the run time of the biggest ATE program from just under 2 weeks to the time it took for a finger to come off a depressed return key!
Leaving the RAF after 18 years’ service, Steve worked for a Charity (Apex Leicester Project) before returning to electronics at Sonatest in Milton Keynes which after 3 or 4 years led to a Job at Telematica; the then development arm of Trafficmaster PLC (Tm). Eventually brought in-house at Tm he worked moved into the IT Support Team of 5 people looking after 300 users in the UK as well as sites in Italy, Germany and Benelux countries – 24x7 cover. His last project moving email from a Linux Box to Microsoft Exchange for the 300 users in the company each of whom typically had 5 email addresses.
In 2006 Steve left to start his own company back in North Wales, Computer Technical Solutions Ltd (CTS) was an MSP and became an MSSP following another of Steve's passions Cybersecurity. Whist working full time running CTS, Steve completed a Masters Degree in Computer Science with Cybersecurity at Wrexham University.
Officially semi-retiring in 2025, by May 2026 that overactive mind started thinking about all of the software he had seen not just for MSSPs but also for his clients that was either extremely expensive or that didn't exist with a complete answer to the needs of the SME.
By August 2026 Angstep Ltd was formed and two significant pieces of software had been created. Netmon the Network Monitoring Software and the second release Parkcore aimed at Caravan/Lodge Holiday Parks, now in the final development stages and under Beta Release. Determined, focused and loving life… And so, it begins!
