What is a compromised software update?¶

A compromised software update is an update whose development, packaging, signing or delivery path has been abused so that it carries unauthorised code or content. It can look legitimate because it arrives through the vendor or an organisation's normal deployment process.

Receiving the update does not by itself prove that a system was compromised. Exposure, installation, execution and resulting activity are separate findings.

One update can produce different outcomes¶

An affected device may have downloaded the package without installing it, installed it without triggering the malicious component, or blocked it. Different devices may have received different versions or used different delivery channels. Malicious code may also activate only when a particular configuration, environment or later command is present.

For each system, establish where possible:

• the package version and hash;
• its source and download time;
• whether and when it was installed;
• whether the relevant component executed; and
• what process, file, account or network activity followed.

Software inventory usually supports only part of that sequence. It may show a version after the package has been removed or fail to show code that did execute. Deployment logs, package-manager records, endpoint telemetry and network evidence should be aligned rather than treated as interchangeable.

Identify where trust failed¶

The package may have been altered in the supplier's build environment, signed using an abused key, substituted in a repository, or introduced through an internal deployment server. Direct vendor downloads, managed deployment tools, local caches and third-party repositories preserve different records.

Tracing each device's route helps locate the compromised stage and avoids assuming that the supplier knowingly participated. The supplier may itself be a victim.