Dependency & Security Alerts with OpenClaw

Common dependency security use cases

Every production codebase has dependencies. Npm, pip, RubyGems — they're how we build fast. But each dependency is a transitive tree of hundreds more. When a CVE is published, or a popular package is yanked, you need to know immediately. OpenClaw adds scheduled monitoring so you don't have to remember to run npm audit manually after every deployment.

How dependency monitoring works

OpenClaw's dependency scanner follows a simple three-step process for every repository you monitor:

Step 1: Read your lock file. Your lock file (package-lock.json, requirements.txt, or Gemfile.lock) is the source of truth — it contains exact pinned versions of every transitive dependency your project uses. OpenClaw reads this file either from your GitHub repository via the REST API or from the local filesystem, depending on how you configure the agent.

Step 2: Query the package registry. For each package in your lock file, OpenClaw queries the npm registry or PyPI JSON API to fetch the current latest version and deprecation status. This tells you how far behind you are — one major version? Three minor versions? Deprecated entirely?

Step 3: Cross-reference advisories. Every dependency and version is then checked against the GitHub Advisory Database, a free, publicly maintained database of security advisories. OpenClaw queries it via the GitHub GraphQL API, filtering by severity (CRITICAL and HIGH by default) and returning only new advisories published within the last N days so you don't get alert fatigue from old, known vulnerabilities.

The entire process runs on your schedule — daily, weekly, or monthly — and outputs a single, unified markdown report that you can push to Slack, email, or store as a GitHub wiki page.

npm/Node.js dependency scanner

The npm scanner reads package-lock.json from your repository and checks every dependency for outdated versions and known CVEs. Here's the AGENTS.md configuration:

agents:
  npm-dep-scanner:
    description: "Check Node.js dependencies for outdated versions and known vulnerabilities"
    tools:
      - github-api          # to read package-lock.json from repo
      - http-fetcher        # to query npm registry
    config:
      token: "${GITHUB_TOKEN}"
      owner: "${GITHUB_OWNER}"
      repo: "${TARGET_REPO}"
      lockfile_path: "package-lock.json"
      npm_registry_url: "https://registry.npmjs.org"
      thresholds:
        major_versions_behind: 1    # flag if 1+ major versions behind
        minor_versions_behind: 3    # flag if 3+ minor versions behind
      ignore_packages:
        - "some-internal-package"
      severity_filter: [CRITICAL, HIGH, MODERATE]  # CVE severities to include
    output:
      format: markdown
      sections:
        - critical_cves           # packages with CRITICAL severity CVEs
        - high_cves               # HIGH severity CVEs
        - deprecated_packages     # packages marked deprecated on npm
        - major_version_outdated  # 1+ major versions behind
        - minor_version_outdated  # 3+ minor versions behind
      include_fields: [package, current_version, latest_version, versions_behind, cve_ids, severity, fix_version]

Key thresholds: Adjust major_versions_behind and minor_versions_behind based on your risk tolerance. A strict team might flag anything 1+ minor versions behind; a pragmatic team might only care about major versions. The severity_filter controls which CVEs trigger an alert — filter to [CRITICAL] only if you want to reduce noise and check MODERATE CVEs manually once a week.

Ignoring internal packages: If you have private npm packages, add them to ignore_packages so the scanner doesn't waste time checking the public registry for them.

pip/Python dependency scanner

The Python scanner works similarly but reads from requirements.txt or pyproject.toml and checks against PyPI. It also flags yanked releases — a PyPI-specific concept where a maintainer pulls a version due to a critical bug or security issue.

agents:
  python-dep-scanner:
    description: "Check Python dependencies for outdated versions and vulnerabilities"
    tools:
      - github-api
      - http-fetcher
    config:
      token: "${GITHUB_TOKEN}"
      owner: "${GITHUB_OWNER}"
      repo: "${TARGET_REPO}"
      requirements_files:
        - "requirements.txt"
        - "requirements-dev.txt"      # scan dev deps separately
      pypi_api_url: "https://pypi.org/pypi"
      thresholds:
        major_versions_behind: 1
        minor_versions_behind: 2
      check_for_yanked_releases: true
    output:
      format: markdown
      sections:
        - critical_cves
        - high_cves
        - yanked_packages            # packages yanked from PyPI (security/critical bug)
        - outdated_packages
      note: "Dev dependency CVEs are flagged but marked [DEV] — lower priority for production risk."

Dev dependencies: The scanner can optionally scan separate dev requirement files. CVEs in dev dependencies (test frameworks, linters, etc.) are usually lower priority for production deployments but still worth tracking.

GitHub Advisory Database CVE monitoring

The CVE monitor is a dedicated agent that queries the GitHub Advisory Database's GraphQL API for new vulnerabilities across your monitored packages. Unlike the npm and Python scanners (which check all packages), the CVE monitor focuses on newly published advisories so you're alerted the moment a new CVE hits your stack.

agents:
  cve-monitor:
    description: "Check GitHub Advisory Database for new CVEs affecting our dependencies"
    tools:
      - github-graphql-api
    config:
      token: "${GITHUB_TOKEN}"       # same PAT — GitHub Advisory API uses same auth
      ecosystems:
        - NPM
        - PIP
        - RUBYGEMS
      packages_file: "monitored_packages.txt"  # one package name per line
      severity_filter: [CRITICAL, HIGH]
      new_since_days: 7              # only report advisories published in last 7 days
    output:
      format: markdown
      include_fields: [ghsa_id, cve_id, package, severity, affected_versions, patched_version, summary, published_at]
      sort_by: [severity, published_at]
      prompt: |
        For each new CVE, write a one-sentence plain-English explanation of what the vulnerability
        allows an attacker to do (e.g. "Allows remote code execution via malformed input to the
        parse() function"). Use the advisory summary as source material but do not quote it verbatim.

monitored_packages.txt format: Create a file listing the packages you care most about, one per line. For a Node.js app, that might be express, lodash, jsonwebtoken, etc. The CVE monitor will alert whenever a new advisory is published for any of these.

The prompt field: OpenClaw can summarise CVE descriptions in plain English. Instead of forwarding raw CVSS scores and technical jargon, the agent produces a human-readable one-liner: "Allows attackers to bypass rate limiting via repeated requests" is much more actionable than a CVSS severity number.

License compliance scanning

For commercial projects, it's critical to audit dependencies for license compatibility. Licenses like GPL-3.0 and AGPL-3.0 require you to open-source your own code if you distribute the software — a deal-breaker for many commercial products. OpenClaw's license scanner flags any problematic licenses in your dependency tree.

agents:
  license-scanner:
    description: "Flag dependencies with licences incompatible with commercial use"
    tools:
      - github-api
      - http-fetcher
    config:
      token: "${GITHUB_TOKEN}"
      owner: "${GITHUB_OWNER}"
      repo: "${TARGET_REPO}"
      lockfile_path: "package-lock.json"
      project_type: commercial       # or: open_source, internal
      flag_licences:
        - GPL-2.0
        - GPL-3.0
        - AGPL-3.0
        - LGPL-2.1
        - LGPL-3.0
        - CDDL-1.0
        - EUPL-1.1
      safe_licences:
        - MIT
        - Apache-2.0
        - BSD-2-Clause
        - BSD-3-Clause
        - ISC
        - 0BSD
        - Unlicense
      flag_unknown_licences: true    # flag packages with no SPDX identifier
    output:
      format: markdown
      sections:
        - flagged_licences           # licences requiring review for commercial use
        - unknown_licences           # packages with no licence info
      note: "This is a screening tool, not legal advice. Consult your legal team for licence compatibility decisions."
    schedule: monthly

Important: This is a screening tool, not legal advice. Always consult your legal team before shipping code with GPL or AGPL dependencies in a commercial product.

HEARTBEAT templates

Schedule your dependency and security agents with these three HEARTBEAT templates:

Weekly dependency health check

  weekly-dep-check:
    agents: [npm-dep-scanner, python-dep-scanner, cve-monitor]
    schedule: "0 9 * * 1"            # Monday at 9 AM
    output: slack://alerts-channel
    combine: true                    # single report, all three agents
    title: "📦 Weekly Dependency Health Report"

Daily CVE watch (CRITICAL only)

  daily-cve-watch:
    agents: [cve-monitor]
    config_override:
      severity_filter: [CRITICAL]    # CRITICAL only, lower noise
      new_since_days: 1
    schedule: "0 7 * * *"            # Every day at 7 AM
    output: email://security-team@company.com
    notify_only_if_changes: true     # only send email if new CVEs found

Monthly license audit

  monthly-license-audit:
    agents: [license-scanner]
    schedule: "0 10 1 * *"           # First of month at 10 AM
    output: slack://legal-team
    title: "⚖️ Monthly License Compliance Report"

Combining agents: The combine: true setting merges output from multiple agents into a single report. Useful for the weekly report so you get all dependency data at once. For the daily CVE watch, running a single agent keeps the noise down.

Sample dependency health report

Here's what a typical weekly report looks like (dark terminal preview):

Frequently asked questions

Does OpenClaw replace npm audit or pip-audit?

It complements them. npm audit and pip-audit are great for local development — you run them at the command line and get immediate feedback. OpenClaw adds scheduled monitoring so you're alerted to new vulnerabilities in already-deployed code without having to remember to run the audit manually. It also covers multiple repositories in one unified report, which is invaluable for teams managing many projects.

How does OpenClaw read my dependencies?

It reads your lock file (package-lock.json, requirements.txt, Gemfile.lock, etc.) either from your repository via the GitHub API or from the local filesystem. Lock files contain exact pinned versions, which gives more accurate results than checking ranges in package.json or setup.py. Transitive dependencies (dependencies of your dependencies) are included in the scan, so you're not blind to security issues deep in your dependency tree.

What is the GitHub Advisory Database?

A free, publicly maintained database of security advisories for open-source software. It covers npm, pip, RubyGems, Maven, Go, Rust, and more. It's the same data that powers GitHub's own Dependabot alerts. OpenClaw queries it via the GitHub GraphQL API using your existing personal access token — no separate authentication required.

Can OpenClaw automatically update vulnerable packages?

No. OpenClaw reports vulnerabilities and suggests the patched version, but it does not modify your codebase. Automated dependency updates are a high-risk operation — updating a transitive dependency might break your app in subtle ways. Use GitHub Dependabot or Renovate Bot for automated PRs, but always require human review and a passing test suite before merging.