dep-auditor

Dependency Security Audit

Core Principles

• Read-only by default. When the user only requests "check, audit, report," do not modify manifests, lockfiles, source code, CI, or external services.
• Use actually resolved versions and traceable advisories as evidence. Do not guess CVE, fixed versions, reachability, or licenses based on package names, version age, or memory.
• Prefer the package manager locked by the project and existing audit commands. Do not run bare npxto complete the audit, and do not execute pip install、go install、cargo install or other download commands without authorization.
• Separate "finding problems," "recommending fixes," and "executing changes." Any action that changes dependencies or lockfiles requires explicit user authorization.
• For the license section, only state facts, applicable scenarios, and items pending confirmation; do not make legal conclusions.

Workflow

1. Confirm Scope and Authorization

• Confirm the target directory, ecosystem, workspace scope, and whether both production and development dependencies need to be checked.
• Explain the commands to be run, whether the network will be accessed, and what package metadata may be sent to registries or vulnerability services.
• Check the working tree and existing changes first. Do not overwrite, revert, or mix in the user's uncommitted modifications.
• If lockfiles, tools, or the network are missing, continue completing the verifiable parts and write the coverage gaps into the report; do not fill in blanks with speculation.

2. Build a Dependency Inventory

• Locate manifests and lockfiles:package.json、package-lock.json、pnpm-lock.yaml、yarn.lock、requirements*.txt、Pipfile.lock、poetry.lock、uv.lock、go.mod、go.sum、Cargo.toml、Cargo.lock、pom.xml, Gradle files, and Gemfile.lock。
• Use lockfiles or package manager resolution results to determine actual versions; version ranges in manifests cannot prove the final installed version.
• Confirm the package manager and version from packageManager, lockfiles, wrappers, CI, and project documentation. If multiple conflicting lockfiles exist, report the ambiguity first.
• Mark direct/transitive dependencies, production/development scope, and workspace ownership. If this cannot be determined, write "unknown."

3. Choose Read-Only Checks

Only run commands that match the project's actual ecosystem and are already available in the current environment:

Ecosystem	Preferred Evidence	Read-Only Command Examples
npm	package-lock.json, project npm version	npm audit --json、npm outdated --json
pnpm	pnpm-lock.yaml, project pnpm version	pnpm audit --json、pnpm outdated --format json
Yarn	yarn.lock, project Yarn version	Use the read-only audit / outdated commands supported by that version's documentation
Python	Current virtual environment, lockfile	Run when installed pip-audit --format json; for version inventory you can use python -m pip list --outdated --format=json
Go	go.mod / go.sum	Run when installed govulncheck -json ./...；go list -m -json all
Rust	Cargo.lock	Run when installed cargo audit --json; do not install subcommands without authorization
JVM / Ruby	wrapper, lockfile, project tasks	Prefer running the repository's existing audit tasks; do not temporarily inject plugins into build files

When a command does not exist, record "not executed" and the reason, then separately propose optional installation options and wait for user authorization. Do not write missing tools as "no vulnerabilities found."

4. Verify Vulnerability Evidence

For each issue, record at least:

• advisory ID, source link, and query time;
• Actual resolved version, affected range, and known fixed versions;
• Direct / transitive dependencies and production / development scope;
• Severity source, CVSS version, and score (if provided by the source);
• Reachability evidence. Write "reachable" or "unreachable" only when a tool or code path analysis can prove it.

Distinguish between "an affected version exists in the dependency tree" and "the vulnerability can be exploited in the current program". When results from different tools conflict, present the evidence side by side and do not arbitrarily choose the more severe conclusion.

5. Verify versions and licenses

• Version health records the currently resolved version, latest stable version, deprecation notices, release date, and upgrade span. Do not automatically judge something as vulnerable merely because it "has not been updated for more than two years".
• Verify facts from package metadata, SPDX identifiers, repository LICENSE and license exceptions; when sources are inconsistent, retain the conflict.
• Do not collectively call GPL, AGPL, or other copyleft licenses "infectious licenses", and do not map them rigidly to high / medium / low risk.
• List items to be confirmed based on distribution method, linking method, SaaS usage, modification status, dual licensing, and SPDX exception. When legal judgment is needed, clearly recommend consulting compliance or legal personnel.

6. Output a Chinese report

# 📋 依赖安全审计报告

**项目与范围**：{路径、workspace、生产/开发依赖}
**扫描时间**：{含时区}
**证据基线**：{manifest、lockfile、包管理器版本、提交 SHA}

## 执行覆盖

| 检查项 | 工具与版本 | 结果 | 覆盖缺口 |
|--------|------------|------|----------|

## 漏洞证据

| 严重度 | 包与解析版本 | Advisory / 来源 | 受影响范围 | 修复版本 | 范围 | 可达性 | 置信度 |
|--------|----------------|-----------------|------------|----------|------|--------|--------|

## 版本健康度

| 包与解析版本 | 最新稳定版 | 弃用 / 维护证据 | 升级跨度 | 建议 |
|----------------|------------|-----------------|----------|------|

## 许可证事实与待确认事项

| 包与版本 | SPDX / 许可证 | 证据来源 | 使用场景 | 待确认事项 |
|----------|----------------|----------|----------|------------|

## 建议与优先级

1. {立即缓解但不修改依赖的措施}
2. {建议升级及其依据}
3. {需要补充验证或合规确认的事项}

If no issues are found, write "not found within the coverage of this tool and scope", while retaining limitations such as unscanned ecosystems, missing lockfiles, network failures, and unanalyzed reachability.

7. Remediate after explicit authorization

• Confirm the directories, packages, version ranges, package managers, and target branches that are allowed to be modified; if the working tree is not clean, isolate first or ask how to handle it.
• Use the project's native package manager and exact versions to perform minimal upgrades. Do not run npm audit fix、pip-audit --fix、--force or bulk major-version upgrades by default.
• Handle direct dependencies and transitive dependencies, and patches / minor versions and major versions, in separate batches; read the changelog, migration guide, and runtime requirements first.
• After each batch of changes, check the manifest and lockfile diff, and rerun the audit, project tests, build, and lint. External services or production behavior require additional confirmation.
• Record residual risk and rollback method. Roll back only the changes produced this time, and do not overwrite the user's original changes.

Security boundaries

• Do not output or upload tokens, private registry credentials, internal package source code, or complete environment variables.
• Use organization-approved registries, proxies, and vulnerability sources for private dependencies; do not send internal package names to unauthorized services.
• Provide verifiable temporary mitigations first, then upgrade recommendations; do not skip environment, compatibility, and rollback verification just because the severity is high.