What Software Updates Can Still Get Wrong

In the 2020 SolarWinds breach, attackers infiltrated thousands of networks not through an initial software install, but through a routine software update that went unquestioned. That single version change became one of the most devastating supply chain compromises in recent history.

New Version, Less Risk? Think Again

In cybersecurity, a persistent myth is that software updates automatically reduce risk. The assumption is simple: new versions mean patches, and patches mean protection.

But most updates introduce more than just fixes. They add features, shift dependencies, and often increase complexity. Even small updates can introduce new libraries, dependencies, or third-party code, changes that may not be obvious from outside the build process.

Each new element represents more code running in your environment. Without inspecting what changed, you're relying on blind trust.

What’s in a Patch, Really?

Version updates often go far beyond simple fixes...

A typical patch can introduce new third-party dependencies or update existing ones, each carrying potential vulnerabilities. A patch may change the logic or flow of the application’s code, affecting how it processes data or handles access. Configuration defaults might be altered, sometimes enabling features or behaviors that were previously disabled. Updates often modify the tooling or packaging used to build the software, which can subtly shift how it behaves in different environments. Even the compiled binaries themselves can change in ways that affect performance, metadata, or behavior.

These changes don’t just update the software, they reshape its security posture. If those differences go unexamined, the risk doesn’t go away. It quietly grows.

Why Update Security Matters

Most organizations conduct security reviews when they onboard new software. They request a Software Bill of Materials (SBOM), assess risk, and check for regulatory compliance.

But what happens after the first deployment? When version 2.0 is released? Or when an update is silently pushed to a system already in production?

In many cases, nothing happens. Software artifacts change and SBOMs are not regenerated to reflect these updates. 

The updates are treated as safe, even though they may introduce risks that were never present in the original software.

Attackers Exploit the Gaps

Adversaries target the exact places defenders ignore, especially in the update cycle. According to Gartner, costs stemming from software supply chain attacks will grow from $40 billion in 2023 to $138 billion by 2031. These attacks often exploit code introduced in post-deployment updates that were never re-evaluated. They prey on a common systemic vulnerability: trusting that every update is safe, simply because it comes from a known vendor.

You Can’t Manage What You Can’t See

Here’s the turning point: Security isn’t just about what software was intended to include; it’s about what it actually contains when deployed. And that difference often comes down to what happens during the build process.

Even if source code appears clean, vulnerabilities can be introduced during compilation, linking, or packaging. This includes hardcoded credentials, misconfigured binaries, injected code, and unintended components added by third-party tooling or automation. 

These risks don’t appear in source code or SBOMs derived from source code. They only emerge when you analyze what actually executes. That’s why compiled software inspection is essential: it exposes tampering, build drift, and misconfigurations introduced during the compilation and packaging process, risks other methods often miss.

Best Practices for Version-Aware Risk Management

The good news? There’s a clear path forward.

To reduce risk as software changes, organizations, whether building software or relying on third-party vendors, should adopt practices that support continuous inspection and validation.

If You Build Software

Organizations that create, integrate, or manage their own software should:

• Maintain a living SBOM
  A static SBOM becomes outdated after a subsequent software update. Generate fresh SBOMs for each new version to track components accurately.
  
  
• Automate the detection of version changes
  Use tools to compare vendor-supplied software across versions—even without source access—to flag drift and unauthorized changes.
  
  
• Require risk reviews with every version update
  Treat each release as new software, and perform security and compliance checks based on the scale and nature of the changes.
  
  
  

If You Buy or Deploy Software

Security teams responsible for third-party software can:

• Request or regenerate SBOMs on every update
  Ask suppliers to provide updated SBOMs, or generate your own to track changes and spot hidden components.

• Automate the tracking of changes between releases
  Use security tools to compare releases of vendor-supplied software and identify hidden changes, even without access to the build process.

• Inspect what’s running in your environment
  Analyze deployed firmware and binaries to uncover risks introduced during packaging, delivery, or post-deployment updates.

Even without full visibility into the build process, your team can independently validate what changed, or require vendors to prove it.

Don’t Trust Blindly

If you wouldn’t deploy software without a security review the first time, why trust the next version without scrutiny?

Modern software evolves constantly. Updates aren’t inherently safer; they’re only newer.  Reviewing every change is the only way to ensure new versions don’t introduce new vulnerabilities.

NetRise Helps You See What Changed

NetRise enables organizations to deeply inspect every version of their software—firmware, containers, applications—and understand what’s changed between releases. Tools like NetRise Trace help organizations verify what’s changed between versions, detect tampering or unauthorized modifications, and confirm that delivered software matches expectations—even when the source isn’t available.

With this visibility, you can catch vulnerabilities and misconfigurations introduced in updates—before they’re exploited.

SolarWinds Was Not a Fluke

The SolarWinds breach didn’t begin with malicious new software. Rather, the breach started with a trusted update that bypassed scrutiny. 

Don’t assume an update is safe. Prove it.

In the end, it’s not about trusting the update. It’s about verifying what changed. That’s how you stay ahead.

Learn more about how NetRise delivers the visibility to make that possible.