The Three Supply Chain Attack Surfaces
| Attack Surface | Attack Method | Real Example | Primary Defense |
|---|---|---|---|
| Service Providers | Compromise a vendor with legitimate access; use stolen credentials to pivot into the target | Target breach via HVAC contractor (2013) | Vendor security audits; network segmentation; monitor vendor account activity |
| Hardware Providers | Sell counterfeit or tampered hardware that looks legitimate; device may monitor traffic or contain backdoors | $1B counterfeit Cisco scheme (arrested 2022) | Purchase from authorized distributors; verify hardware authenticity; small vetted supplier base |
| Software Providers | Compromise the build pipeline or distribution mechanism; inject malicious code before or after code signing | SolarWinds SUNBURST — build pipeline compromise (2020) | SBOM; staged update deployment; behavioral monitoring; code signing + reproducible builds |
Island Hopping — How Supply Chain Attacks Propagate
Island hopping describes the technique of using a weaker, connected organization as a stepping stone to reach a more hardened target.
1
Identify the Target
The attacker wants access to Organization A — a bank, government agency, or large corporation with a hardened security perimeter. Direct attack is difficult and likely to be detected quickly.
The attacker wants access to Organization A — a bank, government agency, or large corporation with a hardened security perimeter. Direct attack is difficult and likely to be detected quickly.
2
Map the Supply Chain
The attacker researches which service providers, contractors, and vendors have legitimate access to Organization A. They look for a provider with lower security maturity — an HVAC contractor, a payroll processor, a small IT support company — that Organization A trusts and has granted network access.
The attacker researches which service providers, contractors, and vendors have legitimate access to Organization A. They look for a provider with lower security maturity — an HVAC contractor, a payroll processor, a small IT support company — that Organization A trusts and has granted network access.
3
Compromise the Weaker Link
The attacker attacks the supplier directly — phishing, credential stuffing, or exploiting an unpatched vulnerability. The supplier is the real target of the initial attack. This step may be easy if the supplier lacks endpoint protection, MFA, or security awareness training.
The attacker attacks the supplier directly — phishing, credential stuffing, or exploiting an unpatched vulnerability. The supplier is the real target of the initial attack. This step may be easy if the supplier lacks endpoint protection, MFA, or security awareness training.
4
Harvest Trusted Credentials
Once inside the supplier, the attacker collects any credentials, VPN certificates, or service account tokens used to access Organization A's systems. These credentials are legitimate — they were issued by Organization A for the supplier's legitimate use.
Once inside the supplier, the attacker collects any credentials, VPN certificates, or service account tokens used to access Organization A's systems. These credentials are legitimate — they were issued by Organization A for the supplier's legitimate use.
5
Use Trusted Access Against the Ultimate Target
The attacker uses the harvested credentials to access Organization A. The connection looks normal: the right source IP, legitimate credentials, normal hours of access. Organization A sees a vendor account doing vendor things — no alarms fire.
The attacker uses the harvested credentials to access Organization A. The connection looks normal: the right source IP, legitimate credentials, normal hours of access. Organization A sees a vendor account doing vendor things — no alarms fire.
Defense point: Monitor vendor account behavior with anomaly detection — normal vendor access has predictable patterns. Unusual data volumes, off-hours access, or access to systems outside the vendor's scope should trigger alerts regardless of credential legitimacy.
SolarWinds SUNBURST — Build Pipeline Compromise
SUNBURST demonstrates how compromising the software build process creates a trusted delivery mechanism for malicious code at scale.
1
Attacker Enters the Build Pipeline
In early 2020, attackers gained access to SolarWinds' build environment — the automated system that compiled, packaged, and prepared the Orion software update. How exactly they gained this initial access is not fully confirmed but likely involved compromised developer credentials.
In early 2020, attackers gained access to SolarWinds' build environment — the automated system that compiled, packaged, and prepared the Orion software update. How exactly they gained this initial access is not fully confirmed but likely involved compromised developer credentials.
2
Malicious Code Injected Before Signing
The attackers inserted the SUNBURST backdoor code into the Orion source before the build process compiled and signed it. The malicious code was designed to appear innocuous during testing — it would not activate if it detected a test or sandbox environment, making it invisible to SolarWinds' own QA process.
The attackers inserted the SUNBURST backdoor code into the Orion source before the build process compiled and signed it. The malicious code was designed to appear innocuous during testing — it would not activate if it detected a test or sandbox environment, making it invisible to SolarWinds' own QA process.
3
Legitimate Code Signing Applied
SolarWinds' automated build process applied the legitimate SolarWinds code-signing certificate to the compiled, already-malicious update package. The signature was cryptographically valid — it genuinely came from SolarWinds. The signature proved provenance, not safety.
SolarWinds' automated build process applied the legitimate SolarWinds code-signing certificate to the compiled, already-malicious update package. The signature was cryptographically valid — it genuinely came from SolarWinds. The signature proved provenance, not safety.
4
Normal Distribution to 18,000 Customers
The signed update was distributed through SolarWinds' normal update mechanism. Customers' security tools verified the valid signature and approved installation. The update was installed as a trusted, signed software update — across approximately 18,000 organizations.
The signed update was distributed through SolarWinds' normal update mechanism. Customers' security tools verified the valid signature and approved installation. The update was installed as a trusted, signed software update — across approximately 18,000 organizations.
5
Nine Months of Undetected Access
SUNBURST activated after a dormancy period to evade detection. It communicated over standard HTTPS to C2 servers using domain names that mimicked legitimate SolarWinds infrastructure. The malicious activity blended into normal SolarWinds traffic. It was not discovered until December 2020 — nine months after first distribution.
SUNBURST activated after a dormancy period to evade detection. It communicated over standard HTTPS to C2 servers using domain names that mimicked legitimate SolarWinds infrastructure. The malicious activity blended into normal SolarWinds traffic. It was not discovered until December 2020 — nine months after first distribution.
Key lesson: Code signing verifies that SolarWinds signed the update — it does not verify that the code is safe. If attackers compromise the process before signing, the signature becomes a false assurance. The defense is not just code signing but reproducible builds (allowing independent parties to verify that a signed binary matches published source code) and behavioral monitoring of deployed software.
Why Code Signing Is Necessary but Insufficient
What Code Signing DOES
- Verifies the publisher (who signed it)
- Detects tampering after signing
- Prevents third-party modification during distribution
- Establishes a chain of trust to the certificate authority
What Code Signing Does NOT Do
- Does NOT prove the code is safe or malware-free
- Does NOT protect against compromise before signing
- Does NOT guarantee the build pipeline is secure
- Does NOT detect if the signer was deceived
SolarWinds implication: The SUNBURST update had a perfectly valid SolarWinds signature. Every security check that relied on "signature is valid = safe to install" failed completely. The signature was legitimate — the code it signed was not. This is why SBOM, reproducible builds, and behavioral monitoring are necessary complements to code signing.
Supply Chain Security Controls Summary
| Control | What It Addresses | Layer |
|---|---|---|
| Vendor security audits in contracts | Service provider security posture; ensures ongoing verification, not just onboarding | Service providers |
| Network segmentation for vendor access | Limits blast radius if vendor credentials are compromised; vendor can only reach required systems | Service providers |
| Vendor account behavioral monitoring | Detects compromised vendor credentials by identifying anomalous access patterns | Service providers |
| Authorized hardware distributors only | Reduces counterfeit hardware risk by purchasing from known-legitimate sources | Hardware |
| Hardware authenticity verification | Physically and electronically verify hardware matches manufacturer specifications before deployment | Hardware |
| Code signing verification | Verifies software came from the claimed publisher and was not modified after signing | Software |
| Staged update deployment (test then prod) | Behavioral testing in isolated environment before production rollout detects anomalous update behavior | Software |
| SBOM (Software Bill of Materials) | Enables rapid identification of all applications affected when a dependency has a vulnerability | Software |