Software supply chain attacks: SolarWinds and Log4Shell

Almost no organisation writes all of its own software. Applications are built on open-source libraries, installed from vendors, updated automatically and run on platforms maintained by others. Each of those is a link in a software supply chain. An attacker who compromises one link can reach every organisation downstream at once, often through channels that are trusted by design, such as signed updates. Two incidents made this impossible to ignore.

SolarWinds Orion: a trusted update turned against its users

In December 2020, it became public that attackers had compromised the build process of SolarWinds Orion, a widely used IT monitoring platform. Malicious code was inserted into legitimate Orion updates, which were then distributed to customers through the normal update channel. Because the updates came from the real vendor, customers had every reason to trust and install them. Once installed, the altered software could give the attackers a foothold inside the network.

CISA issued Emergency Directive 21-01, requiring US federal civilian agencies to immediately disconnect or power down affected Orion products, and published a detailed advisory (AA20-352A) describing the activity and the long, careful approach the attackers took after gaining access.

Log4Shell: one library, everywhere

In December 2021, a critical flaw was disclosed in Apache Log4j 2, a very common Java logging library. Tracked as CVE-2021-44228 and nicknamed Log4Shell, it could allow a remote attacker to run code on a vulnerable system simply by getting a crafted text string logged. NIST’s National Vulnerability Database rates it at the maximum severity. The hard part was not the patch, which the Apache project released quickly. It was finding every place Log4j was used: inside vendor products, bundled deep in other libraries, in systems nobody knew contained Java at all.

The US Cyber Safety Review Board, in its July 2022 report on Log4j, concluded that the vulnerability would remain a risk for years, because vulnerable copies would persist in systems that are rarely updated.

Two different attacks, one lesson

Both incidents showed that you inherit the risk of everything you run, and that you cannot respond quickly to what you cannot list. That insight drove the push for software bills of materials, build integrity and signing, which are covered in the next lesson.

What defenders do differently now

• Keep an inventory of software and its components, so “are we affected?” takes minutes, not weeks.
• Protect build systems as carefully as production: they produce what your customers trust.
• Limit what monitoring and management tools can reach; they often hold wide privileges.
• Watch outbound traffic from trusted software too. A signed application contacting new destinations is still worth a look.
• Follow CISA’s Known Exploited Vulnerabilities catalogue to prioritise patching.

Where FireAI fits

A SolarWinds-style attack is a reminder that a valid signature proves who built software, not that it behaves well. FireAI ties rules to an app’s verified code signature, and it also judges where the app connects: Investigate lists signs such as the first time an app contacts a destination, and the world map shows when a familiar, signed app starts talking somewhere new. Its opt-in threat lists can include CISA KEV and NIST NVD data for your apps’ versions.