Everything on this site is derived from public sources by a deterministic pipeline. No entry is written by hand, and no field is estimated. This page describes how the derivation works, so that a wrong record can be traced to the step that produced it.

Sources#

Three, all public and all dated.

NVD (National Vulnerability Database). The CVE records themselves — description, CVSS scores, weakness classifications, references, and the CPE configuration that states which products are affected. Retrieved through the NVD CVE API 2.0.

CISA Known Exploited Vulnerabilities catalogue. Whether a vulnerability has confirmed exploitation in the wild, when it was added, whether CISA records ransomware campaign use, and the remediation date set for US federal civilian agencies. The catalogue version used for the current build is shown in the footer of every page.

FIRST EPSS. A modelled probability that a vulnerability will see exploitation activity in the next 30 days, with the date the score was calculated. EPSS is a forecast, not an observation, and is labelled as such wherever it appears.

Which vendors are in scope#

The list of vendors is curated by hand, and this is the step most likely to be wrong.

CVE records identify products by CPE identifier, which contains a vendor token. Those tokens do not reliably match brand names. Dahua's products are catalogued under dahuasecurity, not dahua. Hanwha's appear under hanwhavision and two other spellings. Xiongmai's are under xiongmaitech.

We built the vendor list in two passes. First, every candidate token was queried against NVD to see whether it returns results at all. Second, NVD's CPE dictionary was searched by brand name to find the tokens the first pass missed.

The second pass returns noise, and the noise is instructive: searching for "genetec" returns genetechsolutions, which is a WordPress plugin author with no connection to Genetec. Searching for "milestone" returns apache, pivotal_software and eclipse, because the word appears in their product descriptions. Following that output automatically would have attributed thousands of unrelated vulnerabilities to video vendors. Every token is therefore reviewed by hand before inclusion, and rejected tokens are recorded with the reason.

Which products are in scope#

Some vendors in the list make only video equipment. For those, every product in their CPE namespace is included.

Others — D-Link, TP-Link, NETGEAR, Synology, QNAP, Bosch, Honeywell and several more — make video products alongside routers, storage appliances or building controls. Including their whole namespace would attribute router vulnerabilities to a camera vendor. For these, only products matching an explicit pattern list are included, and the count of excluded products is published on the coverage page rather than hidden.

This filter will have both false positives and false negatives. A camera product whose model name matches none of the patterns is missing from this site.

How a product page is assembled#

For each CVE, NVD's configuration section lists CPE match rules. Each rule names a vendor, a product and often a version or version range. We read those rules and record, for every product in scope, which CVEs name it and which version strings were specified.

Two details worth knowing:

Hardware and firmware are separate CPE entries. A camera typically appears twice — h:vendor:model for the hardware and o:vendor:model_firmware for the firmware, joined by an AND relationship. We merge these into a single product and take version strings from the firmware entry, which is where they live.

Version coverage is not completeness. The versions listed on a product page are the versions named in CVE records. A version absent from that list has not been assessed and found clean — it has simply never been named. Product pages state this explicitly rather than presenting the list as a firmware history.

Product names#

Display names are derived mechanically from the CPE product token: underscores become spaces, a trailing _firmware is dropped, tokens that look like model codes are upper-cased, and word-like tokens are title-cased. The raw CPE identifier is printed on every product page so the derivation can be checked.

We do not look up marketing names, and we do not correct the derivation by hand. A name that looks wrong is a faithful rendering of what NVD holds, which is more useful than a name we improved silently.

What is deliberately absent#

Several fields that would make this site more useful have no reliable public source, so they are absent rather than estimated:

• End-of-life and end-of-support dates. Some vendors publish lifecycle policies; few publish machine-readable per-model dates.
• Default credentials. Widely circulated, rarely authoritative, and frequently out of date.
• Shipped network services and default ports. Vendor documentation covers this inconsistently and it varies by firmware version.
• Deployment counts or exposure figures. We do not scan the internet and do not republish scan data as though it were ours.

Where a page shows an "experimental risk indicator", it shows the components separately and names the ones with no source. Two of the six have no source for any product on this site, which is why there is no single score.

What the counts do and do not mean#

A high CVE count usually means a product has been studied. Researchers pick targets that are popular, cheap to obtain, or already known to be interesting. A product with twenty CVEs has had twenty things found and fixed; a product with none may simply never have been examined.

A low count may mean the vendor does not participate in the CVE system. Publishing advisories and requesting CVE identifiers is a deliberate investment. Vendors who fix issues silently in firmware releases appear here as having few or no vulnerabilities.

Ranking vendors by CVE count therefore rewards the ones who disclose least. We publish the counts because they are the fact we have, and we say this on every vendor page because the fact is easily misread.

Rebuild cadence and errors#

The dataset is rebuilt from source rather than edited. The build date appears on every page, and the KEV catalogue version and EPSS date appear in the footer.

If a record here is wrong, it is either wrong upstream or wrong in one of the steps above. Either way we would like to know: data@camerarisk.com. Corrections that originate upstream will be reported upstream and noted here.

Who publishes this#

CameraRisk is published by the same small editorial project as three related sites: VideoCybersecurity for reference guides, VideoSOC for advisories, and VideoASM for the attack-surface framework.

That is stated here because common ownership between linked sites should be disclosed rather than inferred. The four share this sourcing standard and the build system underneath them. They do not share content, and there is no site-wide link block between them — cross-links appear only where following one is genuinely the next thing a reader would want, which on a product page is usually nowhere.