Watches every service you run, checks its version against published security advisories, and sends a Telegram alert when something needs an urgent update.
Built after a Gitea instance was compromised via a CVE that had been public for two months while the deployment was only one minor version behind. cve-watcher exists so that gap never happens again.
- Inventory — discovers running services and their image versions from:
- the local k3s cluster (read-only ServiceAccount), and
- Coolify instances (Hetzner VPSs, client apps) via the Coolify API with a read-only token.
- Match — maps each service to a product (CPE / package) and queries advisory sources (NVD, GitHub Security Advisories, CISA KEV) for notices affecting that exact version.
- Alert — sends one Telegram message per affected service, grouped with the max CVSS and the version to update to at least, labelled with where it runs (kubernetes namespace or coolify server). Deduplicated so you hear about each problem once; KEV (known-exploited) findings flagged as urgent.
- Diun — tells you a new tag exists. It has no idea whether your running version is vulnerable.
- Trivy Operator — deep image scanning, but k8s-only, heavyweight, and noisy; no Coolify support. cve-watcher is a thin, targeted watcher, not a scanner.
- Renovate — updates dependencies in repos; doesn't watch running deployments or send ops alerts.
If one of those fits your need better, use it. cve-watcher exists for the specific gap: running version → published advisory → urgent alert.
Single static Go binary in a FROM scratch container, deployed as a
k3s Deployment with:
- a read-only ClusterRole over workload discovery (get/list/watch only, no secrets access),
- a small PVC for alert-dedup state and the advisory cache,
- a Secret holding the Telegram bot token, NVD/GitHub tokens, and Coolify tokens — never in the config file,
- a default-deny egress NetworkPolicy: DNS, the k8s API, and outbound HTTPS to the advisory + notification endpoints.
The full runbook — credential setup with least-privilege scopes, the manifests in deploy/, and the step-by-step apply order — is in docs/DEPLOY.md. The design spec is REQUIREMENTS.md.