Dependency scanning: known flaws in packages

What it checks

Most of the code in a modern project comes from third-party packages. Dependency vulnerability scanning reads the project's manifest or lockfile, lists the package versions in use and compares them with advisory databases that record which versions carry a known flaw. It finds published problems in libraries; it does not look for new bugs in your own code.

Six scanners, chosen by manifest

DevFlow ships 6 scanners, one per ecosystem, and runs each one only when its manifest is present:

• govulncheck for a go.mod at the repository root;
• pnpm audit for a package.json at the root;
• dotnet list package --vulnerable for .sln or .csproj files;
• pip-audit for requirements*.txt files;
• cargo-audit for each Cargo.lock;
• osv-scanner for pom.xml and Gradle lockfiles.

The Go and Node checks look only at the root. The others walk the tree, skipping folders such as .git, node_modules, vendor and build output, because Python, Rust, .NET and JVM projects often nest their manifests under src/ or per-module folders.

When scans run

At task finalization the pipeline runs the summarizer, captures result screenshots and then scans every repository the task changed, before it assembles the merge evidence report. A repository without changes is not scanned and appears in the evidence as not run, so it is never silently missing.

A second path runs on a schedule. Each workspace gets a built-in vulnerability integration that, every 12 hours by default, fetches each repository's default branch, scans it in a temporary worktree and turns every finding into an attention item.

Bounded and fail-soft

Each scanner gets 300 seconds by default (SCANNER_TIMEOUT_SECONDS), because some of them fetch from the network and a stalled fetch must not hold the task. A scanner that fails or times out is recorded as an error for that scanner, while the others still run and report.

One shape for every ecosystem

Each tool has its own output format. DevFlow normalizes every finding to one shape: an advisory id, a severity in five buckets, the package, a short title, the fixed version when known and an advisory link. A task's summary then reads like "3 vulnerabilities: 2 high, 1 moderate" whatever the language.

Where findings show up

The scan result, with every named finding, is stored on the task as its scan report. The evidence section of the pull request body gives one line per repository: the scanners that ran when nothing was found, otherwise the count per severity, or a note that a scanner failed. A finding never blocks the pipeline, so deciding whether to upgrade a package stays with the reviewer.