News Article · 2 min read
Why Supply-Chain Attacks Keep Working: Lessons from SolarWinds and xz-utils
Two of the most consequential software supply-chain compromises on record share a root cause that most vendor-risk programs still don't test for.
The 2020 SolarWinds compromise (malicious code inserted into Orion software updates, distributed to roughly 18,000 customers) and the 2024 xz-utils backdoor (a multi-year social-engineering effort to gain maintainer access to a widely-used compression library) are structurally different attacks with the same underlying lesson: the trust boundary most organizations actually rely on — "we vet the vendor, then trust their updates" — has no mechanism for catching a compromise that happens inside the vendor's own build pipeline or open-source maintainer relationships.
What actually would have helped
- A real, machine-readable SBOM (Software Bill of Materials) for both direct dependencies and transitive ones — xz-utils was several layers deep in most affected systems' dependency trees.
- Build-provenance verification (attestations that a given artifact was actually built from the source it claims to be), not just "we downloaded it from the official source."
- Anomaly detection on outbound network behavior from newly-updated software, independent of whether the update itself was expected.
Note
xz-utils was caught because a Microsoft engineer noticed an unexplained SSH login latency increase during unrelated performance work — not because any vendor-risk process flagged it. That's not a criticism of vendor-risk programs; it's a reminder that supply-chain compromise detection is still immature industry-wide.