Automated Vulnerability Scanning for Every Software Release
How to automatically scan your application for CVEs in CI/CD and attach the report to every release your customers see in Distr.
The security review email lands in your inbox before your customer will approve deploying the new version. “Can you provide a vulnerability report for the packages and container images in this release?”
You don’t have one ready. You pull up the code, run a scan manually, format it into something readable, attach it to an email. The customer reviews it. Finds a medium-severity CVE in a transitive dependency you’ve known about for two weeks. Now there are more emails.
This is the loop for most ISVs shipping software to on-prem or BYOC environments. Every release triggers a security review. Every security review involves a scramble.
It doesn’t have to work that way.
Why Enterprise Security Reviews Keep Stalling Software Deployments
The problem isn’t that your software has vulnerabilities. Every piece of software does. The problem is that your customers have to ask — and you have to scramble to answer.
Customer security teams don’t trust that you’ve already looked. They need to see the report themselves. And if you can’t produce one quickly, the deployment sits in a queue while you do.
The vendors handling this well have made vulnerability reporting part of the release process itself. Every version ships with a report attached. When the customer asks, you point to it. When they don’t ask, they can still find it.
How Automated Vulnerability Scanning Works with Distr
Distr doesn’t run the scans itself — you do that in your CI/CD pipeline using osv-scanner, Google’s open-source vulnerability scanner. What Distr does is attach the results to the application version so customers see them directly in their portal.
The setup is three jobs in your GitHub Actions workflow:
- build — Builds and pushes your container images to the registry
- vulnerability-scan — Runs osv-scanner against your source dependency lockfiles and your container images, then generates the report
- distr-docker (or distr-kubernetes) — Creates the Distr version and attaches the scan report as a customer-visible resource
What gets scanned matters. Scanning only your requirements.txt misses vulnerabilities in your base image and system packages. Docker image vulnerability scanning alone misses your application-level dependencies. osv-scanner does both in the same job — lockfile scanning for source dependencies, container vulnerability scanning for image layers — and produces a single unified report classified by CVSS severity: Critical, High, Medium, Low.
The report is non-blocking. It always exits with code 0. Vulnerabilities are reported, not enforced. You decide whether a known CVE is worth holding up a release. Your customers get full visibility either way.
What the Vulnerability Report Looks Like in the Distr Customer Portal
Once the CI job runs, the scan report appears in the customer portal alongside the version. No extra steps. No emails or manual attachments.
Customers can review the findings before they approve a deployment. If your team has a known CVE documented and triaged, that context is right there too. If the report is clean, that’s visible as well.
Instead of a customer emailing you to ask for documentation, they log into Distr and find it themselves. The back-and-forth on CVEs that used to take days happens upfront — or doesn’t happen at all.
The same workflow runs locally, you can use the Distr Vulnerability Scanning Script and running it gives you the same report locally that CI produces. Catches surprises before they hit the pipeline.
Getting Started with Vulnerability Scanning in Distr
The full setup is in the vulnerability scanning guide. The hello-distr repository has a complete working GitHub Actions workflow you can copy and adapt.
The example covers four services — backend, frontend, proxy, and jobs. You’ll swap in your own services and lockfile paths. Takes maybe 20 minutes to get running.
If you’re already using Distr, this is a straightforward extension of the version creation workflow you’ve already got. If you’re not yet using Distr and you’re distributing self-managed software to enterprise customers… this is one piece of a bigger problem we’re built to solve. Try it out.
Join the Conversation
Questions on the scanning setup, or have you already got this running? Come find us: