Supply Chain Attack
Also Known As
dependency confusion
typosquatting attack
build pipeline attack
TL;DR
An attacker compromises a trusted third-party dependency, build tool, or package to inject malicious code into downstream applications.
Explanation
Supply chain attacks target the weakest link in the software delivery pipeline — a compromised open-source package, a hijacked build server, or a malicious code commit to a widely-used library can affect thousands of downstream applications simultaneously. Mitigations include pinning dependency versions with integrity hashes (composer.lock with hash verification), auditing packages before adoption, using tools like composer audit, and monitoring for unexpected outbound network connections.
Common Misconception
✗ Pinning dependency versions fully prevents supply chain attacks. Version pinning prevents unexpected upgrades but not account compromise of the original maintainer, dependency confusion attacks using higher-versioned private package names, or malicious code in the pinned version itself.
Why It Matters
Attackers target the build tools and dependencies of popular projects — a single compromised package can affect thousands of downstream applications simultaneously.
Common Mistakes
- Not committing composer.lock to version control — running composer install without it installs unpinned latest versions.
- Not running composer audit or npm audit in CI pipelines to catch known vulnerable dependencies.
- Installing packages from unverified sources or using package name typosquatting targets.
- Running post-install scripts from packages without reviewing them — a common malware vector.
Avoid When
- Never use composer update in production deployments — use composer install --no-dev from the locked file.
- Do not install packages from unknown vendors without reviewing the package source and history on packagist.org.
When To Use
- Pin exact dependency versions in composer.lock and commit it — ensures repeatable builds.
- Run composer audit in CI to catch known-vulnerable dependencies before deployment.
Code Examples
✗ Vulnerable
// No version pinning — installs whatever is current
"require": {"acme/payment": "*"}
✓ Fixed
// Pin versions + commit composer.lock
"require": {"acme/payment": "^2.4.1"}
// Audit on every CI run:
$ composer audit
// Block known-vulnerable packages automatically:
$ composer require --dev roave/security-advisories:dev-latest
// Review before adding new dependencies:
$ composer show acme/payment // inspect maintainers, abandoned status
// Verify signatures (Composer 2.4+):
$ composer config audit.abandoned report
References
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
15 Mar 2026
Edited
31 Mar 2026
Views
32
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 0
No pings yet today
Perplexity 9
Amazonbot 8
Google 3
Ahrefs 2
Unknown AI 2
SEMrush 1
Bing 1
Also referenced
How they use it
crawler 24
crawler_json 2
Related categories
⚡
DEV INTEL
Tools & Severity
🔴 Critical
⚙ Fix effort: Medium
⚡ Quick Fix
Pin exact versions in composer.lock, verify package checksums, use roave/security-advisories, and audit new dependencies before adding
📦 Applies To
PHP 5.0+
web
api
cli
🔗 Prerequisites
🔍 Detection Hints
No composer.lock committed; packages without version pinning; unreviewed new dependencies
Auto-detectable:
✓ Yes
composer-audit
snyk
dependabot
trufflehog
⚠ Related Problems
🤖 AI Agent
Confidence: High
False Positives: Medium
✗ Manual fix
Fix: High
Context: File
CWE-829
CWE-494