Skip to content

Docker · Kubernetes · Trivy · CISA KEV · EPSS

Container image vulnerability scanning, notifications, and remediation

KestreLynx is open-source software that regularly scans images used by running Docker and Kubernetes containers with Trivy. It sends changes since the last scan and priorities based on severity, CISA KEV, and EPSS to Slack or a webhook. For Docker, Compose, and Kubernetes, remediation plans and pull requests (experimental) support remediation by comparing rescans under the same conditions and creating GitHub pull requests, with both features disabled by default.

Setup GitHub

Open source · AGPL-3.0

# security-alerts

KestreLynx APP 9:00 AM

🛡️ KestreLynx [prod-vps] — scan results for 2026-06-28 09:00
12 images scanned, 1 affected
Changes since the last scan.

🆕 New since last scan (1)
Image: nginx:1.25.3

◆ libnghttp2-14
Installed: 1.52.0-1
Fixed in: 1.52.0-1+deb12u1
Upgrade risk: 🟢 distro security patch
Findings: CRITICAL 0 / HIGH 2

Top CVE: CVE-2023-44487 · HIGH · EPSS >99% (+1 more CVE(s) in this package)
Exploitation: CISA KEV (exploited in the wild)
References: advisory · vendor advisory · 💬 HN (166 pts)

📌 Open now: 🚨 1 act-now

Sample notification in the default diff mode. Values are illustrative, not from a live scan.
  • New findings “New since last scan” names the image and package.
  • Fix availability “Installed” and “Fixed in” show the current and fixed versions.
  • Priority “Open now” counts by priority; KEV and EPSS give the context.

Follow changes between scans

Diff notifications highlight new findings, added CVEs, newly available fixes, priority escalations, and findings that leave the monitored scope. Open findings still trigger a short update when nothing changes; Monday notifications include a full report by default.

Prioritize with KEV and EPSS

KestreLynx combines severity with CISA KEV and EPSS data to group findings into Act now, Watch, and Low. These priorities help guide review; they do not establish whether your environment can be exploited.

Scan with Trivy, review fixes by package

Trivy scans report HIGH and CRITICAL vulnerabilities by default, including findings without available fixes. Package summaries show fixed versions when available and annotate upgrade risk, without guaranteeing compatibility.

Remediation plans and pull requests (experimental)

Kubernetes remediation plans show published-image update candidates, guidance for pulling floating tags again, and language-package update candidates. Kubernetes PRs support image tag updates in plain manifests, Kustomize images[].newTag updates, image tag updates in Helm values, and base image updates in Dockerfiles, plus npm / pnpm / pip / uv updates when work Pods are configured. For npm, pnpm, and uv, this also includes re-resolution through dependent packages under the supported conditions. For Docker and Compose, KestreLynx can propose changes to three kinds of source:

  • Published image tags in Compose files
  • Base image tags in Dockerfiles
  • Language-package dependencies managed with npm, pnpm, pip, or uv

Both remediation plans and pull requests are disabled by default. Plans select candidates, compare scans, and notify without writing to GitHub or starting work containers. Enabling pull requests separately allows GitHub changes and Docker work containers or user-configured Kubernetes work Pods for language-package updates.

These screenshots show actual output from the demo repository, which intentionally pins older images and dependencies, with the generated PRs available on GitHub.

The Slack fix plan lists three created PRs and a Dockerfile base update marked “Needs a decision” because the candidate introduces new findings.

Slack fix plan showing Compose, pip, and npm update PRs and a Dockerfile base update requiring a decision

PR #1 proposes updating nginx from 1.27.0 to 1.27.5 and records the candidate scan comparison: 17 targeted findings resolved, 86 remaining.

GitHub PR body with What, Change, and Verification sections, including 94 other findings remaining and no introduced findings

After PR #1 was merged and the running proxy container was replaced with nginx 1.27.5, the next scan reported resolutions for four packages with history carried over.

Slack scan notification showing the nginx image update and resolutions for libabsl20220623, libavif15, libfreetype6, and liblzma5

A candidate or pull request does not mean the running image has been fixed. Review the comparison scope and run your CI before merging; rebuilding and deploying remain separate steps.

See Remediation plans and pull requests (experimental) for setup, notifications, and permissions.

Scope and access

For self-hosted services where you want to review vulnerability changes in the images your containers are running.

Docker
One instance per host covers running containers across Compose projects and standalone deployments.
Kubernetes
An in-cluster Deployment discovers running containers across all or selected namespaces through read-only API operations, with additional permissions limited to a work namespace only when language-package updates are configured.
Verified scope
Single-node K3s with containerd on linux/amd64. Multi-node clusters, arm64, managed Kubernetes, and authenticated private registries remain unverified. Verification record
Discovery
Containers must be running when discovered. Kubernetes native sidecars are included; ordinary init containers and ephemeral containers are excluded.
Docker socket access
KestreLynx reads container information and Trivy reads images through the Docker API; with remediation pull requests enabled, KestreLynx also creates, starts, and removes work containers for language-package updates. Mounting the socket with :ro does not restrict API permissions and does not need to change to :rw, so the mounted image must be trusted.

Setup

These steps use Docker Compose. You need a Docker host with Docker Compose and at least one notification destination: a Slack Incoming Webhook, a Slack bot with a destination channel, or a generic webhook. For Kubernetes, see Setup instructions.

  1. Clone the repository and enter its directory

    git clone https://github.com/kitsunetrail/kestrelynx.git
cd kestrelynx

  2. Create the configuration file

    Copy the example to config.yml and set a notification destination.

    cp config.example.yml config.yml
${EDITOR:-vi} config.yml

  3. Check the timezone and start KestreLynx

    Scan times follow TZ in docker-compose.yml, which defaults to UTC; use Asia/Tokyo for Japan time.

    ${EDITOR:-vi} docker-compose.yml
docker compose up -d

  4. Check startup and scans in the logs

    The example configuration runs one scan at startup, then scans daily at 09:00.

    docker compose logs -f

Keep the kestrelynx-state volume when recreating the container to preserve the history used for change notifications and first-seen dates.

Trial reports are welcome in Discussions.

Documentation, development logs, and articles

Report a bug or suggest an improvement on GitHub Issues.