Service Level Agreement
Last updated: December 23, 2025
1. OVERVIEW
This Service Level Agreement ("SLA") describes Root's service level commitments for customers with paid subscriptions to the Root Platform. This SLA is incorporated by reference into the Terms of Service and any applicable Order Form.
Capitalized terms not defined herein have the meanings set forth in the Terms of Service or your Order Form. In the event of a conflict between this SLA and an Order Form executed by Root's Chief Executive Officer, the Order Form shall control with respect to the specific commitments described therein.
Root will use commercially reasonable efforts to meet the specified SLA Target Timelines set forth below.
2. PLATFORM SERVICES
2.1 Root Image Catalog (RIC)
Root Image Catalog provides access to hardened, continuously remediated container images. Customers may subscribe to images within the catalog for use in their environments.
Included in RIC:
• Access to all standard catalog images
• Subscription to any number of images (subject to acceptable use)
• SBOMs, VEX statements, and build provenance for all images
• CVE remediation per applicable SLA tier
Not Included in RIC (Separate Entitlement Required):
• FIPS-validated images
• STIG-hardened images
• Other specialized compliance images as specified
Image Request Entitlement: Where specified in an Order Form, Customer may request addition of new images to the catalog. Root will use commercially reasonable efforts to add requested images within thirty (30) days of request if and as specified in the Order Form, subject to technical feasibility. Image request entitlements do not guarantee addition of any specific image.
Community Images: Root may offer certain images designated as "Community Images" at no charge or reduced subscription cost. Community Images are provided "AS IS" without warranty or SLA commitment.
2.2 Root Library Catalog (RLC)
Root Library Catalog provides backported security fixes for application dependencies across supported language ecosystems (e.g., Python/PyPI, JavaScript/NPM, Java/Maven).
Scope of RLC SLA:
• Applies only to new CVEs discovered after Customer's subscription effective date
• Applies only to libraries explicitly designated as "Subscribed Libraries" in the Order Form or Root Platform
• Does not apply to pre-existing CVE debt at time of subscription
CVE Burn Down: Remediation of pre-existing vulnerabilities in Customer's pinned library versions may be available as a separate entitlement ("CVE Burn Down Credits") if and as specified in the Order Form.
2.3 Deliverables
All Root-delivered fixes include:
• Full source code build in accordance with SLSA standards
• Software Bill of Materials (SBOM)
• VEX (Vulnerability Exploitability eXchange) statements
• Diff files and provenance documentation
• Patch efficacy testing against proof-of-concept exploits where available
Root maintains underlying open source licensing for all images and publishes patches in compliance with applicable license requirements as provided in the Terms of Service.
3. PLATFORM AVAILABILITY
3.1 Uptime Target
Root targets 99.9% monthly availability for the Root Platform, including registry services and API access ("Platform Availability").
3.2 Calculation
Availability % = ((Total Minutes - Downtime Minutes) / Total Minutes) × 100
Where:
• Total Minutes = Total minutes in the calendar month
• Downtime Minutes = Minutes where Platform was unavailable, excluding Exclusions
3.3 Exclusions
Downtime does not include unavailability due to:
(a) Scheduled Maintenance: Planned maintenance with at least twenty-four (24) hours advance notice via email or Platform notification
(b) Third-Party Infrastructure: Outages of underlying infrastructure providers (e.g., AWS, Google Cloud, Cloudflare) outside Root's reasonable control
(c) Force Majeure: Events beyond Root's reasonable control, including natural disasters, acts of war, terrorism, pandemic, or government action
(d) Customer-Caused Issues: Unavailability resulting from Customer's acts, omissions, equipment, software, or network connectivity
(e) Suspension: Service suspension due to Customer's breach of the Agreement or non-payment
3.4 Scanning Frequency
Root targets vulnerability scanning of subscribed images and libraries at least once every twenty-four (24) hours when utilizing Root-controlled registries. Scanning frequency for Customer-controlled registries depends on Customer's CI/CD configuration and API integration.
3.5 Pull Rate Limits
To ensure fair use and prevent service degradation, Root may implement reasonable pull-rate limits on registry access. Customers experiencing rate limiting due to suspected misconfiguration will be notified and assisted in remediation.
4. VULNERABILITY REMEDIATION SLA
SLA Tiers
This SLA defines Standard remediation timelines included with all paid subscriptions. Enhanced SLA tiers with accelerated timelines may be available at an additional charge for customers with more aggressive remediation requirements. Enhanced SLA terms, eligibility, and pricing are specified in the Order Form.
4.1 General Definitions
"CVE" means a vulnerability with an assigned Common Vulnerabilities and Exposures identifier.
"CISA KEV" means a vulnerability listed in CISA's Known Exploited Vulnerabilities catalog.
"Severity" is determined by CVSS score from the NIST National Vulnerability Database:
• Critical: CVSS 9.0–10.0
• High: CVSS 7.0–8.9
• Medium: CVSS 4.0–6.9
• Low: CVSS 0.1–3.9
"Fix Candidate" means a proposed remediation existing within the trusted ecosystem—including upstream maintainer releases, sibling distributions, forks, or validated unmerged pull requests.
"Remediation Complete" means Root has delivered a fix that is fully tested, validated against proof-of-concept exploits where available, and includes diff file and provenance documentation.
"Subscription Date" means the effective date of Customer's subscription for the applicable service (RIC or RLC) as specified in the Order Form.
4.2 SLA Timeline Commencement (Both RIC and RLC)
SLA timelines begin upon the later of:
(f) CVE publication in a recognized vulnerability database (NVD, vendor advisory, etc.); AND
(g) Availability of a Fix Candidate within the trusted ecosystem
Subsequent severity reclassification (e.g., addition to CISA KEV) triggers the more stringent timeline from that point forward.
4.3 Remediation Delivery Standards (Both RIC and RLC)
All Root-delivered fixes include:
• Source builds in accordance with SLSA standards
• Software Bill of Materials (SBOM)
• VEX statements
• Diff files and provenance documentation
• Patch efficacy testing and PoC validation where available
Root maintains underlying open source licensing and publishes patches in compliance with applicable license requirements as provided in the Terms of Service.
4A. ROOT IMAGE CATALOG (RIC) — SLA SPECIFICS
4A.1 Scope of RIC SLA Coverage
The RIC Remediation SLA applies to:
(h) Subscribed Images: Container images explicitly subscribed to by Customer within the Root Platform
(i) All CVEs: Both new and pre-existing vulnerabilities in Subscribed Images are covered—there is no distinction between CVE Debt and new CVEs for RIC
(j) Supported Images: Standard catalog images as available in the Root Platform. FIPS, STIG, and other specialized images require separate entitlement per Order Form.
4A.2 What RIC Covers vs. Excludes
Covered
Not Covered
All CVEs in Subscribed Images (new and existing)
Community Images (no SLA)
Critical, High, Medium severity per SLA tier
Low severity (commercially reasonable)
OS-level and package vulnerabilities
Customer-added layers or modifications
Standard catalog images
FIPS/STIG without entitlement
4A.3 RIC Standard SLA Target Timelines
Standard SLA timelines. Enhanced SLA with faster remediation available via Order Form.
Severity
Standard Timeline
CISA KEV
Critical
30 calendar days
72 hours
High
30 calendar days
72 hours
Medium
60 calendar days
—
Low
Commercially reasonable
—
4A.4 RIC Enhanced SLA Timelines
Enhanced SLA terms, eligibility, and pricing are specified in the Order Form.
Severity
Enhanced Timeline
CISA KEV
Critical
7 calendar days
48 hours
High
14 calendar days
48 hours
Medium
30 calendar days
—
Low
Commercially reasonable
—
5. CVE SURGE PROTECTION
5.1 Surge Condition
A "CVE Surge Condition" exists when the rate of new Critical or High severity CVEs affecting a specific subscribed image or library version exceeds 2.5 times (2.5x) the historical monthly average for that project or dependency, measured over the trailing twelve (12) months.
5.2 Effect of Surge Condition
Upon determination of a CVE Surge Condition:
(k) SLA timelines become advisory targets rather than commitments for the affected image or library
(l) Root will notify Customer of the Surge Condition and collaborate on prioritization of critical fixes
(m) Root will provide guidance on upgrade paths to more stable versions where available
(n) Normal SLA commitments resume when the Surge Condition no longer exists
5.3 Extended Life Support
For customers requiring continued support of end-of-life or high-CVE-volume versions, Extended Life Support may be available at additional cost as specified in the Order Form.
6. ESCALATION TO ROOTLABS
6.1 Triggering Escalation
In exceptional circumstances where standard AVR processes cannot remediate a CVE within SLA timelines—typically due to extraordinary technical complexity or ecosystem-wide gaps—Customer will be notified and may request escalation to Root Labs.
6.2 Root Labs Services
Upon Customer request, Root Labs may provide:
Risk Triage: Comprehensive analysis to determine actual applicability of the CVE to Customer's context, which may include:
• Reachability analysis of vulnerable code paths
• EPSS (Exploit Prediction Scoring System) evaluation
• Environmental context review (runtime, network exposure, access controls)
• Threat intelligence correlation
• Attack chain validation
• Proof-of-concept assessment
VEX Enforcement: When triage determines risk is not applicable or low:
• Standard VEX: SBOM with scanner-consumable VEX statements
• VEX-enforced image (at Customer discretion): Modified image enabling SCA tools to reflect corrected risk assessment
Custom Remediation: When CVE risk remains Critical or High and no viable ecosystem fix exists, Root Labs may use commercially reasonable efforts to engineer a novel fix, including:
• Developing targeted patches compatible with Customer's versions
• Validating fixes resolve the vulnerability without breaking functionality
• Providing supporting documentation for compliance records
6.3 Root Labs Timeline
While Root Labs prioritizes delivery within original SLA timelines, complex research may extend up to thirty (30) days from escalation request.
6.4 Service Commitments
• Parallel Processing: Individual CVE escalations do not impact delivery timelines for other remediable CVEs
• Communication: Regular status updates for all escalated issues
• Transparency: If remediation is determined technically infeasible, Root Labs will provide written technical justification and support for alternative approaches
6.5 Technical Infeasibility
If Root determines a CVE cannot be remediated, Root Labs will work with Customer to provide:
(o) Written technical justification
(p) Support for alternative workaround solutions, such as: "Lowest lift" library or package-specific upgrades; Collaboration with Customer engineering on alternative approaches; Alternative CVE-compliant image maintaining stability
(q) Upon Customer request, additional technical review involving Root's CTO and/or VP of Engineering
7. EXCLUSIONS
7.1 SLA Exclusions
Remediation SLA commitments do not apply when:
(r) No Fix Candidate exists within the ecosystem
(s) Vulnerability is in Customer-provided code, configurations, or customizations
(t) CVE is disputed, rejected, or withdrawn by NVD or the relevant authority
(u) Customer has not provided required access, information, or timely response to Root inquiries
(v) Image or library is designated as Community (no SLA)
(w) CVE Surge Condition applies (Section 5)
(x) Vulnerability exists in a FIPS, STIG, or specialized image for which Customer does not have entitlement
(y) Pre-existing CVE debt for RLC (covered by CVE Burn Down entitlement if applicable)
7.2 Force Majeure
Neither party shall be liable for failure to perform obligations due to events beyond reasonable control, including natural disasters, acts of war or terrorism, pandemic, government action, or failure of third-party infrastructure providers.
8. SLA REMEDY AND ESCALATION
8.1 Escalation Path
Customer's remedy for SLA concerns is escalation through Root's support organization:
• Level 1: Account Manager
• Level 2: Head of Customer Success
• Level 3: Head of Field Engineering
• Level 4: CTO
8.2 No Service Credits
SLA timelines represent Root's performance targets. Failure to meet SLA timelines does not entitle Customer to automatic service credits or financial remedies. Customer's remedy is escalation per Section 8.1 and, where applicable, termination rights per Section 9.
9. TERMINATION FOR SLA FAILURE
9.1 Conditions for Termination
Customer may terminate the Agreement for material SLA failure only if all of the following conditions are met:
(z) Root fails to remediate a Critical severity or CISA KEV vulnerability within two times (2x) the applicable SLA timeline;
(aa) Customer has escalated to Root Labs per Section 6 and Root Labs has exhausted the thirty (30) day extended research period;
(bb) Root Labs has not provided either: (i) a viable remediation, or (ii) a reasonable alternative (VEX enforcement, workaround, alternative image);
(cc) Customer provides written notice specifying the SLA failure; and
(dd) Root fails to cure within forty-five (45) days of such notice.
9.2 Refund Upon Termination
Upon termination pursuant to Section 9.1 or Section 10, Customer is entitled to a pro-rata refund of prepaid fees for the unused portion of the subscription term, less fees attributable to the sixty (60) days following the effective termination date to facilitate transition services.
9.3 Limitations
Termination under this Section does not apply to:
• CVEs where a CVE Surge Condition existed
• CVEs excluded under Section 7
• Situations where Customer failed to cooperate with Root's remediation efforts
10. MODIFICATIONS
Root may modify this SLA by posting an updated version to www.root.io/sla. Material changes will be communicated with at least thirty (30) days notice. If changes are not acceptable to Customer, Customer may elect to terminate the Agreement and receive a pro-rata refund in accordance with Section 9.2.
