While it’s our goal to distribute vulnerability-free versions of all components, this isn’t always possible. Kubernetes and KOTS are made from many components, each authored by different vendors.
The best way to stay ahead of vulnerabilities is to run the latest version and have a strategy to quickly update when a patch is available.
How We Scan
Our build pipeline uses Anchore Grype to scan for and detect known, published vulnerabilities in our images. It’s possible that other security scanners will detect a different set of results. We commit to patching vulnerabilities according to the timeline below based on the results of our internal scans.
If you or your customer detects a different vulnerability using a different scanner, we encourage you to report it to us in a Zendesk ticket, Slack message, or emailing [email protected] Our team will evaluate the vulnerability and determine the best course of action.
When possible, KOTS uses alpine, scratch, or distroless images to reduce the number of components that might be affected by CVEs. When a larger base image is required, we will keep it updated to the latest version available based on the following timeline:
|Base Version Change||Time to include in release|
|Patch version||Within 2 weeks|
|Minor version||Within 30 days|
|Major version||Before the previous version is EOL|
Upstream CVE Disclosure
Replicated KOTS and kURL deliver many upstream Kubernetes and ecosystem components. We don’t build these packages and rely on the upstream software vendor to distribute patches. Our intent is to make any patches available as soon as possible, but guarantee the following timeline to make upstream patches available after we learn about the vulnerability and a patch is available to us:
|CVE Level||Time to release|
|Critical||Within 2 weeks|
|High||Within 60 days|
|Medium||Within 90 days|
|Low||Best effort unless risk accepted|