Dependencies (SCA)

Connect a GitHub or Azure DevOps repository and AlertaVuln parses the dependency manifests it finds there, derives your tech stack, and watches the vulnerability feeds for anything that affects it. You can also curate the stack by hand.

The tech stack page listing synced packages, each with its ecosystem, resolved version and licence

The tech stack derived from a project’s manifests - every package with its ecosystem, version and licence. Demo data.

Event-driven, not scheduled

Most tooling checks your dependencies when you run a pipeline. AlertaVuln inverts that: when a new CVE is ingested from the feeds, it is immediately matched against the tech stack of every project. If it names a package you depend on, an alert is created and dispatched to your notification channels - you don’t wait for the next nightly CI run to discover you’ve been exposed for hours.

Two more triggers keep the picture current:

Backfill on arrival - when a package first enters your stack (a repo scan lands it, or you add it manually), AlertaVuln queries OSV.dev for all known vulnerabilities affecting it, not just future announcements.
Rescans - connected repositories are rescanned automatically on a per-plan cadence, and you can trigger manual rescans at any time:

Plan	Auto-rescan cadence	Manual rescans / day
Free	24h	5
Pro	6h	15
Team	2h	Unlimited
Enterprise	1h	Unlimited

Supported ecosystems

AlertaVuln parses manifests and lockfiles for eight ecosystems:

Ecosystem	Files parsed
npm (Node.js)	`package.json`, `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`
PyPI (Python)	`requirements.txt`, `Pipfile`, `Pipfile.lock`, `pyproject.toml`, `poetry.lock`, `uv.lock`, `pdm.lock`
NuGet (.NET)	`*.csproj`, `packages.config`, `Directory.Packages.props`, `packages.lock.json`
Maven (Java / JVM)	`pom.xml`, `.gradle`, `.gradle.kts`
Go	`go.mod`
crates.io (Rust)	`Cargo.toml`, `Cargo.lock`
Packagist (PHP)	`composer.json`, `composer.lock`
RubyGems (Ruby)	`Gemfile`, `Gemfile.lock`

Lockfiles win over manifests

Lockfiles describe what is actually installed; manifests describe what was asked for. CVE matching wants the former, so when a lockfile sits next to its manifest in the same directory, the resolved versions from the lockfile are used and the manifest’s declared ranges (^18.0.0-style) are dropped.

This is workspace-aware for the ecosystems that hoist a single lockfile to the repository root: npm / yarn / pnpm workspaces, Cargo workspaces, and the newer Python tooling (poetry, uv, pdm). A nested package.json with no lockfile of its own still resolves against the workspace-root lockfile.

Transitive dependencies

Lockfile parsing also records parent → child dependency edges, so when a CVE lands on a transitive package the alert shows the required by chain - the path from a top-level dependency down to the vulnerable package - answering “why is this package in our project?” without re-running a scan.

Enrichment and best-source resolution

CVE data is ingested from NVD, GitHub Advisory (GHSA), OSV.dev and the CISA KEV catalog. When sources disagree, each field is resolved independently under a “trust the best source” policy:

Field	Rule
CVSS score	Highest score wins - never under-report. Ties go to the more trusted source (NVD, then GHSA, then OSV).
Severity band	Highest band wins; ties broken by the same trust order.
Description / CWE	The most trusted source that actually has a value - the canonical text, not the longest.
KEV flag	CISA KEV is authoritative; the flag is set if any source reports it.
Published date	The earliest date seen across sources (first-seen).

From match to alert

Every matched CVE becomes an alert with a RED, YELLOW or GREEN verdict and the reasoning behind it - a GREEN alert tells you a bullet was dodged, and why. Alerts are delivered to any of the five notification channels configured on the project: Slack, Microsoft Teams, Discord, Google Chat, or a generic webhook.