Know which vulnerabilities your running images have

Wodby scans a build image while an enabled app service runs it. That includes derivatives, such as workers or cron services that run another service's image, and an image that several services run is scanned once. Images come from the build's own registry repository: Wodby Registry, or the Docker Hub or Distribution Registry integration selected for the environment.

• Find vulnerabilities in operating system packages.
• Find vulnerabilities in application dependencies the scanner recognizes, such as Node.js, Python, PHP, Go, or Java packages.
• Match against advisories from Linux distributions, language ecosystems, and the National Vulnerability Database.

Wodby rescans each deployed image about once a day, so a newly published vulnerability appears without a rebuild or a new deployment. When a build is no longer deployed, rescans stop and the build keeps its last result.

• Show a newly deployed image as pending until its first result arrives.
• Retry failed scans automatically, waiting longer after each failure.
• Keep the last good results and show the reason when a rescan fails.

The list of builds shows how many vulnerabilities each deployed build has by severity. On a build's page, the Vulnerabilities tab has a report for each scanned app service, starting with the most severe and fixable findings.

• Filter findings by severity or by whether a fix is available.
• See the affected package, its version and type, and where it is in the image.
• Open the advisory for each vulnerability and see the fixed versions.

When you update a base image or dependency, build and deploy as usual through CI/CD. Wodby scans the new image once it is deployed.

The weekly organization report lists deployed builds with critical or high vulnerabilities, with their app environment, services, and scan date, and links to each build. The REST API returns the same summaries for builds and their images.

• Only images built for your app services are scanned. Catalog images you run without a build, such as a database service, are not.
• Scanning does not review your own code or find vulnerabilities that have not been published.
• Scanning does not block deployments or change your images. You decide what to fix and when.
• Images must be in a registry reachable at a public HTTPS address and within the size and platform limits in the documentation.

Vulnerability scanning is included in the Team and Enterprise plans. See pricing.