Security Watch: A Daily Check of Your Dependencies and Runtimes

In 2023 about 29,000 vulnerabilities were published with a CVE number. In 2024 it was 40,009, a rise of 38%, and in 2025 it was 48,185, by Jerry Gamblin's yearly count (2025 figures). That is about 130 a day. One count of this year had 2026 past 50,000 by early November.

Most of them are not in anything you run. The work is finding the few that are, on the day they are published, in every repository you own. A team that ships with coding agents has more repositories and more dependencies than it had two years ago, and the same number of people to read advisories.

Cogny can now do that reading for you, every day.

What it checks

Once a day, for each GitHub repository connected to your workspace:

• Installed packages against published advisories. Cogny reads your lockfiles and compares the exact versions you install with the public advisory databases, including GitHub's and the Python packaging one, and the feed of known malicious packages.
• Runtimes against end-of-life dates. The Node.js, Python and other runtime versions your Dockerfiles and version files pin are checked against their published support dates. Past end of life counts as high; within 90 days of it, moderate.
• Node.js security releases. A repository pinned to an exact Node.js version is checked against the newest security release in that version line.

A match is found by comparing versions, not by a model reading advisory text. An advisory matches only when the database says the exact version you install is affected, and the version to move to comes from the advisory's own "fixed in" data.

What you get

Each match becomes a ticket on your board: which repository, which package or runtime, the advisory, the severity the advisory database gave it, and the version that fixes it.

You choose what happens next:

• File a ticket. A person starts the coding agent on it when they want.
• File a ticket and start the coding agent. For a version bump within the same major version, the coding agent opens a pull request by itself, up to 2 a day per workspace. Major upgrades, and advisories with no fix yet, stay tickets for a person.

When a later check no longer finds the problem, the ticket is closed as fixed.

If you also use auto-merge, a version bump of a package you already depend on can merge once every check passes and the merge review clears your threshold. On Cogny Sites, each deploy is checked before visitors get it, and a deploy that fails can be reverted for you. Each of those is its own setting.

What it costs

The daily check uses no credits. A coding-agent run on a ticket uses credits like any other run, whether you start it or the watch does.

What it doesn't do

• It doesn't read every lockfile yet. npm's package-lock.json, uv.lock and exact pins in requirements*.txt are read. yarn, pnpm, bun, poetry, Cargo, Go and Gemfile lockfiles are not; the report names every file it skipped, so a repository is never shown as clean because it couldn't be read.
• It doesn't check floating image tags. node:24-alpine moves on every build and pins nothing to compare. Only exact versions are checked.
• It tracks security releases for Node.js only. Other runtimes are checked for end of life.
• It doesn't read Forgejo repositories yet.
• It files at most 10 tickets per workspace a day. The rest are found again and filed the next day.
• It doesn't merge anything. The watch files tickets and, if you choose, opens pull requests. Merging is yours, or auto-merge's if you turned that on.

Turning it on

It is off by default, because it reads your repositories and files tickets by itself. It is part of Cloud and needs a GitHub repository connected for the coding agent. An owner or admin turns it on under Settings → Coding Agent → Security watch.

Your own agent can do the same over MCP: get_security_watch shows whether it is on, what the latest check read and found, and the open security tickets; update_security_watch turns it on or off and sets what a match does. The MCP documentation lists both.