Vulnerability Patch Policy
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 Trivy 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 GitHub issue, Slack message, or opening a support issue from the Replicated Vendor Portal. Our team will evaluate the vulnerability and determine the best course of action.
Base Images
KOTS images are built on top of Chainguard's open source Wolfi base image. Wolfi is a Linux undistro that is focused on supply chain security.
KOTS has automation that uses the Chainguard melange and apko projects to build packages and assemble images on Wolfi. Building and assembling images in this way helps to ensure that any CVEs can be resolved quickly and efficiently.
Upstream CVE Disclosure
Replicated KOTS and kURL deliver many upstream Kubernetes and ecosystem components. We do not 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 |
Notable Upstream CVEs
This section lists CVEs that have yet to be resolved by the upstream maintainers and therefore are not patched in Replicated. This is not an exhaustive list of unpatched upstream CVEs; instead, these are noteworthy CVEs that we have evaluated and on which we offer our opinion to help with your own security reviews. When available, we will apply upstream patches in accordance with our policy desribed in Upstream CVE Disclosure above. We will update this list after applying any upstream patches.
| CVE ID | Explanation |
|---|---|
| None | N/A |
Vulnerability Management Exception Policy
There might be instances where policy exceptions are required to continue using third party software with known vulnerabilities in our on premises products. Some reasons for an exception include:
- Feature breakage or bugs in patched versions
- Performance issues in patched versions
- Patched version contains higher severity vulnerabilities
Regardless of the reason, an exception is vetted from a business impact and security standpoint. The business review assesses the overall impact to the product created by the patched, but otherwise problematic, piece of software. The security portion determines if the CVE is applicable to this specific context and if that CVE's impact to the product’s overall security posture is acceptable.
In the event of a vulnerability management exception, a notice is posted containing:
- The impacted product(s)
- The rationale for the exception
- The relevant CVE(s)
- A risk assessment in the product context for each CVE
As subsequent versions of the vulnerable software are released, Replicated continues to research to find a solution that satisfies the business and security requirements of the original exception.
Known Disclosed Vulnerabilities in our On Premises Products
| CVE | CVE Summary | Rationale | Additional Reading |
|---|---|---|---|
| None | N/A | N/A | N/A |
Last modified February 26, 2024.