Supply Chain Attack

Your web app will depend on libraries and third-party components outside your control. For example, Social media (SoMe) trackers and CSS or similar plugins. Over time, they might be insecure or outdated. This is known as a supply chain attack, when something you already trust becomes the way attackers get in.

Tip: Keep a list of them and the last working version on your end.

Examples: One famous example was log4j and another was SolarWinds. 

A supply chain attack compromises a system indirectly, by tampering with something it depends on rather than attacking it head on. The weak point might be an open source library, a build tool, a software update or a hardware component. The tampered piece arrives through a trusted channel, so everyone downstream installs and runs it without suspicion. In software, the term sits alongside software supply chain security, dependency risk and third-party risk.

So what? A single compromised component can reach huge numbers of systems at once. The xz Utils case showed how much critical infrastructure can rest on one overworked, unpaid maintainer.

Examples: In the xz Utils attack (2024), someone posing as a helpful contributor spent around two years earning maintainer access. They then hid a backdoor in the release tarballs while leaving the visible source code clean. It was caught in March 2024 when an engineer noticed SSH logins taking slightly longer than usual. A more everyday version is a malicious package published to a public registry such as npm or PyPI under a name close to a popular one.