Supply Chain Attack
debt(d7/e7/b5/t7)
Closest to 'only careful code review or runtime testing' (d7), slightly better. Tools like composer-audit, snyk, dependabot, and trufflehog exist and are listed, but they only catch known-vulnerable or known-malicious packages. Novel attacks — account compromise of a maintainer, a freshly uploaded malicious package, dependency confusion with a private package name — are invisible to automated tools until signatures/advisories are published. Detection is therefore largely after-the-fact or requires deep manual review, landing near d7.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix describes a multi-step programme: pinning composer.lock, verifying checksums, adding roave/security-advisories, and auditing every dependency. Remediating a supply chain compromise after the fact requires identifying affected packages, rotating secrets, auditing all post-install scripts, and potentially redeploying from a clean state — a cross-cutting effort touching CI configuration, dependency manifests, deployment pipelines, and potentially application code.
Closest to 'persistent productivity tax' (b5). Supply chain hygiene applies to all contexts listed (web, api, cli) and imposes ongoing overhead: every new dependency must be audited, composer.lock must be maintained and committed, CI pipelines must run audits, and developers must review post-install scripts. This slows many work streams but does not fully define the system's architecture, placing it at b5.
Closest to 'serious trap — contradicts how a similar concept works elsewhere' (t7). The misconception field states explicitly: 'Pinning dependency versions fully prevents supply chain attacks.' This is a well-documented and very common wrong belief — developers who know about version pinning naturally assume they are protected, but pinning does not guard against maintainer account compromise, dependency confusion, or malicious code already present in the pinned version. This contradicts the intuitive mental model of version control as a safety guarantee, scoring t7.
Also Known As
TL;DR
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
Why It Matters
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
// No version pinning — installs whatever is current
"require": {"acme/payment": "*"}// 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