How Many Vulnerabilities Do You Expect on a New Device? Zero? Think Again.

You unwrap a new device, plug it in, and check the report. No CVEs. Clean. Secure… right? Not so fast.

No CVEs doesn’t mean no risk; it just means nothing has been flagged so far. That clean slate can lull you into a false sense of security, especially if you’re relying on scanners that only see what’s already mapped and published.

The real blind spot? It’s not just missing CVEs. It’s missing CPEs, Common Platform Enumerations, the identifiers that scanners rely on to link software or firmware to known vulnerabilities in the first place.

The CVE-to-CPE Dependency

CVEs don’t work in isolation. They need CPEs, the identifiers that tell scanners, “this piece of software is the one linked to that vulnerability.” Other identifiers exist, like PURLs (Package URLs), which are becoming common in SBOMs for tracking individual software components. But while PURLs are useful at the package level, they don’t provide the same kind of device-level mapping that CPEs do. Because whole devices and firmware ship as complete systems, missing CPEs create some of the biggest blind spots.

If a device ships without CPEs, and without PURLs at the component level, the scanner can’t make the match, even if the vulnerable code is sitting right there in the software. That’s how you end up with a false sense of security.

Why New ≠ Secure

New devices, like new software versions, can introduce risk as well as reducing it. They often reuse unpatched third-party components, ship with misconfigurations baked into firmware, or contain hidden hardcoded credentials and debug interfaces. Because they haven’t yet been examined by researchers or red teams, they escape early scrutiny. The absence of CPEs and related CVEs doesn’t mean the code is clean; it simply means the code is unverified.

Why Binary Analysis Fills the Gap

This is where traditional SBOM tools and signature-based scanners fall short. Without a known CPE string, they can’t detect anything, even if the binary contains vulnerable code. That’s why binary analysis is critical.

With NetRise, you can:

• Generate SBOMs directly from the firmware, even without source code  access.
• Detect components missing CPEs but known to include risk.
• Flag hardcoded secrets, outdated libraries, or embedded exploits.
  
• Identify reused software packages across product lines or vendors.

With binary analysis, you don’t have to rely on declared CPEs. NetRise goes deeper, inspecting the software itself to reconstruct what's actually present. By fingerprinting libraries and components directly from the binary, even when they’re statically linked, renamed, or missing identifiers, the platform can recognize vulnerable code regardless of whether a CPE was ever assigned. And unlike identifiers of any kind, whether device-level like CPEs or component-level like PURLs, binary analysis isn’t dependent on what metadata exists. 

Those fingerprints are matched against multiple data sources, from CVE databases to threat intelligence feeds, using both exact version matches and fuzzy techniques that detect known vulnerable code patterns. NetRise also draws on compiler artifacts, function signatures, and build metadata to connect binaries back to their upstream packages. The result: even if a new device ships without CPEs or PURLs, NetRise can still identify vulnerable components and map them to CVEs that traditional scanners would completely miss.

But missing CPEs aren’t the only blind spot. Even when identifiers exist, traditional scanners still fail to capture what actually shipped. That’s because they analyze manifests and declared dependencies, the developer’s intent,  rather than the binary itself. Build processes systematically insert risk through static linking, vendored libraries, transitive dependencies, and insecure defaults. The result is the same: your source-code derived SBOM looks complete, but the binaries tell a different story. Binary analysis closes both gaps, the CPE/CVE lag in new devices and the hidden flaws baked in during the build process.

A Real-World Blind Spot

Within the NetRise platform, we routinely analyze new devices that appear “clean” to conventional scanners, only to uncover vulnerable components with known CVEs that go undetected due to missing or incorrect CPE mappings.

If you’re shipping new devices, inheriting firmware from upstream partners, or onboarding new vendors, relying solely on CPE-linked scanning introduces real risk.

Takeaway: New Devices Need the Same Scrutiny

Don’t let the absence of CVEs lull you into a false sense of security. The CPE system has a time delay and new devices often slip through the cracks. The only way to know what’s in your code is to look directly at the firmware itself.

NetRise helps you close that gap with deep binary analysis, software origin tracking, and enriched vulnerability context, even when CPEs are missing and CVEs haven’t yet been assigned.

For device manufacturers and global organizations alike, no CVEs doesn’t mean no risk. NetRise provides the binary-level visibility to close the gap, giving enterprises confidence in what they onboard, and manufacturers evidence in what they ship.