Video ASM and vulnerability management
Vulnerability management assumes you know what you have and that published vulnerability data describes it. For video estates, both assumptions fail — and the second fails in a way that produces false comfort.
Vulnerability management is a mature discipline with good tooling. Applied to a video estate it runs into two problems, and only the first is widely understood.
Problem one: the scanner has to know the device exists#
A vulnerability management programme operates on an asset list. If the cameras are not on it, the programme is complete and silent about them simultaneously.
This is the ordinary scoping problem, and it is solvable: add the ranges, add the credentials, run the scans. It is genuinely the easier of the two.
There are complications worth knowing about. Credentialed scanning, which is what makes vulnerability management accurate for servers, generally does not work here — most cameras offer no mechanism for it. Unauthenticated scanning of embedded devices carries a real risk of disruption: devices in this class have historically responded badly to aggressive port scanning and protocol fuzzing, and a scan that reboots a recorder during an incident is worse than no scan. And a scanner's fingerprinting of embedded devices is frequently wrong at the model level, which matters when the CVE mapping depends on it.
None of that makes scanning useless. It makes it one input rather than the input.
Problem two: the vulnerability data is structurally incomplete#
This is the one that produces bad decisions, because it produces a clean report.
A vulnerability management programme's output is only as complete as the vulnerability database behind it. For mainstream server and application software, that database is a reasonable approximation of what is known. For video products it is not, for reasons that have nothing to do with the products' actual quality:
Many vendors do not assign CVEs. Publishing a security advisory and requesting a CVE identifier is a deliberate process a company has to invest in. Some video vendors run a mature product security function and publish consistently. Others publish advisories with no CVE. Others publish nothing, and fix issues silently in a firmware release whose notes say "improvements and bug fixes".
CPE identifiers for these products are inconsistent. The mapping from "this device" to "this entry in the vulnerability database" runs through a CPE string, and for camera products those strings are irregular — the same vendor appears under multiple names, hardware and firmware are separate entries, and model naming does not follow a scheme. A scanner that fingerprints a device correctly can still fail to match it to the vulnerability, and a vendor can appear to have almost no vulnerabilities because their products are catalogued under a name nobody queried.
Component vulnerabilities are rarely attributed to the device. Where a camera embeds a vulnerable third-party library, the CVE names the library. Unless the vendor issues its own advisory saying "our product contains this", no scanner will connect the two.
The practical consequence: a low CVE count for a product is not evidence that the product is sound. For several vendors it is evidence that they are not in the system. A vulnerability management programme that ranks vendors by CVE count will systematically favour the vendors who disclose least.
What Video ASM adds#
Given the above, the framework treats published vulnerabilities as one of four independent assessment inputs rather than as the assessment:
Lifecycle position is often more decisive than any individual CVE. A product past end of support has no route to remediation for anything found in future, which is a permanent condition rather than an open finding.
Configuration — shared credentials, unnecessary services, unencrypted management — produces more real-world compromise in this asset class than published vulnerabilities do, and none of it appears in a CVE feed.
Exposure, in both directions. Inbound reachability changes what a vulnerability means. Outbound cloud connectivity is a security-relevant property that no vulnerability scanner reports because it is not a vulnerability.
Ownership, which is not a security property at all until you need something changed.
Where vulnerability management is simply better#
Two places, and they are important.
For the VMS servers — Windows or Linux machines running video-management software, database engines and web services — conventional vulnerability management is exactly right, and often better than anything a video-specific programme would do. These are ordinary servers. Scan them like ordinary servers.
For prioritisation signal quality, the vulnerability management world has built things the video world has not: exploitation catalogues, exploit-prediction scoring, and a shared vocabulary for severity. The framework's prioritise stage borrows all of it rather than inventing an alternative.
The summary#
| Vulnerability management | Video ASM | |
|---|---|---|
| Input | An asset list you already have | The estate, discovered from physical and operational sources |
| Primary evidence | Published vulnerabilities | Vulnerabilities, lifecycle, configuration, exposure |
| Assumes | The vulnerability database describes your assets | It does not, and says so |
| Fails silently when | The asset is not in scope | — (the coverage gap is the reported output) |
| Handles VMS servers | Well | Defers to vulnerability management |
| Handles cameras | Partially, with fingerprinting and coverage caveats | This is the scope |
If you run vulnerability management over your camera estate and it returns few findings, the correct interpretation is usually that you have measured your coverage, not your risk. Per-product vulnerability history, including which vendors publish and which do not, is catalogued on CameraRisk.