No. Edge device statistics, such as time to patch VPNs and firewalls, describe a narrow class of internet facing appliances. They say little about library updates, server patching or container images, which run on different owners, tools and risk profiles. Measure each layer separately.
What the headline edge figures cover
The 2025 Verizon DBIR drew attention to vulnerabilities in VPNs and edge devices. Press coverage reported that 54% of edge device vulnerabilities were fully remediated within a median of 32 days (Infosecurity Magazine). Tenable's companion analysis looked at 17 edge device CVEs, all on the CISA known exploited list (Tenable).
Those are high value targets and a deliberately chosen set. They are useful for edge priorities.
Why other layers behave differently
| Layer | Who patches | What slows it | Typical tooling |
|---|---|---|---|
| Edge appliance | Network or infrastructure team | Maintenance windows, vendor firmware | Vendor advisories |
| Server OS | Operations | Reboots, change control | Patch management |
| Application dependencies | Developers | Breaking changes, tests | Dependency scanning |
| Container images | Platform or developers | Rebuild and redeploy | Image scanning |
| Cloud services | Provider and you | Shared responsibility | Provider notices |
Each row has its own bottleneck. A team that patches firewalls in a week can still leave a vulnerable library in production for months, because the work sits in a different queue.
What to measure per layer
- Median and 90th percentile days from patch release to verified fix.
- Percent fixed within the target window.
- Count and age of the oldest open items.
- Coverage: the share of assets in the measurement.
Why not one blended number
A blended figure is dominated by whichever layer has the most items, usually dependencies and images. It will hide a slow edge process or a fast one. Report by layer, then summarize with the worst layer in view.
Inventory first
Dependency and image layers are the ones most teams cannot enumerate quickly. A software bill of materials gives you the list, and reachability analysis shows which vulnerable components your code actually calls. That is how you decide what to fix first in a layer that otherwise looks overwhelming. Safeguard does both, and the free scan at gold.safeguard.sh/scan is a quick way to see your dependency layer.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how many components a single application carries and how they are listed.
A practical split
For each layer, name an owner, an inventory source and a target. Edge devices might have a short target tied to known exploitation. Dependencies might have a target tied to reachability. Images might be tied to rebuild cadence. Different targets are fine as long as each one is written down and measured.
Quick check
If my edge devices are fast, am I fine?
Not necessarily. Other layers have separate owners and delays. Measure each one.
Why are edge devices in so many reports?
They are internet facing and have been used in many attacks, so they feature in breach data and exploited vulnerability lists.
Sources
- Infosecurity Magazine, Verizon DBIR reveals jump in vulnerability exploitation
- Tenable, Verizon 2025 DBIR research collaboration on CVE remediation trends
Last reviewed: 19 October 2026.
