Setting Up Continuous Dependency Monitoring From Scratch

Most organizations scan their dependencies on a schedule: once a week, once a sprint, or once a release. Between scans, new vulnerabilities are disclosed, advisories are published, and the organization's exposure changes without anyone knowing. The Log4Shell vulnerability was disclosed on a Thursday. Organizations that scanned weekly on Mondays were exposed for four days before their next scan detected it.

Continuous dependency monitoring eliminates this gap. Instead of scanning on a schedule, you monitor vulnerability feeds in real time and correlate new disclosures against your dependency inventory as they happen. Here is how to set it up.

Architecture Overview

A continuous monitoring system has four components:

1. Dependency inventory -- a current, accurate record of every dependency in every project
2. Vulnerability feed -- a stream of new vulnerability disclosures, updated continuously
3. Correlation engine -- the logic that matches new disclosures against your inventory
4. Notification system -- the mechanism that alerts the right people when a match is found

Each component can be implemented with varying levels of sophistication. A basic setup uses SBOM files, OSV.dev's API, a cron job, and email alerts. An advanced setup uses a live dependency graph, multiple advisory feeds, real-time stream processing, and integrated ticketing.

Step 1: Build the Dependency Inventory

The inventory is the foundation. If it is incomplete or stale, monitoring is unreliable. You need:

SBOM Generation

Generate SBOMs for every project in your portfolio. Use CycloneDX or SPDX format. The SBOM must include:

• Every direct dependency with exact version
• Every transitive dependency with exact version
• The package ecosystem for each dependency (npm, PyPI, Maven, etc.)
• The project name and version the SBOM describes

Automated Regeneration

SBOMs must be regenerated whenever dependencies change. The most reliable trigger is CI/CD pipeline execution: generate a new SBOM on every build that modifies the dependency tree. At minimum, regenerate weekly.

Centralized Storage

Store all SBOMs in a central location where the correlation engine can access them. This can be a database, an object store, or a dedicated SBOM management platform. The storage must support querying by package name and version across all SBOMs.

Step 2: Configure Vulnerability Feeds

Primary Feeds

OSV.dev: The Open Source Vulnerabilities database aggregates advisories from multiple sources (GitHub, npm, PyPI, RubyGems, Go, Rust, etc.) in a standardized format. The API supports querying by package and version. This is the best single source for open source vulnerability data.

NVD (National Vulnerability Database): The US government's comprehensive CVE database. Coverage is broader than OSV but data is often delayed by days or weeks after initial disclosure. Use as a supplementary source, not the primary one.

GitHub Security Advisories: GitHub's advisory database covers packages across multiple ecosystems and is updated quickly. The GraphQL API supports efficient polling.

Ecosystem-specific feeds: npm audit advisories, PyPI safety database, RubyGems advisory database, and similar ecosystem-specific sources often have the freshest data for their respective ecosystems.

Feed Polling Strategy

For near-real-time monitoring, poll primary feeds every 15 to 30 minutes. For each poll, request only advisories published or modified since your last poll. Most APIs support this with timestamp-based filtering.

For NVD, which has rate limits, poll hourly and use the modified-date filter to get incremental updates.

Step 3: Build the Correlation Engine

The correlation engine's job is simple in concept: when a new advisory arrives, check whether any project in your inventory uses the affected package at an affected version.

Basic Implementation

For a straightforward implementation:

1. When a new advisory is received, extract the affected package name, ecosystem, and version ranges
2. Query your SBOM inventory for any project that includes this package at an affected version
3. For each match, generate an alert with the advisory details and affected project information

Handling Version Ranges

Advisory version ranges use ecosystem-specific notation. npm uses semver ranges. Python uses PEP 440. Maven uses its own version range syntax. Your correlation engine must parse version ranges correctly for each ecosystem.

Use established libraries for version comparison rather than implementing your own:

• semver for npm packages
• packaging for Python packages
• Maven Artifact for Java packages

Deduplication

The same vulnerability may appear in multiple feeds. Deduplicate by CVE ID when available, and by package-name plus advisory-ID for advisories without CVEs. Keep a record of previously alerted vulnerabilities to avoid sending duplicate notifications.

Reachability Analysis

Advanced correlation engines include reachability analysis: does the project actually use the vulnerable function? This requires call graph analysis and is computationally expensive, but it dramatically reduces false positives. A critical vulnerability in a package you depend on but never call is lower priority than one in a function you invoke directly.

Step 4: Configure Notifications

Alert Routing

Route alerts to the team that owns the affected project. This requires a mapping from projects to teams, which should be maintained alongside your SBOM inventory.

Alert urgency should match vulnerability severity:

• Critical with known exploit: Immediate notification (Slack, PagerDuty, SMS)
• Critical without known exploit: High-priority notification (Slack, email)
• High severity: Standard notification (email, Jira ticket)
• Medium/Low severity: Batch notification (weekly digest)

Alert Content

Each alert should include:

• The vulnerability identifier (CVE, GHSA, etc.)
• Severity score and qualitative rating
• Affected package and version range
• Which of your projects are affected
• Whether a fixed version is available
• Direct link to the advisory for details

Reducing Alert Fatigue

Alert fatigue is the biggest operational challenge in continuous monitoring. Mitigate it by:

• Suppressing alerts for vulnerabilities that are not reachable in your code
• Grouping related alerts (same CVE affecting multiple projects)
• Allowing teams to suppress alerts for accepted risks (with documented rationale and expiration date)
• Tuning severity thresholds per project based on exposure (internet-facing vs. internal)

Step 5: Integrate with Remediation Workflows

Monitoring without remediation is just expensive awareness. Connect your monitoring system to your remediation workflow:

Automated Ticket Creation

When a vulnerability match is found, automatically create a ticket in your issue tracker (Jira, Linear, GitHub Issues) assigned to the owning team. Include the vulnerability details, affected project, and remediation guidance.

Automated Fix Proposals

For vulnerabilities with available fixes, automatically generate a pull request that updates the affected dependency. The team's job shifts from investigating and fixing to reviewing and merging.

SLA Tracking

Track remediation against defined SLAs. If a critical vulnerability is not remediated within 72 hours, escalate. The monitoring system should track not just detection but also time-to-remediation.

Operational Considerations

Scaling

As your portfolio grows, the number of SBOM-to-advisory comparisons grows multiplicatively. Indexing your SBOM inventory by package name allows constant-time lookups instead of scanning every SBOM for every advisory. At scale, consider a database-backed inventory with proper indexing.

Testing the System

Periodically verify that your monitoring system actually works:

• Introduce a known-vulnerable dependency into a test project and verify that an alert fires
• Check that advisory feed polling is functioning (monitor for gaps in advisory timestamps)
• Verify that alert routing delivers notifications to the correct teams

Metrics

Track:

• Mean time from advisory publication to alert delivery
• False positive rate (alerts for packages not actually used, or for non-reachable code paths)
• Alert-to-remediation time
• Percentage of portfolio covered by current SBOMs

How Safeguard.sh Helps

Safeguard.sh provides continuous dependency monitoring out of the box, including automated SBOM generation, real-time vulnerability feed correlation, intelligent alert routing, and integrated remediation workflows. Instead of building and maintaining a custom monitoring pipeline, teams can deploy Safeguard's monitoring capability across their entire portfolio and start receiving actionable alerts immediately. The platform handles feed aggregation, version range parsing, deduplication, and reachability analysis, turning what would be a months-long infrastructure project into a configuration task.