See What Changed. Prove What Improved. Fix Real Risk.
Security teams can analyze a single firmware image. What they can’t easily see is what changed between versions.
Every release can introduce improvements, regressions, and new risk. Vulnerabilities are patched, new components are added, configurations shift, and risk evolves. Most teams are left comparing reports manually, trying to answer basic questions:
- What actually changed between versions?
- Did this release reduce risk, or introduce new exposure?
- Can we prove remediation progress over time?
The process is slow, inconsistent, and doesn’t scale.
NetRise Asset Diffing eliminates that gap.
Compare Versions Without the Guesswork
Security analysis often breaks down when trying to answer a simple question: what's different?
Asset Diffing lets teams select any two versions of a firmware or software asset — sequential releases, non-sequential versions, or pre-release builds against prior production versions — and immediately see categorized changes across vulnerabilities and SBOM components. Risk trends become visible across asset versions.

Each change is clearly labeled:
- Added → Introduced in the latest version
- Removed → No longer present
- Unchanged → Persists across versions

Teams can immediately spot regressions, validate fixes, and track security posture consistently across product families.
Versioning becomes actionable instead of archival.
One Release Looks Good. Trends Tell the Truth.
Security teams also need to understand how risk evolves over time.
Asset Diffing introduces trend visibility across versions, including CVE counts by severity; added, removed, or unchanged vulnerabilities, and changes in software composition.


These trends show whether security posture is improving or drifting.
And when something changes, teams can drill down to understand exactly why.
What a Real Comparison Report Shows
Here's what this looks like in practice.
Excerpts below from the NetRise platform’s downloadable PDF report compare two firmware versions — V3.0.3 and V3.7.0 — across the same device. The result is a structured, evidence-backed view of exactly what changed.
The Vulnerabilities tab breaks down exactly what was added and removed between versions — by severity, CISA KEV status, and whether findings are weaponized or have proof-of-concept exploits.
On vulnerabilities alone, the newer version shows a 15% overall improvement: 930 fewer total CVEs, with High severity findings dropping by 281 and Medium by 622. Critical-severity count held flat at 37 — a clear signal that while significant remediation occurred, the most severe findings still require attention.
The report also surfaces what improved beyond raw CVE counts. Misconfigurations dropped by 3. Cryptography findings fell by 2. Credential exposures decreased by 3. Each of these represents a discrete, verifiable change — not an estimate, not a trend line, but a specific finding that was present in one version and resolved in the next.
Not everything improved. PoC (Proof of Concept) exposure increased by 39%, and CISA KEV count ticked up slightly. This is exactly the kind of regression that trend reporting is designed to surface before it becomes a liability, and the kind of finding that would be invisible in a point-in-time analysis of only the newer version.
This is what remediation validation looks like when it's built on evidence, not attestation.



The SBOM tab shows the same for software composition: which components were introduced, which were removed, and what two versions have in common.
Both views are explorable in the platform and exportable in a single report. Teams can use these reports for compliance audits, customer security reviews, and internal release validation without manually assembling evidence across versions.
The SBOM comparison tells its own story. Between V3.0.3 and V3.7.0, 62 components were added and 39 were removed, for a net gain of 23. The binary count grew by 65. That's not incidental — it's the software composition of this device changing in ways that affect risk, compliance obligations, and downstream license exposure. Without a diff, none of it is visible.
Turn Versioning Into a Security Advantage
Firmware and embedded software have always been difficult to analyze.
Asset Diffing makes change itself visible.
Instead of asking whether a release is better or worse, security teams can now answer with precision:
-
What changed
-
What requires attention
-
What to fix next
And just as importantly, they can prove it.
Frequently Asked Questions
What types of assets can be compared with Asset Diffing?
What does Asset Diffing actually show you?
How is Asset Diffing different from just comparing two scan reports?
Manually comparing scan reports requires stitching together outputs from different runs, normalizing findings, and reconciling inconsistencies — a slow process that rarely scales across product families or release cadences. Asset Diffing does this automatically inside the platform, with consistent categorization and trend data that spans the full version history of an asset, not just two isolated snapshots.
Stay up to date with the news
Sign Up To Get Our Free Insights Delivered To Your Inbox
Recent Press Releases
Stay up to date with the latest official announcements and corporate milestones from NetRise.
