Implementing Level 3 of the Container Vulnerability Management Framework
Explore expert takes on container security, DevSecOps best practices, and the future of automated vulnerability management.
Last Updated :
Mar 24, 2025
Purpose
This Service Level Agreement (“SLA”) sets forth Root.io Inc.‘s (“Root’s”) commitments for addressing vulnerabilities (“CVEs”) identified in container images provided through Root’s Automatic Vulnerability Remediation (“AVR”) service. Root will use commercially reasonable efforts to address CVEs as follows.
Definitions
Viable Patch: A publicly available software fix for a CVE that is:
Officially released by a credible upstream maintainer or recognized third-party.
Stable for its intended release.
Deemed portable across supported architectures.
Validated by passing the upstream project’s standard testing frameworks and by Root research & development.
Severity Levels: Root adheres to the National Vulnerability Database (NVD) guidance for determining vulnerability severity levels for all SLA tiers:
Critical: CVSS 9.0–10.0
High: CVSS 7.0–8.9
Medium: CVSS 4.0–6.9
Low: CVSS <4.0
Scope
This SLA covers vulnerabilities within Root-managed container images provided under the AVR service. Vulnerabilities resulting from customer modifications, unsupported environments, or factors outside Root’s control are not covered.
SLA Coverage Tiers
Basic Support (Community Images): No timelines committed for remediation.
Standard SLA Targeted Remediation Timeframes:
Critical: 7 calendar days after Viable Patch identification.
High: 14 calendar days after Viable Patch identification.
Enhanced SLA Targeted Remediation Timeframes:
Critical: 7 calendar days after Viable Patch identification.
High: 7 calendar days after Viable Patch identification.
Medium: 30 calendar days after Viable Patch identification.
SLA Activation
The SLA timeline begins when:
A Viable Patch becomes publicly available from a credible upstream source; and
The Customer scans the affected image using the Root AVR platform, identifying the vulnerability and initiating the remediation request.
Root’s remediation obligations conclude when a rescan of the updated image using Root’s AVR platform confirms that the vulnerability is resolved.
Customer Responsibilities
As a condition to Root’s obligations under this SLA, Customers must:
Continuously scan container images through the Root platform.
Identify and request remediation for vulnerabilities using the Root platform.
Rescan updated images to confirm successful remediation.
Promptly report any issues or concerns to Root through official support channels.
Adhere strictly to supported configurations and environments.
Exclusions and Limitations
This SLA does not apply if:
No Viable Patch exists.
The Customer fails to continuously scan or request remediation via the Root platform.
Vulnerabilities stem from customer-added software, modifications, or unsupported configurations.
Delays arise due to external upstream dependencies or force majeure events.
Remedies
Root will employ commercially reasonable efforts to meet all targeted SLA timelines for vulnerability remediation. If Root does not meet the target SLA timelines despite these efforts, the Customer may request service credits or initiate an escalation process. The initial escalation will be directed to Root’s Head of Field Engineering, with subsequent escalations to the CTO if necessary. Root will work diligently with the Customer to address concerns and implement appropriate corrective actions throughout the escalation process.
General
Root may periodically update this SLA and will inform customers of material changes. The Master Agreement remains controlling for terms not explicitly covered by this SLA.
3/24/25 Revision
Trusted by businesses who can't afford slowing down
Ready to transform your container security?
From vulnerability detection to patched images in ~180 seconds.