php-vuln-scanner

PHP dependency vulnerability scanner (php-vuln-scanner)

Scans the Composer dependencies of a PHP project, identifies known security vulnerabilities (CVE/Advisory), and provides a framework for inferring associations with routes/entry points.

Input

source_path: source code root directory

Supported targets:

composer.json
composer.lock
Directory recursion (find composer.lock under multiple submodules)

Rules and output

Rule matching: use built-in/external rule sets (for example references/php-vulnerability.yaml, if present, take priority)
Output to:

{output_path}/vuln_report/
  {project_name}_composer_vuln_report_{timestamp}.md

Scanning process (required)

Cross-validation suggestion: if it can be executed in the project environment, composer audit, it is recommended to cross-compare its output with this skill's rule matching results to improve CVE coverage.composer audit uses the Packagist real-time advisory database, which can supplement the timeliness blind spots that may exist in this skill's built-in rule set. Take the union of the two as the final vulnerability list.

Dependency enumeration
- Parse composer.lock to obtain package names and versions
- When handling multiple modules, output grouped by module
Vulnerability matching
- Match affected version ranges against known CVE rules
Trigger point analysis (framework)
- Identify the functional domains that known high-risk components may enter: route entry points, serialization/templates, upload/download, authentication chain
- It is recommended to use php-route-mapper to output routes and then perform "affected route inference"
Component->route association inference (required; if missing, the pipeline cannot be driven)
- Input dependencies: read routes_{timestamp}.md and params_{timestamp}.md(consistent with shared/IO_PATH_CONVENTION.md ; when persisted independently, it is often a file of the same name under route_mapping/ ; when merged in the pipeline, read the equivalent section of the overall report)
- Evidence priority:
  1. Classes/functions that directly reference the component in code (for example use Vendor\\Pkg\\{value}、new {value}、Vendor\\{value}::）
  2. Identify the functional domain where the component resides through "known access points" related to templates/serialization/upload/network (then trace back to routes)
  3. Inference based solely on naming is a fallback: it must be marked as ⚠️待验证
- For each vulnerable component, output:
  - The component's code reference locations (file path + function/class name; if there is no line number, write "to be located" but still provide the file path)
  - The sink functional domains the component may trigger (SQL/TPL/DESER/FILE/UPLOAD/SSRF/XSS/AUTH, etc.)
  - Infer affected routes/entry points (route entries must be listed one by one; omission is prohibited; each entry must simultaneously provide route_id and the route string, ensuring it can be directly backfilled to php-route-tracer）

Output report structure (mandatory)

# {project_name} - Composer 组件漏洞扫描报告
生成时间: {timestamp}
分析路径: {source_path}

## 风险统计
（按 Critical/High/Medium/Low 分类，不得省略）

## 漏洞详情（逐条列出）
=== [CVE-xxxx-xxxx] {组件} {版本} ===
- 影响版本:
- 当前版本:
- 严重等级:
- 可能触发点（推断框架）:
- 代码引用位置（证据）:
  - 文件: path/to/xxx.php
  - 证据: 函数/类/调用片段（必须给出最小可定位片段）
- 受影响路由/入口（结合 route-mapper，给出“推断理由”）:
- 路由清单（逐条列出，禁止省略）:（必须同时给出 `route_id` 与路由字符串）
- 推断理由（必须明确是 1/2/3 优先级哪种证据方式）
- 修复建议:

Key component trigger point matrix (mandatory: used to drive pipeline stage 3)