Snapshot 185758
Normalized text
Scripts and page chrome removed; this is what change detection compares.
Skip to main content 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 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, report it to us by opening a support issue from the Replicated Vendor Portal. For more information, see Submit a Support Request. Our team will evaluate the vulnerability and determine the best course of action. Base images Replicated builds the images for KOTS, Embedded Cluster, the Replicated SDK, and many kURL add-ons with Replicated's SecureBuild technology. SecureBuild builds packages from source with melange and assembles minimal images with apko on a hardened base. When a fix is available for a package or one of its dependencies, SecureBuild rebuilds the affected images, which helps us resolve CVEs quickly. Upstream CVE disclosure Replicated KOTS, kURL, and Embedded Cluster deliver many upstream Kubernetes and ecosystem components. We rely on the upstream software vendor to distribute patches. Replicated doesn't control when upstream projects release fixes, which release lines receive them, or which Kubernetes versions a fixed release supports. Some projects only fix a vulnerability in a newer release that requires a newer Kubernetes minor version. For example, a CoreDNS fix might ship only in a CoreDNS release that's compatible with the next Kubernetes minor version. In that case, the CVE can't be resolved on the older Kubernetes version, and the fix reaches your customers when they upgrade to a Kubernetes version that supports it. For the Kubernetes versions that each installer supports, see Supported Replicated Installer versions. 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 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. Last modified October 9, 2026. On this page How we scan Base images Upstream CVE disclosure Vulnerability management exception policy