Perform a software package vulnerability audit using SecDB.
## What this tool does
Analyzes a list of software packages identified by PURL (Package URL) and returns
vulnerability information plus a Markdown summary. The audit results are based
exclusively on the package list provided.
## When to use this tool
Use this tool when the user wants to determine:
- whether application dependencies contain known vulnerabilities
- whether a project is affected by security advisories
- which packages require patching or upgrading
## Supported ecosystems
- **npm** - Node.js packages (e.g. pkg:npm/lodash@4.17.21)
- **maven** - Java/JVM packages (e.g. pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1)
- **pypi** - Python packages (e.g. pkg:pypi/django@4.2.0)
- **gem** - Ruby gems (e.g. pkg:gem/rails@7.0.0)
- **cargo** - Rust crates (e.g. pkg:cargo/openssl-src@111.10)
- **nuget** - .NET packages (e.g. pkg:nuget/Newtonsoft.Json@13.0.1)
- **golang** - Go modules (e.g. pkg:golang/github.com/gin-gonic/gin@1.9.1)
- **composer** - PHP packages (e.g. pkg:composer/symfony/symfony@6.4.0)
- **pub** - Dart packages (e.g. pkg:pub/dio@5.4.0)
- **swift** - Swift packages (e.g. pkg:swift/github.com/apple/swift-nio@2.65.0)
- **hex** - Erlang and Elixir packages (e.g. pkg:hex/phoenix@1.7.0)
## Inputs
- **purls**: list of Package URLs, one per entry.
Generate them from your project manifest files:
- Node.js: package.json / package-lock.json
- Python: requirements.txt / Pipfile.lock / pyproject.toml
- Ruby: Gemfile.lock
- Go: go.mod / go.sum
- Rust: Cargo.lock
- PHP: composer.lock
- Java: pom.xml / build.gradle
- .NET: *.csproj / packages.lock.json
## Outputs
- **report**: structured JSON objects describing the advisories affecting the audited packages. Packages without known vulnerabilities are not listed.
- **summary**: Markdown summary including vulnerable packages, total CVEs, and severity breakdown.
- **audited**: number of PURLs that were checked.
- **ignored**: PURLs that were not checked because they are malformed or from an unsupported ecosystem.
## LLM usage guidelines
- Never guess whether a package is vulnerable — always call this tool.
- Only submit PURLs from the supported ecosystems listed above; others are returned in `ignored`.
- Tell the user about any `ignored` PURL: they were not checked, so they are not known to be safe.
- The `summary` is already Markdown and can be shown directly.
- Use `report` when deeper technical analysis is required.
ConnectorNo auth