Schedule icon
Script icon
Docker icon
If icon
SlackIncomingWebhook icon
Set icon

PipAuditWatch - Python dependency CVE watcher

A Kestra blueprint that runs pip-audit against your requirements file and alerts on Slack about known CVEs, without spamming.

Categories
Infrastructure

How it works

  1. find_vulns (io.kestra.plugin.scripts.python.Script) writes your pasted requirements to a file and runs pip-audit against the OSV database, saving the JSON report. It collects every vulnerability, builds a stable id per finding (package@version:vuln-id), and compares against the KV state so only new findings alert. The Slack text names the package, the installed version, the CVE id with aliases, and the fixed version when one is published.
  2. maybe_alert (io.kestra.plugin.core.flow.If) posts the Slack alert only when there is something new.
  3. save_state (io.kestra.plugin.core.kv.Set) writes back the current finding ids. Bumped packages drop out on their own, so a reintroduced vulnerability alerts again, and clean reruns stay quiet.

What you get

  • A daily supply-chain check on your Python dependencies, no scanner to install or maintain.
  • Slack alerts with the actionable trio: what is vulnerable, which CVE, and which version fixes it.
  • No alert spam: the KV-backed memory remembers reported CVEs, and fixed packages stop alerting.
  • Quiet runs when everything is clean.

Who it's for

Anyone shipping Python who wants to know about known CVEs in their dependencies without wiring up a full SCA platform. Paste requirements, get alerts.

Why orchestrate this with Kestra

Running pip-audit by hand works once; remembering to run it daily does not. As a flow it runs on schedule, keeps every scan's findings where you can audit them, and only bothers you when something new appears. It is also the natural sequel to BumpPilot: BumpPilot bumps your dependencies, this one tells you why you must.

Prerequisites

  • Kestra with the Docker task runner available.
  • A Slack Incoming Webhook URL.
  • Network access to the OSV database from the task container (default).

Secrets

Secret What it is
SLACK_WEBHOOK base64-encoded Slack Incoming Webhook URL

In Kestra OSS, secrets come from environment variables prefixed with SECRET_ and must be base64-encoded.

Quick start

  1. Start Kestra with the secret above as a SECRET_ environment variable.
  2. Import this flow and run it with the default requirements: the Slack alert lists the known urllib3 CVEs, while the other pinned packages report clean.
  3. Paste your real requirements and run again: new findings alert, known ones do not repeat.
  4. Bump a vulnerable package and run again: quiet for that package.

How to extend

  • Read requirements from a Git repo instead of pasting, by adding a git clone step before the audit.
  • Fail the run (instead of just alerting) when a critical CVE appears, by adding a Fail task on severity.
  • Scan multiple requirement files by looping with a ForEach task.
  • Route alerts to PagerDuty or Opsgenie by swapping the Slack task for another notification task.

Inputs

Input Type Default What it does
requirements STRING a small pinned set, incl. urllib3==1.26.5 paste your requirements.txt content here
slack_webhook STRING (required) Incoming webhook URL of the Slack channel for alerts

Links

Pitfalls

  • pip-audit only knows about published vulnerabilities. A brand-new CVE can take hours to land in OSV, so a clean scan is "no known CVEs", not "secure".
  • The default requirements pin a known-vulnerable urllib3 so the first run demonstrates the alert. Replace it with your real requirements before relying on the schedule.
  • Findings are keyed by package, version, and vuln id. Re-pinning the same vulnerable version does not re-alert; changing the version does.
  • The flow is strictly read-only. It never modifies your requirements or installs anything outside its own container.
See How

New to Kestra?

Use blueprints to kickstart your first workflows.