Daily summary. Scan complete across 8 active projects. New CVEs: 2 critical (CVSS 9.0+), 5 high (CVSS 7.0-8.9), 3 medium. Critical: npm library auth-utils in 3 projects, patch 5.4.4 → 5.4.7 (compatible minor upgrade). High: Maven dependency logging-core requires a major bump (4.x → 5.x) with API changes in 12 call sites.
AGENT · DEPENDENCY WATCHER
CVEs on dependencies reach the team before they become an incident.
Dependency Watcher monitors third-party dependencies across the customer's projects daily (npm, Maven, PyPI, NuGet, RubyGems). It cross-references public CVE databases (NVD, GitHub Advisory). It proposes upgrades that are compatible with the customer's code version constraints. Immediate alert to the security team on high severity.
Dependency Watcher at work.
Confirmed. Critical upgrade scheduled for today; I'll slot the major bump as a sprint on Friday.
Decisions recorded. Next scan: tomorrow morning.
Why it exists.
Most code in a modern company is made up of third-party dependencies (open source libraries, commercial SDKs, frameworks). A published vulnerability on one of those dependencies (a CVE) can expose the company to real compromise. Manual CVE monitoring across all dependencies of all projects is impractical at the volume.
How it scans every day.
Dependency Watcher runs on a daily schedule. For each customer project: it reads the dependency files (package.json, pom.xml, requirements.txt, .csproj, Gemfile), retrieves the versions in use, and cross-references them against public CVE databases (NVD, GitHub Advisory, sector-specific registries). For each vulnerability found: it classifies the severity (CVSS score), proposes an upgrade to the patch version, and evaluates compatibility.
The decision stays with the team.
The upgrade decision stays with the customer's team. The agent proposes automatic PRs only for pre-approved patch and minor upgrades; for major upgrades the PR is a proposal to review.
Three technical functions that change the way CVEs are handled.
Information security manager
Sees the full vulnerability picture across projects, aggregated by severity. Patching capacity is sized to actual risk.
10 active controls
policy.evaluate 14:02:11 ALLOW
pii-detector 14:01:58 BLOCK
tool.invoke 14:01:42 WARN
memory.write 14:01:09 BLOCK
DevOps lead
Receives upgrade proposals ordered by severity with a compatibility assessment. Schedules patching weeks that fit the team's development pipeline.
Proposal no. 2024-081 In review
Missing disclosure
MiFID II art. · regulated financial instrument
Alt. 1 …in compliance with MiFID II and applicable supervisory provisions.
Alt. 2 …with full disclosure attached to the offer document.
Audit trace recorded · 14:31
Senior developer
Focuses on upgrades that require code changes (major version bumps), while patch and minor upgrades go through the standard pipeline.
$ git clone github.com/polyant-ai/polyant
$ cd polyant
$ docker compose up -d
polyant agent runtime · active
AGPLv3 · code within the customer's perimeter
12 new CVEs in a morning summary, three decisions from the lead.
Dependency Watcher reads 8 projects every morning.
For a B2B SaaS company with 8 active projects, the agent runs every day. The daily summary reaches the security team's Slack channel. The agent identifies 12 new CVEs across the customer's projects: 2 critical, 5 high, 5 medium.
Three severity classes, each with a compatibility assessment.
The 2 critical CVEs affect a common npm library present in 3 of the 8 projects. The patch is available as a compatible minor upgrade (no API changes). The agent proposes an immediate upgrade. The 5 high CVEs affect a Maven dependency. The patch requires a major version bump with API changes that touch several call sites in the code. The agent flags the required upgrade with a breakdown of the code points to change and proposes a dedicated branch for a coherent migration.
Upgrade today, sprint next week, backlog for medium.
The summary reaches the security team with the severity classification, the proposed upgrades, and the compatibility assessment. The DevOps lead decides: immediate upgrade of the critical CVEs today; a dedicated sprint for the high CVEs next week; regular backlog for the medium ones.
Declarative rules from the security team, version-controlled.
Rules are declarative. The security team defines in a human-readable format the severity thresholds for immediate alerts, compatibility rules for major version bumps, and the summary format. Rules live in the customer's repository, version-controlled, validated at agent startup.
- Language
- TypeScript (Node.js)
- LLM model
- customer's choice: Anthropic, OpenAI, Mistral, open source models hosted internally, AWS Bedrock for a private model
- Built-in controls used
- pii-detector, credential-detector, tool-rate-limit
- Native channels
- Slack, Telegram, OpenAI-compatible HTTP
- CVE database integration
- NVD, GitHub Advisory via webSearch or dedicated adapter during delivery
- GitHub, GitLab, Bitbucket integration
- native ghPR/ghIssue tools for GitHub; adapter during delivery for others
- Memory
- persistent per instance, pgvector + PostgreSQL FTS on the customer's dependency portfolio
- Registry
- immutable, queryable with a standard SQL client (DORA, NIS2 inspectable audit)
Frequently asked questions about the agent.
For patch and minor upgrades on projects pre-approved by the DevOps team, the agent can propose an automatic PR for the team to review and merge. For major upgrades or core projects, the agent proposes the upgrade as a task for a dedicated sprint. The merge decision always stays with the human team.
Snyk, Dependabot, and similar tools provide CVE monitoring and upgrade proposals as a dedicated service. Dependency Watcher covers the same function but is integrated into Polyant as part of the customer's IT squad, shares the audit registry with the other agents, and operates under the unified runtime governance. For customers already using these tools, Dependency Watcher can work in aggregation with them or replace them.
When the proposed upgrade breaks the project's tests (detected in CI/CD), the agent reports the failure with a breakdown of the failing tests. The DevOps lead decides whether the upgrade goes into a dedicated branch with test fixes, or is deferred. The automatic-block rule for failing tests is declarative.
The typical pattern for Dependency Watcher is 3-6 weeks. Discovery one week, severity and compatibility rule configuration 1-2 weeks, integration with the customer's repositories 1-2 weeks, hand-off to the security team one week.
From a 30-minute conversation to the squad in production.
A 30-45 minute conversation to understand how Dependency Watcher would be configured for the customer's case. Repositories, languages, team severity thresholds.