Monitor CVEs and dependencies in your application

Continuous monitoring versus one scan

New advisory information can appear after a successful release check. Monitoring compares it with the project inventory already supplied. External scanning may identify selected technology signals, but it cannot infer the full package graph or every transitive dependency from a URL.

Provide an inventory tied to a release

Supply exact package versions, ecosystem and provenance. Supported inputs include npm package-lock v2/v3, CycloneDX JSON 1.5/1.6 with package URLs, and supported manual entries. Keep environment, build or commit and collection time. Inventory import parses data; it does not run package installation scripts.

Primary sources: Primary reference 1 · Primary reference 2

Continue: Add security checks to CI/CD and GitHub Actions

Supported ecosystems and formats

The supported ecosystems are npm, PyPI, Maven, Go, crates.io, Packagist, NuGet, RubyGems, Hex and Pub. This does not mean every native manifest in those ecosystems is accepted. Use the documented SBOM format with purl and exact versions; npm also has direct package-lock support.

Distinguish advisory sources and evidence

OSV supplies package/version advisory data; NVD provides additional vulnerability context and CISA KEV adds known-exploitation context. A match does not prove exploitation of your application. The reproducible snapshot is GHSA-j8rh-479h-cp32 for axios: 1.8.1 is affected in its stated range; 1.20.0 is the recorded fix boundary as of 2 November 2026.

Primary sources: Primary reference 1 · Primary reference 2

Continue: Next.js security: check APIs, Server Actions and secrets

Prioritize with application context

Check the affected version, vulnerable feature, exposure, prerequisites and deployed environment. A present package is not proof that the affected feature is reachable. Unknown versions remain uncertain. Do not invent an exploitation conclusion or automatically run an active CVE scenario merely because an inventory matches.

Understand the notification

An alert should identify the project, package, version, advisory and relevant inventory or revision. Notifications are available in the workspace and through configured Telegram conditions, not email. A source outage or stale inventory affects confidence; a general CVE news feed is not project-specific monitoring.

Project: Synthetic fixture
Package: npm / axios 1.8.1
Advisory: GHSA-j8rh-479h-cp32
Inventory: guide-before
Next step: update, deploy and submit the new inventory.

Primary sources: Primary reference 1 · Primary reference 2

Continue: Vibe coding security: check your application before launch

Verify the updated release

Update the dependency, build and deploy the application, then submit an inventory for that revision. The example runs the actual parser and matcher against two synthetic lockfiles: guide-before matches this advisory; guide-after does not. It does not claim that version 1.20.0 has no other advisories or that a customer deployment was changed.

Keep the evidence current

Refresh inventory after every relevant deployment and review source freshness. Withdrawn advisories and changed ranges can change the result. A manual snapshot does not prove current production composition. Keep the original match, the fixed build identifier and the new inventory to support an auditable resolution.

Continue: Prepare an automated API security assessment

Reproducible examples and downloads

Tested with: guides-1 · OSV snapshot 2026-11-02

All example data is synthetic. Downloads contain no active keys or customer records. Run examples only in your own isolated test environment.

• inventory-guide-before.json — example / template
• inventory-guide-after.json — example / template

Example verification record: versions, actions and observations

Questions and answers

Editorial team and sources

Scantelio editorial team: methodology and limitations. Example verified: 2026-11-02.

• Reference 1 · google.github.io
• Reference 2 · www.nist.gov
• Reference 3 · api.osv.dev