What is ASUS ShadowHammer supply chain attack?

On March 25th, Motherboard reported that hackers managed to hijack ASUS, the 5th-largest  PC manufacturer by unit sales, software supply chain and inject a security backdoor that was installed on over a million computers (according to Kaspersky).




As the attack on Avast CCleaner’s installer did in 2017, the ASUS’s hijack spotlights the tech community’s risk associated with distributed software development.


Distributed software development is extremely resource efficient. Having software developed by multiple suppliers around the world, though, exposes companies to a number of supply chain risks. These risks can and must be hedged against.


Software supply chain attacks are not new to the industry, but when the malware injected in the Avast supply chain infected 2.3 million customers, the problem started to get proper attention. While much has been said of the problem since the CCleaner attack, the ASUS security breach proves that not enough has been done to prevent the issue from happening again.


Furthermore, companies like ASUS with their sprawling supply chains and their “trusted” networks of software producing coders from around the world, only increases the number of attack vectors hackers have to exploit. This is just one more giant reason companies need to secure their supply chains with more diligence and resolve.


Let’s take a look at how the ASUS attack was carried out. Hackers injected the ASUS update code with malware and signed it with one of ASUS’s own digital certificates. Because the certificate was valid, the injected code was then pushed to ASUS’s software distribution servers. As a result, more than a million ASUS customers unwittingly downloaded and installed the malicious update on their computers.


In this case, the backdoor sat on ASUS update servers for months before the company was able to identify the issue. And yet even after the exploit was recognized, the signing certificate used in the attack was not revoked, leaving customers to continuously suffer the effects of being comprised by the injected malware.

Lessons learned from the ASUS attack


After two attacks of such magnitude and the repeated methodology used by hackers, it’s time to humbly recognize the lessons learned from software supply chain attacks, and to take necessary corrective actions:


  1. Software supply chain attacks represent an effective and inexpensive way hackers can infect millions of computers with malware
  2. Trusting a coder doesn’t mean that you can trust his security practices, especially when he’s working remotely where your company’s security policies cannot be enforced
  3. Code signing and digital certificates, the de-facto claimed solution for software integrity verification, have repeatedly proven to be unable to guarantee software trust
  4. The certificate revocation process is almost never enforced, leaving users to continuous exposure to malicious software even after issues are identified


In order to solve these problems, software development processes must take a page out of the industrial manufacturing’s playbook. Manufacturing companies, in fact, vet and monitor each supplier and material before and after they become part of the supply chain. Here’s a simple checklist that companies should keep in mind when implementing a distributed software supply chain:


  1. Be capable of inhibiting coders from accessing their supply chain process when they cannot trust a coder anymore
  2. Enforce integrity verification at every step of the development workflow
  3. Verify trust from development to production and create a Trusted Software Bill of Materials (SBOM)
  4. Instantly recall any software produced by a non-trusted party
  5. Notify users of the issue so that they can install the correct patch

How CodeNotary can prevent software supply chain attacks

CodeNotary provides the capabilities needed to bring trust to the software supply chain. With CodeNotary, developers sign their code with their unique identity, so that it can be verified for integrity and origin. This can happen at every stage of the software lifecycle from development to production to distribution.


Here is how CodeNotary brings trust to the software supply chain:


  1. Developers sign, with a single command, the hashes of code they produce using their unique identity. Having a one command process makes signing extremely easy and eliminates any overhead
  2. The signed code is verified for integrity and authenticity as it moves along the supply chain, from IDE to source control, to build, to deployment and finally production and distribution. CodeNotary makes code integrity verification part of the build and deployment for a fully automated and secure process
  3. Only the code that passes the integrity verification is allowed to move into the next stage. This continuous integrity creates a trusted supply chain pipeline that software vendors can rely on
  4. In case of a rogue coder, CodeNotary can immediately revoke his signature and untrust his code
  5. The final product contains only trusted code, tracked in the product SBOM
  6. Software vendors can instantly recall any buggy or untrusted software after releasing it to production. This triggers automatic alerts to customers, who can then update the application before hackers exploit the vector


Trusted software supply chain


vChain developed CodeNotary to allow companies to build a trusted software supply chain inexpensively and without any overhead. With CodeNotary software vendors and publishers have no reason for becoming victims of supply chain attacks ever again.


Start your CodeNotary trial and see how easy it is to secure your software supply chain.



Get Started Now

Metrics and Logs

(formerly, Opvizor Performance Analyzer)

VMware vSphere & Cloud

Monitor and Analyze Performance and Log files:
Performance monitoring for your systems and applications with log analysis (tamperproof using immudb) and license compliance (RedHat, Oracle, SAP and more) in one virtual appliance!

Subscribe to Our Newsletter

Get the latest product updates, company news, and special offers delivered right to your inbox.

Subscribe to our newsletter

Use Case - Tamper-resistant Clinical Trials


Blockchain PoCs were unsuccessful due to complexity and lack of developers.

Still the goal of data immutability as well as client verification is a crucial. Furthermore, the system needs to be easy to use and operate (allowing backup, maintenance windows aso.).


immudb is running in different datacenters across the globe. All clinical trial information is stored in immudb either as transactions or the pdf documents as a whole.

Having that single source of truth with versioned, timestamped, and cryptographically verifiable records, enables a whole new way of transparency and trust.

Use Case - Finance


Store the source data, the decision and the rule base for financial support from governments timestamped, verifiable.

A very important functionality is the ability to compare the historic decision (based on the past rulebase) with the rulebase at a different date. Fully cryptographic verifiable Time Travel queries are required to be able to achieve that comparison.


While the source data, rulebase and the documented decision are stored in verifiable Blobs in immudb, the transaction is stored using the relational layer of immudb.

That allows the use of immudb’s time travel capabilities to retrieve verified historic data and recalculate with the most recent rulebase.

Use Case - eCommerce and NFT marketplace


No matter if it’s an eCommerce platform or NFT marketplace, the goals are similar:

  • High amount of transactions (potentially millions a second)
  • Ability to read and write multiple records within one transaction
  • prevent overwrite or updates on transactions
  • comply with regulations (PCI, GDPR, …)


immudb is typically scaled out using Hyperscaler (i. e. AWS, Google Cloud, Microsoft Azure) distributed across the Globe. Auditors are also distributed to track the verification proof over time. Additionally, the shop or marketplace applications store immudb cryptographic state information. That high level of integrity and tamper-evidence while maintaining a very high transaction speed is key for companies to chose immudb.

Use Case - IoT Sensor Data


IoT sensor data received by devices collecting environment data needs to be stored locally in a cryptographically verifiable manner until the data is transferred to a central datacenter. The data integrity needs to be verifiable at any given point in time and while in transit.


immudb runs embedded on the IoT device itself and is consistently audited by external probes. The data transfer to audit is minimal and works even with minimum bandwidth and unreliable connections.

Whenever the IoT devices are connected to a high bandwidth, the data transfer happens to a data center (large immudb deployment) and the source and destination date integrity is fully verified.

Use Case - DevOps Evidence


CI/CD and application build logs need to be stored auditable and tamper-evident.
A very high Performance is required as the system should not slow down any build process.
Scalability is key as billions of artifacts are expected within the next years.
Next to a possibility of integrity validation, data needs to be retrievable by pipeline job id or digital asset checksum.


As part of the CI/CD audit functionality, data is stored within immudb using the Key/Value functionality. Key is either the CI/CD job id (i. e. Jenkins or GitLab) or the checksum of the resulting build or container image.

White Paper — Registration

We will also send you the research paper
via email.

CodeNotary — Webinar

White Paper — Registration

Please let us know where we can send the whitepaper on CodeNotary Trusted Software Supply Chain. 

Become a partner

Start Your Trial

Please enter contact information to receive an email with the virtual appliance download instructions.

Start Free Trial

Please enter contact information to receive an email with the free trial details.