Vulnerability Monitoring: How to Detect New Advisories That Affect You

Last verified on Nov 8, 2026.

A new advisory is only a problem if it matches something you run. Thousands of CVEs are published, and almost none apply to your stack. The work is matching: knowing precisely what you run, then comparing that list with each new advisory quickly enough to act while it still matters.

That makes this a two-sided problem. If your inventory is wrong or stale, the best feed in the world will miss things. If your feed is slow, a correct inventory only tells you about yesterday's news.

What the evidence looks like

You want an alert record that names the advisory, the package, the affected version you run and where it runs. This example shows the shape:

{
  "advisory": "GHSA-xxxx-xxxx-xxxx",
  "cve": "CVE-2026-00000",
  "package": "example-web-framework",
  "ecosystem": "npm",
  "installed": "4.18.1",
  "fixed_in": "4.18.3",
  "services": ["checkout-api", "admin-ui"],
  "kev": false,
  "epss": 0.04
}

The identifiers above are placeholders for an example, not a real advisory.

How to detect it

1. Build the inventory. Generate it from lockfiles in CI and from the images you actually deploy. Also record runtime versions, such as the language runtime and the base operating system. Emit it as data you can query, and log the version at startup so running services report themselves:

2026-11-08T07:00:02Z level=info msg="service starting" service=checkout-api version=2026.11.3 runtime=node-22.11.0

2. Pick one or more feeds. OSV offers a query API: send a package and version, and get back the vulnerabilities that affect it.

curl -s https://api.osv.dev/v1/query -d '{
  "package": { "name": "jinja2", "ecosystem": "PyPI" },
  "version": "3.1.4"
}'

The request format comes from the OSV query documentation. Names are matched exactly and are case-sensitive, so use PyPI and not pypi. You can also give a package URL, but not a version in both places, which returns a 400. GitHub's Dependabot alerts cover repositories on GitHub and fire when a new vulnerability enters the GitHub Advisory Database or your dependency graph changes. The NVD offers a CVE API for lookups by ID.

3. Run the match on a schedule and on every dependency change. A scheduled job that re-queries the full inventory each day catches advisories published after you last built.
4. Store results and alert only on new pairs of advisory and service, so a known open finding does not page anyone twice.

SELECT f.advisory, f.package, f.installed, f.service, f.first_seen
FROM findings f
LEFT JOIN notified n ON n.advisory = f.advisory AND n.service = f.service
WHERE n.advisory IS NULL
  AND f.first_seen > now() - interval '1 day'
ORDER BY f.first_seen DESC;

Thresholds and pitfalls

Rank before you alert. CISA keeps the Known Exploited Vulnerabilities catalog and recommends using it as an input to prioritization. EPSS publishes a 0 to 1 score estimating the probability that a CVE will be exploited in the next 30 days. A reasonable rule: page when a finding is in KEV or has a high EPSS and the service is internet-facing. Open a ticket for the rest, ordered by severity.

Pitfalls:

• Transitive dependencies. A package you never imported directly can still be in your tree. Scan the resolved lockfile, not the manifest.
• Version ranges. An advisory fixed in one release line may still affect another. Trust the feed's ranges and not a string comparison.
• Unreachable code. A vulnerable function you never call is lower risk, but only mark it after someone checks.
• Images. A base image carries its own packages. Scan built images, not just application dependencies.
• Alert fatigue. If every low-severity finding pages someone, the page that matters will be ignored.

What to do when it fires

Confirm exposure first: is the vulnerable code reachable from the internet or only internal? Then choose between upgrading, applying a mitigation such as a configuration flag or a WAF rule, or accepting the risk with an expiry date. While you patch, search your logs for exploit attempts against the affected endpoint, as described in attack payloads.

Related guides: supply chain attacks covers malicious packages and risky code covers weaknesses in your own code. For connecting a source repository, see the GitHub page. Startup version logs can travel over OpenTelemetry, and the integrations list covers other sources.