Add Composer scanner for PHP projects

[jthDEV]

Why

PHP support used to live in the standalone Composer plugin eacg-gmbh/ecs-composer, which posted scans directly to the ECS API. Since ts-scan became the entry point for all ecosystems, that plugin is no longer usable. This brings PHP back as a regular ts-scan scanner, so Composer projects flow through the same scan → check / analyse / upload paths as every other ecosystem.

What

A new ComposerScanner in src/ts_scan/pm/composer.py:

• detects a project by its composer.json and resolves the dependency graph from composer.lock — a committed lockfile needs neither a Composer installation nor network access
• without a lockfile, runs composer update --no-install --no-scripts; if that fails or Composer is missing, falls back to the requirements declared in composer.json (reported without resolved versions) instead of aborting the scan
• resolves provide / replace, so virtual requirements such as psr/log-implementation attach to the package that satisfies them
• carries over dist.shasum, source.reference, licenses, homepage and description, and warns about abandoned packages
• records vendor/<vendor>/<package> as package_files, so the in-depth analysis picks up installed sources
• guards against cyclic requirements and attaches each package once, even when several requirements resolve to it

Carried over from ecs-composer

• the component key composer:vendor/name, so existing TrustSource components keep matching
• the platform package table from PlatformPackage.php — php / ext-* → PHP-3.01, composer-plugin-api / composer-runtime-api → MIT, including their homepage and repository URLs

Identity

Dependencies export as spec conformant purls, e.g. pkg:composer/monolog/monolog@3.5.0. The module id deliberately carries no version (composer:acme/inventory-app), so module level mutes and exemptions survive version bumps.

Options

Option	Effect
--composer:includeDevDependencies	include require-dev and packages-dev
--composer:includePlatformPackages	include php, ext-*, lib-*, composer-* with their licenses
--composer:enableMetadataRetrieval	enrich packages from the Packagist registry

plus the inherited --composer:ignore, --composer:executable and --composer:forward.

Tests

examples/composer/ ships a committed lockfile covering transitive requirements, provide, an abandoned package, dev dependencies and platform requirements. tests/test_composer.py adds 12 regression tests; the full suite is green (52 passed).

Limitations

• PHP and Composer are not installed on the machine this was developed on, so the lockfile generation path is covered by a mocked executable only, not against a real Composer run. Worth one manual check against a real project before release.
• Platform packages carry their declared constraint (>=8.1), not a resolved runtime version — the lockfile does not contain one, and the scanning machine's PHP version would be misleading.
• pkg:composer/php is a pragmatic purl; purl has no PHP runtime type. It intentionally does not match anything on Packagist.

Note for reviewers

feature/cocoapods-scan and feature/swift-package-manager-scan touch the same three lines (scanner registry, README ecosystem list, CHANGELOG) and will need a rebase after this lands.

🤖 Generated with Claude Code

[github-advanced-security]

Bandit found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

[gr-markin]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

Resolved and pushed in 410a8f4. I merged main, fixed all conflict markers in CHANGELOG.md, README.md, and src/ts_scan/__init__.py, and validated with targeted scanner tests.