Yes. A software update obtained through a legitimate vendor's trusted update mechanism can contain malware if part of the vendor's software supply chain has been compromised.

This type of cyberattack is generally called a software supply chain attack or software supply chain compromise.

Instead of attacking thousands of organizations individually, attackers compromise a software developer, build environment, update infrastructure, code-signing process, dependency, or distribution system. Malicious code can then be delivered to customers through software that users and administrators already trust.

Microsoft describes software supply chain attacks as attacks targeting developers and suppliers to gain access to source code, build processes, or update mechanisms. Malware can consequently become part of an application or update distributed by a legitimate vendor.

This makes supply chain attacks particularly dangerous because normal security assumptions such as:

"The update came from the official software, therefore it must be safe."

may no longer be sufficient.

What Is a Trusted Software Update?

A trusted software update is normally an update distributed through an authorized mechanism controlled by the software vendor.

Examples include:

• Windows Update
• an application's built-in automatic updater
• vendor patch-management systems
• official software repositories
• enterprise software deployment platforms
• mobile application stores
• firmware update utilities
• package-management systems
• official vendor download portals

Normally, the update process may perform several security checks.

For example:

Application → Update Server → Download Update → Verify Signature → Install Update

Cryptographic signatures can help establish the integrity and origin of software. NIST explains that code signing provides integrity assurance that code has not been modified after signing and source authentication identifying who controlled the code when it was signed.

However, an important limitation exists:

A valid digital signature does not prove that the software itself is harmless.

If malicious code enters the software before the legitimate signing process, the malicious software may subsequently receive a perfectly valid vendor signature.

How Can Malware Enter a Legitimate Software Update?

There are several possible attack points.

A simplified software development chain may look like this:

Developer → Source Code → Dependencies → Build System → Signing System → Update Server → Customer

An attacker only needs to successfully compromise a sufficiently important part of this chain.

1. Compromising the Developer's Source Code

Attackers may first compromise developer accounts or development systems.

They could then modify legitimate application source code by inserting:

• backdoors
• credential-stealing functionality
• remote-access capabilities
• command-and-control communication
• malicious scripts
• ransomware loaders
• information stealers
• persistence mechanisms

The developer may subsequently compile the application without realizing that unauthorized code has been introduced.

2. Compromising the Software Build Environment

Modern software is frequently compiled automatically using CI/CD pipelines and build servers.

For example:

Source Repository

↓

CI/CD Server

↓

Compiler

↓

Application Package

↓

Code Signing

↓

Release Server

If attackers compromise the build server, they might inject malware during compilation without necessarily modifying the primary source-code repository.

This distinction is important.

Security personnel reviewing the application's source code could see legitimate code while the compiled binary delivered to customers contains additional malicious functionality.

Microsoft notes that attackers may compromise development infrastructure and inject malicious code before software is compiled and distributed.

3. Compromising the Software Update Server

Another possibility is compromising the infrastructure responsible for distributing updates.

A legitimate update server might normally provide:

software-update-v5.2.exe

After compromising the server, attackers could attempt to replace it with:

software-update-v5.2-malicious.exe

If update verification mechanisms are weak, applications might download and execute the malicious package.

For this reason, software update mechanisms should verify far more than merely the download location.

4. Stealing a Code-Signing Certificate

Software vendors commonly digitally sign executable files.

Windows users may see information such as:

Publisher: Example Software Pvt. Ltd.

A digital signature increases confidence that the software originated from the identified publisher and was not modified after it was signed.

But attackers may steal or misuse signing credentials.

Microsoft identifies stolen code-signing certificates and malicious applications signed under a legitimate developer identity as software supply chain threats.

This means malware could potentially display what appears to be a valid signature.

There have also been cases involving abuse of signing infrastructure. In 2026, Microsoft described disrupting an operation that abused signing services to create certificates used to make malware appear legitimately signed.

Therefore:

Digitally signed ≠ guaranteed malware-free

A signature is an important security control, but it should not be treated as the only security control.

5. Compromising Third-Party Libraries and Dependencies

Most modern applications are not written completely from scratch.

Developers frequently use:

• open-source libraries
• SDKs
• frameworks
• npm packages
• Python packages
• NuGet packages
• Java libraries
• container images
• third-party APIs

Consider an application containing:

Main Application

• Authentication Library
• Database Library
• PDF Library
• Networking Library
• Logging Library

If attackers compromise one dependency, applications incorporating the malicious version may inherit the compromise.

This is why Software Bills of Materials (SBOMs) and dependency management have become important components of software supply chain security.

6. Compromising Package Repositories

Developers increasingly retrieve components automatically from software repositories.

Examples include package ecosystems for:

• npm
• PyPI
• NuGet
• Maven
• RubyGems
• container registries

Attackers may attempt techniques such as:

• dependency confusion
• typosquatting
• account takeover
• malicious package publication
• compromised maintainer accounts
• package replacement

The malicious package can subsequently become part of legitimate applications.

7. Compromising the Vendor's CI/CD Pipeline

Continuous Integration and Continuous Deployment systems frequently possess extensive privileges.

They may have access to:

• source-code repositories
• build servers
• cloud services
• signing systems
• API tokens
• deployment credentials
• production servers

A compromised CI/CD account can therefore become an extremely powerful attack path.

Attackers might alter a release immediately before deployment.

Why Are Malicious Trusted Updates So Dangerous?

Trusted software updates have several characteristics that attackers find attractive.

Existing Trust

Organizations already trust the application.

Security controls may therefore permit it to:

• access the Internet
• modify files
• start services
• modify the registry
• execute during startup
• install drivers
• communicate with vendor infrastructure

Elevated Privileges

Many software updaters run with administrator or even SYSTEM-level privileges.

Microsoft has noted that malicious code hidden within installer or updater processes can benefit from elevated privileges, potentially allowing system-level changes.

Consequently, compromised updates can sometimes immediately obtain extensive access to a computer.

Automatic Deployment

Businesses often automatically deploy updates to hundreds or thousands of endpoints.

For example:

Compromised Vendor

↓

Malicious Update

↓

100 Customers

↓

10,000 Endpoints

A single compromise can therefore create an enormous number of potential victims.

The SolarWinds Example

One of the best-known examples of a trusted software supply chain compromise involved SolarWinds Orion.

Attackers compromised the software supply chain and malicious code known as SUNBURST was distributed through affected Orion software updates.

CISA reported active exploitation involving affected SolarWinds Orion Platform versions released between March and June 2020.

The incident demonstrated an important cybersecurity principle:

Even software received through a trusted vendor's normal distribution process can become an attack vector when the vendor's supply chain is compromised.

Can Antivirus Detect Malware Inside a Trusted Update?

Sometimes—but not always.

Traditional antivirus software commonly relies partly on:

• malware signatures
• known malicious hashes
• reputation
• known behavioral patterns

A newly created supply-chain implant may initially have no known malware signature.

Additionally, security software may initially consider the application trustworthy because it:

• comes from a known vendor
• has an established reputation
• carries a valid signature
• uses an expected filename
• was downloaded through an approved updater

Modern Endpoint Detection and Response systems can provide another layer by analyzing behavior.

For example, an EDR system might detect that a normally harmless accounting application's updater suddenly performs:

Updater.exe

↓

powershell.exe

↓

Downloads unknown executable

↓

Creates scheduled task

↓

Connects to unusual Internet host

Such behavior may be suspicious even if the original executable was signed.

Does HTTPS Prevent Malicious Software Updates?

HTTPS is important, but it cannot solve every supply-chain problem.

HTTPS helps protect communications between the customer and update infrastructure.

It can help prevent attackers from modifying an update while it travels across the network.

But suppose the update server itself contains:

Legitimate HTTPS Server + Malicious Update

The HTTPS connection can still be completely valid.

HTTPS securely transports whatever the trusted server provides.

Therefore organizations should use multiple controls, including:

HTTPS + Code Signing + Hash Validation + Endpoint Monitoring + Secure Build Systems

rather than relying on HTTPS alone.

Does a Valid Digital Signature Mean an Update Is Safe?

No.

A valid digital signature primarily answers questions such as:

Who signed this file?

and

Has this file changed since it was signed?

It does not necessarily answer:

Is this program free from malicious functionality?

NIST emphasizes that digital signatures provide software integrity and source authentication.

If malware was inserted before the vendor legitimately signed the software, signature validation may still succeed.

Similarly, misuse or theft of signing credentials can undermine assumptions based solely on publisher identity.

How Can Businesses Reduce the Risk?

No single technology completely eliminates software supply chain risk.

Organizations should use layered controls.

1. Obtain Software Only from Authorized Sources

Download applications and patches from:

• official vendor websites
• approved repositories
• trusted enterprise deployment systems
• official application stores

Avoid third-party download portals unless absolutely necessary.

2. Verify Digital Signatures

For important Windows executables:

Right-click file → Properties → Digital Signatures

Check:

• signer name
• certificate status
• timestamp
• certificate chain
• expected publisher

Unsigned software does not automatically mean malware, but unexpected signature changes deserve investigation.

3. Verify File Hashes

If a vendor publishes a SHA-256 hash, calculate the downloaded file's hash and compare it.

Windows PowerShell example:

Get-FileHash .\update.exe -Algorithm SHA256

The result should exactly match the vendor's published hash.

However, remember that hashes primarily protect against unauthorized modification or mismatched downloads. If the vendor intentionally or unknowingly publishes a compromised package and its corresponding hash, matching that hash does not prove the program is benign.

4. Use EDR Instead of Relying Only on Antivirus

Enterprise environments should consider Endpoint Detection and Response capabilities.

EDR can monitor:

• process creation
• PowerShell execution
• registry modification
• service creation
• scheduled tasks
• network connections
• persistence techniques
• credential access
• lateral movement

Microsoft recommends endpoint detection and response among the controls for detecting and remediating suspicious activity associated with supply chain threats.

5. Use Application Allowlisting

Organizations can restrict which programs are permitted to execute.

Windows environments may use technologies such as:

• Windows Defender Application Control
• AppLocker
• application-control capabilities in endpoint-security platforms

Application control can reduce the attacker's ability to execute secondary payloads.

6. Apply the Principle of Least Privilege

Users should not routinely operate with local administrator privileges.

Consider:

Normal User → Limited Permissions

instead of:

Normal User → Local Administrator

Even when an application becomes compromised, limiting available privileges can reduce potential impact.

7. Segment Critical Systems

Critical servers should not necessarily have unrestricted communication with ordinary workstations.

Network segmentation can separate:

• domain controllers
• database servers
• accounting systems
• backup infrastructure
• management networks
• user workstations
• development environments
• Internet-facing systems

A compromised update on one workstation should not automatically provide easy access to the entire organization.

8. Monitor Outbound Connections

Security teams should investigate unexpected network communications from normally trusted applications.

For example:

AccountingSoftware.exe → unknown-server.example:443

may deserve investigation if the application has never previously communicated with that destination.

Useful monitoring technologies include:

• firewalls
• DNS logging
• EDR
• SIEM
• proxy logs
• network detection systems

9. Protect Backup Systems

Supply chain compromises can potentially lead to ransomware.

Maintain backups using principles such as:

3-2-1 Backup Strategy

• 3 copies of important data
• 2 different storage types
• 1 copy offsite or isolated

Where practical, include immutable or offline backup protection.

10. Test Important Updates Before Organization-Wide Deployment

Businesses managing many endpoints should consider staged deployment.

For example:

Vendor Releases Update

↓

IT Downloads Update

↓

Security Verification

↓

Test Computers

↓

Pilot User Group

↓

Production Deployment

Instead of:

Vendor Releases Update → Immediately Install Everywhere

This does not guarantee detection of sophisticated malware, but it can reduce operational and security risk.

11. Maintain an Accurate Software Inventory

Organizations should know which software is installed and where.

Inventory records should ideally include:

• application name
• version
• vendor
• installation date
• device
• business owner
• patch status

When a vendor announces a compromise, IT teams can quickly identify affected computers.

12. Monitor Vendor Security Advisories

Security teams should monitor advisories from:

• software vendors
• operating-system vendors
• national cybersecurity authorities
• vulnerability databases
• threat-intelligence providers

Speed is particularly important during a supply-chain incident.

What Should You Do If a Trusted Update Is Reported as Compromised?

Treat the situation as a potential security incident rather than simply uninstalling the program.

A typical response may be:

Identify → Contain → Investigate → Eradicate → Recover → Monitor

First determine which computers installed the affected software and which versions are involved.

Depending on the vendor's guidance and the severity of the incident, organizations may need to:

• isolate affected endpoints
• stop vulnerable services
• block malicious domains or IP addresses
• remove affected software
• deploy corrected versions
• run EDR investigations
• inspect persistence mechanisms
• review authentication logs
• reset potentially exposed credentials
• revoke sessions or tokens
• check lateral movement
• search other endpoints for indicators of compromise

Simply uninstalling the application may not remove secondary malware already installed by the compromised update.

Software Vendors Also Need Strong Supply Chain Security

Developers have an equally important responsibility.

Microsoft recommends protecting build and update infrastructure, using strong authentication, signing software components, validating signatures and developing incident-response processes for supply-chain compromises.

Vendor security should therefore cover the entire lifecycle:

Developer Workstation

↓

Source Repository

↓

Dependency Management

↓

CI/CD Pipeline

↓

Build Server

↓

Signing Infrastructure

↓

Release Repository

↓

Update Infrastructure

↓

Customer

Security weaknesses anywhere along this path can affect the final product.

NIST's Cybersecurity Supply Chain Risk Management guidance similarly addresses risks involving malicious functionality, vulnerable products and limited visibility into how technology is developed, integrated and deployed.

Key Security Principle: Trust but Verify Is No Longer Enough

Modern cybersecurity increasingly follows a Zero Trust approach:

Never trust implicitly; continuously verify.

This principle should also apply to software.

Instead of assuming:

Trusted Vendor = Trusted File = Safe Execution

organizations should think:

Trusted Vendor + Verified Signature + Expected Hash + Approved Version + Expected Behavior + Continuous Monitoring

This layered approach is much more resilient against sophisticated supply chain attacks.

Frequently Asked Questions (FAQ)

1. Can trusted software updates contain malware?

Yes. If attackers compromise a software vendor's development environment, build pipeline, dependencies, signing infrastructure or update mechanism, malicious code can potentially be distributed through what appears to be a legitimate update.

2. What is this type of attack called?

It is generally called a software supply chain attack or software supply chain compromise.

3. Can an automatic software update install malware?

Yes. If the vendor's update infrastructure or software supply chain is compromised, an automatic updater could potentially distribute malicious software.

4. Can digitally signed software contain malware?

Yes. Digital signing proves important information about integrity and signer identity, but does not guarantee that the program contains no malicious functionality.

5. Can malware have a valid digital signature?

Yes. Malware may be signed if attackers steal or misuse signing credentials, abuse signing mechanisms, or insert malicious code before a legitimate vendor signs a compromised build.

6. Does HTTPS guarantee that a software update is safe?

No. HTTPS protects the communication channel, but it cannot guarantee that a file stored on a compromised vendor server is safe.

7. Can antivirus detect a malicious trusted update?

Possibly. Detection depends on the malware, antivirus engine, threat intelligence and behavior. Newly introduced malware may initially evade signature-based detection.

8. Can EDR detect compromised software updates?

EDR may detect suspicious post-installation behavior such as unusual process execution, persistence, credential access or unexpected network communication, even when the originating application is trusted.

9. Should automatic software updates be disabled?

Not generally. Disabling updates creates its own serious security risks because vulnerabilities remain unpatched. Organizations should instead use controlled patch management, staged deployment and monitoring where appropriate.

10. Is downloading an update directly from the vendor enough?

It substantially reduces the risk of receiving fake software from an unrelated third party, but it cannot eliminate the possibility that the vendor itself or its distribution infrastructure has been compromised.

11. Should I check SHA-256 hashes before installing updates?

For sensitive or manually deployed software, hash verification can provide useful integrity assurance when the vendor publishes hashes through a trusted channel.

12. Does matching a SHA-256 hash prove the file contains no malware?

No. It proves that your file matches the file represented by that hash. If the original vendor package itself was compromised before its hash was published, both could match.

13. What is a compromised software build system?

It occurs when attackers gain unauthorized access to infrastructure used to compile or package software and manipulate the resulting application.

14. What is a compromised software dependency?

It occurs when a library, framework, package or other third-party component incorporated into an application becomes malicious or compromised.

15. What is an SBOM?

A Software Bill of Materials (SBOM) is an inventory of software components and dependencies contained within an application. It can help organizations identify exposure when a particular component is found to be vulnerable or compromised.

16. Why are supply chain attacks difficult to detect?

Because malicious activity may originate from trusted software, signed binaries, legitimate vendor infrastructure and normal update processes.

17. Can a supply chain attack affect thousands of organizations?

Yes. Compromising widely deployed software can potentially provide attackers with access to a very large number of downstream systems.

18. What was the SolarWinds supply chain attack?

Attackers compromised the SolarWinds Orion software supply chain, resulting in affected software versions containing the SUNBURST backdoor and being distributed to customers. CISA subsequently issued guidance concerning affected Orion versions.

19. Should businesses immediately install every software update?

Security patches should be deployed promptly based on risk, but organizations with managed IT environments may use testing rings or staged deployment for important systems to balance vulnerability exposure against operational and supply-chain risks.

20. What is the best protection against malicious software updates?

There is no single protection. A strong strategy combines secure patch management, digital-signature verification, endpoint protection, EDR, least privilege, application control, network segmentation, reliable backups, vendor-risk management and continuous security monitoring.

Conclusion

Trusted software updates are essential for cybersecurity because they fix vulnerabilities, improve stability and provide new security protections. However, the update mechanism itself can become a target.

A sophisticated attacker may compromise:

Source Code → Dependency → Build System → Signing Process → Update Infrastructure → Customer

The resulting malicious package may look completely legitimate and may even carry a valid digital signature.

This is why organizations should avoid treating "trusted software" as automatically safe.

The stronger security model is:

Verify the source.

Verify the integrity.

Control deployment.

Limit privileges.

Monitor behavior.

Maintain recoverable backups.

Respond rapidly when a vendor reports compromise.

Software supply chain security ultimately requires protecting not only the final application but the entire ecosystem used to develop, build, sign, distribute, update and execute it.

#Tags

#SoftwareSupplyChain #SupplyChainAttack #CyberSecurity #Malware #SoftwareUpdates #MaliciousUpdates #SupplyChainSecurity #SoftwareSecurity #CyberAttack #CyberThreats #InformationSecurity #ITSecurity #NetworkSecurity #EndpointSecurity #EDR #Antivirus #MalwareDetection #CodeSigning #DigitalSignature #SignedMalware #SoftwareIntegrity #SecureSoftware #PatchManagement #UpdateSecurity #VendorSecurity #ThirdPartyRisk #VendorRiskManagement #CICDSecurity #DevSecOps #SecureDevelopment #SBOM #SoftwareBillOfMaterials #ZeroTrust #LeastPrivilege #ApplicationControl #ThreatDetection #ThreatIntelligence #IncidentResponse #Ransomware #Backdoor #SolarWinds #SUNBURST #DataSecurity #EnterpriseSecurity #WindowsSecurity #CyberAwareness #SecurityBestPractices #SupplyChainRisk #CyberDefense #CyberSecurityAwareness