Modern vulnerability management (VM) programs rely on scanners to build asset inventories, collect system metadata, and track known Common Vulnerabilities and Exposures (CVEs) across an organization’s infrastructure. Tools like Tenable, Qualys, and Rapid7 help you monitor patch posture and exposure across the software your scanner can see in servers, devices, applications, and cloud workloads.
These scanners excel at OS and OS-package vulnerabilities but lack deep insight into application-layer components, such as embedded libraries and custom application code. Vulnerability scanners do not examine the compiled binaries running inside devices, which leaves entire categories of software risk unexamined.
As the VM infographic shows, this view represents only the visible portion of your software attack surface. Beneath that visibility line lies the code your organization actually runs and other artifacts found in the binary package. The compiled software inside devices and applications often contains hidden components, inherited libraries, and non-CVE weaknesses that traditional scanners never inspect. Attackers look in those places first.
Where Traditional VM Stops: Surface Oversight
Most VM platforms, operating at the OS and application layer, rely on what the system can enumerate, such as installed packages and known service configurations. As a result, their view of software is shaped by:
- Package metadata visible to the operating system
- CVEs tied to documented components
- Version and patch information from package managers
- Declarations provided by software vendors
This approach works for software that cleanly reports its components, but it misses exposures buried inside compiled code. Attackers understand that gap and target the layers scanning tools cannot see.
What’s Beneath the Surface: Evidence, Not Metadata
Every software package, application, or firmware image contains compiled components that scanners rarely detect. This includes configuration artifacts, inherited dependencies, and compiled functionality the operating system does not report. They remain hidden until you analyze the compiled software itself, the code that actually executes.
NetRise begins at that deeper layer.
What NetRise Reveals Inside the Software You Rely On
NetRise ingests compiled software artifacts from any vendor, including firmware, applications, or other binaries, and uncovers the exposures traditional scanners cannot reach. NetRise identifies:
- Secrets, keys, and credentials inside binaries
- Misconfigurations inside compiled services and processes
- Outdated or vulnerable libraries not visible to the operating system
- Components missing from vendor Software Bill of Materials (SBOMs) or product documentation
- Non-CVE weaknesses that increase exploitability
What the Scanner Can’t Tell You
Most scanners can confirm whether a package version contains a known CVE. NetRise goes further. NetRise reveals whether that component appears in the compiled software at all, whether it loads at startup, whether it exposes network-reachable functionality, and whether the component introduces real exposure inside the software.
Case in Point: When a Scanner Says “Patched,” but the Software Isn’t
When the F5 BIG-IP security incident surfaced, vulnerability management teams saw a familiar pattern: surface visibility did not reflect the true state of the software running in critical infrastructure.
F5’s appliances are deployed across some of the world’s largest networks. Their software is routinely scanned, monitored, and patched by customers who depend on those systems for load balancing, security, and availability. Yet despite this visibility, a nation-state actor maintained long-term, persistent access to F5’s BIG-IP product development environment and engineering knowledge platforms before the compromise was detected in August 2025 and disclosed in October 2025. After disclosing the incident, F5 released fixes for 44 vulnerabilities across its product portfolio in a single, coordinated update.
For vulnerability management programs, that combination of a development-environment breach and a concentrated patch set highlights two hard truths.
- VM scanners only see what the platform exposes.
Customer tools generally see F5 appliances from the outside in: the network footprint, a limited operating system view, and whatever package metadata or management interfaces the platform exposes. They do not typically unpack appliance firmware images or inspect all compiled binaries inside. Many of the weaknesses that F5 remediated lived in those binaries and inherited components. From the customer side, they remained largely invisible until F5 documented them in security advisories and CVEs. - Vulnerability data tied to package or source metadata can misstate real risk.
Source SBOMs and package inventories describe what developers intended to ship. Binary analysis describes what actually shipped. A VM scanner or SBOM that only sees package or source versions can report “patched” while a vulnerable library is still baked into a binary, statically linked, or embedded in firmware. Even when the scanner’s view of components is accurate, it may not be complete, which leads to an incomplete and sometimes misleading picture of exposure.
NetRise’s analysis of a released BIG-IP Next firmware image uncovered hundreds of security weaknesses, including components that execute at startup and exposed reachable attack paths. Those findings came entirely from the compiled firmware image, with no access to F5’s internal systems or proprietary source code. For many customers, these risks were present in the software they relied on but were invisible to traditional network-based or OS-level scanners.
The F5 breach is a reminder that VM functions must also consider that real exposure can also live inside compiled software.
A “Better Together” Model for Vulnerability Management
Traditional VM tools remain central to your program. They track patch posture, measure exposure, and support enterprise-scale remediation workflows.
NetRise strengthens one critical dimension of that ecosystem: the accuracy and completeness of the software you scan.
Paired with NetRise, your VM program can:
- Confirm whether declared components actually exist in the software
- Identify outdated or vulnerable libraries hidden in compiled code
- Expose issues scanners classify as “not present”
- Prioritize remediation based on components that actually execute
- Validate software inventories with evidence from the binary itself
- Reduce uncertainty when reporting exposure to leadership
NetRise does not replace your scanners. NetRise finds what scanners cannot see.
Seeing the Whole Attack Surface
Your VM program sees what the operating system reports. NetRise reveals the rest, including the compiled code, hidden components, and exploitable weaknesses that define real-world exposure.
The next generation of VM will depend on what you can verify, not what is declared. By pairing surface scanning with binary evidence, organizations gain a more complete and defensible view of software risk.
Need quick help? Chat now with a Real NetRise Expert
Click here➡
No slack account needed
