Skip to content
PHP supply chain

Composer audit for PHP projects

Parser for composer.json or composer.lock with project statistics (package count, PHP constraints, required extensions, require vs require-dev breakdown), EOL detection for the most common PHP packages (Laravel, Symfony, PHPUnit, Guzzle, Monolog, Flysystem, Doctrine), recommendations on security advisories and best practices (composer audit, roave/security-advisories). Triage tool: NOT a real-time vuln scanner.

How to use the audit

  1. 1

    Get the file

    composer.json: file you commit to git, contains declared constraints (e.g. "laravel/framework": "^11.0"). composer.lock: file generated by composer install/update, contains exact resolved versions (e.g. 11.5.0). For real audit you need the lock because it has the actual versions.

  2. 2

    Paste in the tool

    The tool auto-detects the type: top-level packages array -> lock; require object with string constraints -> json. Strict JSON parsing: syntax errors fail with a clear message.

  3. 3

    Read the report

    Output: project statistics (total packages, require/dev breakdown, PHP constraint, extensions) + severity-ordered findings (critical EOL packages, known EOL, deprecations, recommendations). Each finding has package reference, motivation, suggested remediation.

  4. 4

    Run the real audit

    For actual CVE check: terminal composer audit (official command, since 2.4, 2022). Additionally composer require --dev roave/security-advisories:dev-latest: blocks installation of packages with known CVEs via FriendsOfPHP meta-package. Best practice: integrate composer audit in CI/CD.

What a triage audit is, and when it helps

Static triage, not vuln scan. The tool knows a curated set of popular PHP packages with their respective end-of-life (security support) dates and public deprecation flags, and reports major versions that are too far behind or packages already out of support. It does not query remote CVE databases (FriendsOfPHP/security-advisories, Snyk DB, NVD): it does not replace composer audit CLI or GitHub Dependabot, it precedes them.

When static triage is exactly the right thing. Typical cases: legacy project review without filesystem access, where the client pastes a composer.json in an email and wants an assessment in thirty seconds; pre-engagement audit to estimate adaptation effort before sending a quote; initial screen before a real security assessment. Output: list of known risks (Laravel 8 EOL, PHPUnit 9 EOL on PHP 8.4, Monolog 2 EOL) that deserve a follow-up with rigorous CVE checking.

Operational privacy. The composer.lock file contains the complete project structure, transitive dependencies and any private packages with references to internal VCS repositories. You don't want to upload it to a third-party service for a preliminary analysis. EOL detection happens directly in the browser on the text you paste.

Scope limit. The tool flags EOL and major-version-behind packages. It does not flag specific CVEs. The canonical approach for vulnerability checking is composer audit from CLI (official Composer command since 2.4, September 2022), roave/security-advisories as a dev dependency that blocks installation of packages with known CVEs, or Dependabot/Renovate integrated in the repository.

Packages monitored for EOL detection

Curated list of popular PHP packages with end-of-life dates (security support):

  • laravel/framework: 8.x (EOL 2023-01), 9.x (EOL 2024-02), 10.x (EOL 2025-02), 11.x (current LTS)
  • symfony/symfony (and every symfony/* component): 4.x (EOL 2023-11), 5.x (5.4 LTS EOL 2024-11, security extended 2025-11), 6.x (6.4 LTS EOL 2025-11), 7.x (current)
  • phpunit/phpunit: 7.x (EOL 2020), 8.x (EOL 2021), 9.x (EOL 2024-02), 10.x (current)
  • guzzlehttp/guzzle: 6.x (EOL 2022-08, breaking changes for 7.x), 7.x (current)
  • monolog/monolog: 1.x (EOL 2021-09), 2.x (EOL 2025-01), 3.x (current)
  • league/flysystem: 1.x (EOL 2022, breaking changes for 2.x and 3.x), 2.x (EOL 2023), 3.x (current)
  • doctrine/dbal: 2.x (EOL 2023-09), 3.x (current), 4.x (migration in progress)
  • doctrine/orm: 2.x (current LTS), 3.x (migration in progress)
  • illuminate/* (Laravel standalone components): same Laravel cycle
  • twig/twig: 2.x (EOL 2024-04), 3.x (current)

PHP version constraint: the tool flags if the constraint includes EOL versions: 7.0/7.1/7.2/7.3 (EOL before 2022), 7.4 (EOL 2022-11), 8.0 (EOL 2023-11), 8.1 (security 2025-12). Currently supported versions: 8.2, 8.3, 8.4 (active LTS).

Glossary

Technical terms used on this page, briefly explained.

composer.json #
PHP project manifest file. Declares name, author, dependencies (require, require-dev), version constraints (e.g. ^11.0), PSR-4 autoload. Committed in git.
composer.lock #
File auto-generated by composer install/update. Contains exact resolved versions of every package + content-hash + timestamp. Guarantees deterministic builds between dev and production. Committed in git (best practice).
Composer version constraint #
Syntax: ^1.2 = SemVer compatible (>=1.2 <2.0), ~1.2 = patch-level (>=1.2 <1.3), 1.2.* = wildcard, >=1.2 = open. Best practice: ^X.Y for stable dependencies, ~X.Y.Z for conservative dependencies.
EOL (End Of Life) #
Date beyond which a package no longer receives security updates. Keeping EOL packages in production is a risk: new vulnerabilities are not patched, and in NIS2 scope it's flagged as 'inadequate cyber hygiene' (art. 21 c.2 lett. g).
FriendsOfPHP/security-advisories #
Collaborative open source database of security advisories for Composer packages. Updated daily, YAML format, basis of the roave/security-advisories meta-package.
roave/security-advisories #
Composer meta-package (no code, just conflict declarations) that blocks installation of packages with known CVEs. Usage pattern: composer require --dev roave/security-advisories:dev-latest. Zero runtime overhead.
composer audit #
Official Composer command (since 2.4, 2022). Compares installed packages against the FriendsOfPHP CVE database. Output: list of active CVEs with severity. To integrate in CI/CD pipeline.
Renovate / Dependabot #
Automated bots (GitHub Dependabot, Renovate Bot multi-platform) that monitor dependencies and open update PRs. For PHP-Composer: native support, recognize security advisories and prioritize security PRs.

Frequently asked questions about Composer audit

Difference between auditing lock vs json?
composer.lock contains exact resolved versions: the tool can verify if version X.Y.Z is EOL. composer.json contains only constraints (^11.0): the tool doesn't know which actual version is installed, can flag only constraint-level issues (e.g. laravel/framework: ^8.0 is an EOL constraint because Laravel 8 is EOL). For precise audits use the lock.
Does the tool flag specific CVEs of a package?
No. We've already said this in this section, but it's the most frequent question so worth emphasizing. The tool only knows the EOL dates of a curated set of popular packages. For CVE checks use composer audit CLI or GitHub Dependabot.
Can I audit a project with 200+ packages?
Yes, performance is OK up to 1000 packages. The bottleneck is table rendering. For enterprise projects with 1000+ deps: composer audit CLI is faster and more accurate. Our tool is useful for typical projects (10-100 deps) of consulting/SMB scale.
What does the tool do on an unknown package (not in the curated set)?
Counts it in statistics but emits no finding. It's not a finding 'unknown = dangerous': most packages are unknown to the curated set because they're niche, not because they're bad. For broader coverage: composer audit with full CVE database.
Symfony is particularly tricky because it has many standalone components (symfony/console, symfony/yaml, etc). Do you handle them all?
Yes. The tool considers every symfony/* package with the same LTS policy as the main release (Symfony 5.4 LTS = symfony/console:5.4 LTS, etc). Rare exceptions (some components have slightly different cycles) are ignored to simplify.
The project's PHP constraint is <code>>=7.4</code>: what do you flag?
We flag that the constraint is permissive: by including PHP 7.4 (EOL 2022-11), the project formally accepts install on PHP 7.4 even if production is actually 8.x. Best practice: >=8.2 minimum in the constraint, even if production is 8.4. Communicates intent + prevents accidental install on legacy VPS.
How do I integrate <code>composer audit</code> in CI/CD?
GitLab CI example: composer audit --abandoned=report --format=json in the test job. Exit code != 0 if active CVEs. GitHub Actions: same command, optionally with tj-actions/composer-audit. Pre-commit hook: add composer audit to .husky/pre-commit or git/hooks/pre-commit. Best practice: also on tag releases, not only PRs.
Difference between abandoned, deprecated and EOL?
Abandoned: the maintainer has explicitly marked the package as abandoned in composer.json (abandoned field). Deprecated: the package is still maintained but replaced by a newer version (e.g. league/flysystem 1.x deprecated in favor of 2.x). EOL: the maintainer no longer releases security updates on the branch (e.g. Symfony 5.4 after Nov 2025). All three require migration.
Can I use the tool on a library's composer.json (not an app)?
Yes, it works the same. Libraries typically have fewer packages (10-30) and are more careful about backwards compatibility. Typical findings: too-permissive PHP constraint (>=7.0 to support downstream legacy), version pinning of EOL test frameworks.
Does the tool integrate an external PHP library?
No, JSON parse is native (JSON.parse) and all matching logic is. ~10KB total. The curated EOL set is inline in the JS file, periodically updated with releases of monitored projects.

Want a supply chain review of your PHP project?

This tool is a triage. For a full ICT supply chain audit (in scope of NIS2 art. 21 c.2 lett. d): dependency inventory, continuous CVE monitoring, update policies, EOL tracking, CI/CD pipeline hardening, deploy signing. I work on Laravel, Symfony and custom PHP projects.

PHP supply chain audit

Want a realistic estimate for your project?

7-question wizard, 2 minutes, free. Output: range of person-days, rough price range, engagement recommendation. Reference rate 300 EUR/day. Built for custom backend projects, integrations, security audits or AI automation.

Get a free quote