← CodeClarityLab Home
Browse by Category
+ added · updated 7d
← Back to glossary

Dependency Management Philosophy

general PHP 5.3+ Intermediate

Also Known As

dependency management composer lock left-pad

TL;DR

Every dependency is a liability — prefer few well-maintained packages; pin versions via composer.lock; audit regularly.

Explanation

Principles: prefer stdlib, prefer widely-used over niche, check licence (GPL contamination risk), pin versions (composer.lock), audit regularly (composer audit). Left-pad problem (npm 2016): a widely-used 11-line package was unpublished, breaking thousands of projects. Each dependency adds: security attack surface, version conflicts, licence risk, maintenance burden.

Common Misconception

More dependencies save time — each adds security surface, conflicts, licence risk, and maintenance burden.

Why It Matters

Dependency management is not just about installing packages — it is about controlling what code runs in your application. A compromised or malicious package in your dependency tree can exfiltrate data, install backdoors, or corrupt your build. Pinning exact versions in composer.lock and running composer audit regularly catches known vulnerabilities before they reach production. The supply chain attack surface through third-party packages is now the most common vector for large-scale compromises.

Common Mistakes

  • composer.lock not committed
  • composer update in production
  • No licence review
  • Depending on abandoned packages

Avoid When

  • Adding a package for a feature you could implement in 10 lines — every dependency is a supply chain risk.
  • Ignoring outdated dependencies — stale packages accumulate security vulnerabilities.
  • Committing vendor directories to version control when a lock file is sufficient.
  • Using broad version constraints (^1.0) without testing — minor updates can introduce breaking changes.

When To Use

  • Pin exact versions in production lock files — deterministic builds prevent surprise breakage.
  • Audit new dependencies for maintenance activity, license compatibility, and known vulnerabilities before adding.
  • Automate dependency updates with Dependabot or Renovate — humans do not reliably update dependencies.
  • Separate dev dependencies from production dependencies — only production code ships to users.

Code Examples

✗ Vulnerable
// Non-pinned: different versions on dev/CI/prod
✓ Fixed
// Checklist: <50 lines to DIY? Maintained? MIT licence? Audit in CI
git add composer.lock

Added 16 Mar 2026
Edited 25 Mar 2026
Views 25
Rate this term
No ratings yet
🤖 AI Guestbook educational data only
| |
Last 30 days
0 pings W 0 pings T 0 pings F 0 pings S 2 pings S 0 pings M 0 pings T 0 pings W 0 pings T 1 ping F 0 pings S 2 pings S 0 pings M 0 pings T 0 pings W 0 pings T 0 pings F 2 pings S 2 pings S 0 pings M 0 pings T 0 pings W 0 pings T 0 pings F 0 pings S 2 pings S 0 pings M 0 pings T 0 pings W 0 pings T
No pings yet today
No pings yesterday
Amazonbot 7 Perplexity 4 Ahrefs 2 Google 2 SEMrush 2 Majestic 1 Unknown AI 1 ChatGPT 1
crawler 19 crawler_json 1
DEV INTEL Tools & Severity
🟠 High ⚙ Fix effort: Low
⚡ Quick Fix
Run composer audit weekly and on every CI run — it checks installed packages against the PHP Security Advisories database and takes under a second
📦 Applies To
PHP 5.3+ web cli
🔗 Prerequisites
🔍 Detection Hints
No composer audit in CI; outdated packages with known vulnerabilities; composer.lock not committed; use of abandoned packages
Auto-detectable: ✓ Yes composer-audit dependabot snyk roave-security-advisories
⚠ Related Problems
🤖 AI Agent
Confidence: Medium False Positives: Medium ✗ Manual fix Fix: Medium Context: File
CWE-1104

✓ schema.org compliant