audit-dependencies

Audit project dependencies

Use the trustlists_audit_dependencies MCP tool to scan dependency manifests and map likely vendors to public trust center records.

Supported manifests: package.json, requirements.txt, pyproject.toml, Pipfile, go.mod, Cargo.toml, Gemfile, composer.json.

Workflow

Step 1: Identify the project root

Use the workspace root or the directory containing the manifest the user is asking about. If unclear, ask.

Step 2: Decide on dev dependencies

Default to runtime-only (includeDevDependencies: false). Ask the user only if:

• They explicitly mention dev tools, build tools, or testing libraries
• The project has unusually heavy dev deps (monorepo, complex CI)

Dev dependencies usually don't run in production, so their vendor security matters less.

Step 3: Run the audit

trustlists_audit_dependencies({ projectPath: "/abs/path/to/project" })

You'll get back structured JSON with:

• totalDependencies: count of unique deps found
• withTrustCenters - count mapped to trustlists records
• withoutTrustCenters - count without a directory match
• unknownVendor - count where the tool could not identify the likely vendor
• byManager - breakdown by package manager
• results - array of { name, vendor?, hasTrustCenter, trustCenter?, certifications, csaStarLevel?, matchType }
• scannedFiles - which manifests were processed

Step 4: Produce a documentation-visibility report

The tool returns heuristic mappings and public directory data. Follow this structure:

1. Top-line summary

Audited [N] dependencies across [scanned files].
[X]/[N] map to public trust center records ([percent]% documentation coverage).

2. Coverage assessment

Describe coverage without turning it into a security grade:

• 80%+ - Most likely service vendors map to public records
• 60-79% - Useful coverage with several mappings to review
• 40-59% - Partial coverage; prioritize high-impact services manually
• <40% - The package list is a poor proxy for vendor inventory, or many mappings are unknown