What a network scan can't see inside your customer's firewall

CISA's emergency directive on Cisco ASA and Firepower devices, issued in September 2025, opened with a chore: identify every instance in your environment. For a handful of firewalls, that's an afternoon. For a telco or a bank with gear spread across dozens of sites, it's a project, and it raises a question most security programs have never had to answer. What software is actually running inside the devices we own?

Your customers probably have a vulnerability management program. It scans the network, matches versions and banners against CVE lists, and feeds a ticket queue. That works well for what it can see.

What a scan sees and what a firmware image holds

A network scan looks at a device from the outside. Firmware composition analysis opens the image and lists what's inside. They answer different questions, and mature programs often fund only the first.

It helps to keep four terms apart:

• Network scanning finds what answers on the wire and compares it to known vulnerabilities.
• Firmware composition analysis unpacks the shipped image and identifies the components in it, including libraries linked in at build time that never open a port.
• An SBOM (software bill of materials) is the resulting inventory. One built from the artifact can disagree with the one a supplier hands you.
• Reachability and exploit data rank the findings: is the code executed, is it reachable from the network, is it on CISA's Known Exploited Vulnerabilities list.

NetRise studied 100 networking devices (routers, switches, firewalls, VPN gateways and access points) and found an average of 1,267 components and 1,120 known vulnerabilities per device. About 20 per device were weaponized, and 7 of those were reachable over the network. That's vendor research on a small sample, so treat it as a rough shape: over a thousand findings per device and a handful that matter.

Why telcos and banks feel it first

Telecom operators run multi-vendor networks on equipment that stays in service for years, and much of it sits at the edge. After Salt Typhoon, CISA, NSA, FBI and partner agencies published hardening guidance for communications infrastructure in December 2024. It says the compromises it examined lined up with existing weaknesses in victim infrastructure, with no novel activity observed.

The broader data points the same way. In the 2025 Verizon DBIR, edge devices and VPNs rose from 3% to 22% of vulnerability-exploitation breaches, and only 54% of those flaws were fully fixed, with a median of 32 days. The 2026 edition put exploitation ahead of stolen credentials as the top way in.

Banks have the mirror problem. Security appliances, network gear, ATMs and payment terminals come from a short list of suppliers, and the bank didn't write a line of their firmware. Supplier attestations and questionnaires describe a moment in time. Auditors increasingly want evidence, and NetRise can supply the underlying evidence from the software itself. It doesn't make an institution compliant, so ask which standards your customer is actually audited against.

What the incidents do and don't show

In ED 25-03, attackers exploited two zero-days and modified ROMMON on ASA 5500-X units without Secure Boot, so the implant survived reboots and software upgrades. Firmware composition analysis wouldn't have detected that implant or stopped the exploit. That's forensics and runtime territory.

What it could have helped with is the directive's first step: which devices carry the affected software, across which sites. In a large fleet, that's the slow part.

Where NetRise fits

NetRise Turbine analyzes compiled firmware images, appliances and applications without source code or supplier participation. It builds the SBOM from the artifact, ranks vulnerabilities by reachability and exploit data, and flags risk with no CVE attached, such as hard-coded secrets, weak keys and misconfigurations. NetRise Provenance covers the open-source side: who maintains a component, and how far a compromise travels.

It sits next to EDR, SIEM and vulnerability management. It doesn't detect attacks, doesn't patch anything, and needs the firmware image to analyze. Fixes still depend on what the supplier ships.

What a broadband provider did with it

NetRise published a customer story about a global broadband solutions provider that builds devices for service providers. It had OEM firmware to validate before release, no source code, and QA engineers who needed to know what mattered. Each release candidate now goes through binary analysis as a standard QA step, ranked by network accessibility, KEV listing, EPSS score and execution-aware reachability.

The story reports qualitative results: repeatable analysis, sharper prioritization, and conversations with OEM and chipset partners that run on evidence instead of speculation. It gives no figures, so we won't either.

Two lessons carry over to your accounts. The analysis stuck because it became a step in a workflow the team already ran. And the provider credited its choice partly to onboarding: a dedicated demo environment and instruction on reading the results. An operator or bank on the receiving end of vendor gear faces the same triage problem, and the same services gap.

The conversation to have

Four questions open it:

• Can you list the software components inside any one vendor device you run?
• When a disclosure lands, how do you learn which devices it affects, and how long does that take?
• What verifies a supplier's claims today: a questionnaire, an attestation, or the artifact?
• Who triages firmware findings, and what do they use to rank them?

Partners can build services around the answers: a product visibility workshop, an assessment of a sample of devices, help interpreting and ranking results, and re-analysis when firmware or disclosures change. Those are services you'd design and price yourself. NetRise provides the analysis platform, and it lists a managed offering too, so ask us what that covers. Not every account will want any of this. The ones running lots of vendor gear under audit pressure probably will.

Want to test the conversation on a real account? Talk to our DLX team about a partner demo, bring a customer scenario, and we'll walk through what a firmware analysis would produce and what services could sit around it.