Supply Chain and API Security: The Risk You Inherit

Most of your code is not yours

A typical modern application is a small amount of original code sitting on a large amount of open-source dependency. Each dependency has its own dependencies. The result is that an organisation runs thousands of components it never evaluated, maintained by people it has no relationship with.

Supply chain attacks exploit this. Rather than attacking a hardened target directly, an attacker compromises something that target already trusts: a popular library, a build tool, or a software update mechanism.

The recurring patterns

• Compromising a legitimate package maintainer’s account and publishing a malicious update
• Typosquatting, registering package names close to popular ones
• Compromising the build pipeline, so the source looks clean but the artefact is not
• Exploiting known vulnerabilities in dependencies that were never updated

The last is the most common by a wide margin and the least dramatic. Unpatched known vulnerabilities in dependencies cause far more incidents than sophisticated pipeline compromises.

Why APIs deserve separate attention

APIs expose business logic directly, are designed for programmatic access, and often sit outside the testing that user-facing applications receive. Common weaknesses include authorisation checks that verify identity but not entitlement, endpoints returning more data than the interface displays, and absent rate limiting that permits bulk extraction.

Undocumented and forgotten APIs are a particular problem. Older versions left running after a replacement shipped are a recurring source of exposure, and they rarely appear in any inventory.

Practical steps

• Maintain a dependency inventory and monitor it against vulnerability databases
• Pin versions and verify integrity rather than pulling latest automatically
• Discover APIs from the outside in, since documentation is usually incomplete
• Enforce authorisation per object, not just per endpoint
• Retire old API versions deliberately instead of leaving them running

Related in the Knowledge Base

• Software Bill of Materials (SBOM) and Pipeline Security
• OWASP and the Vulnerability Classes That Won't Die
• Third-Party and Vendor Risk: Assessing the Risk You Inherit