> ## Documentation Index
> Fetch the complete documentation index at: https://docs.root.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Backported Patch Conformance

> How Root evaluates, validates, and delivers backported security patches.

Root treats backporting as a disciplined security engineering activity. Every backported patch is evaluated as a complete technical deliverable — not an isolated code change — against Root's internal Backport Conformance Framework before it ships.

This page describes the stages Root applies and the criteria a backported patch must meet.

<Note>
  For an overview of what Root Patches are and how they differ from forced upgrades, see [Root Patches](/concepts/root-patches).
</Note>

## Conformance Stages

Each backported patch passes through five stages. A patch that does not satisfy all five is not shipped.

### Structured Analysis and Applicability

Every backport begins with explicit analysis of the vulnerability, the affected code, and the target environment. This includes:

* **Applicability determination** — whether the vulnerability exists in the target tree
* **Fix tree identification** — locating the authoritative fix (upstream commit, maintainer patch, or advisory)
* **Assumption documentation** — recording any differences in risk assessment between the fix tree and target tree

### Derivation from Prior Art

Backports are derived from existing fixes wherever possible — they are not greenfield work. Root documents:

* **How the fix was adapted** from the fix tree to the target tree
* **Semantic gaps** — structural or behavioral differences that required reengineering
* **Divergence from upstream intent** — any deliberate deviation is explained, not implicit

### Code Quality and Semantic Conformance

Beyond functional correctness, Root evaluates whether the patch belongs in the target codebase:

* **Semantic consistency** — the patch follows the conventions and idioms of the target tree
* **Readability and maintainability** — the change is understandable in context
* **Minimal footprint** — no unnecessary changes beyond what the fix requires

### Secondary Security Analysis

Root does not assume reference fixes are inherently safe. Each backport undergoes a secondary security review:

* **Attack surface assessment** — does the imported code introduce new vulnerabilities?
* **Scope-proportional scrutiny** — larger or more complex changes receive deeper analysis
* **Regression risk** — could the fix destabilize security-relevant behavior elsewhere?

### Verification and Evidence

Backports are validated with concrete, reproducible evidence:

* **Maintainer test suites** — run on the target tree with the patch applied
* **Targeted tests** — added or adapted to cover the specific vulnerability
* **Exploit-focused verification** — proof-of-concept or synthetic exploit validation confirms the vulnerable behavior no longer exists

## Deliverables

Backports ship as complete, reviewer-oriented artifacts. An independent reviewer can inspect:

* **Structured analysis** — the vulnerability assessment and applicability determination
* **Source-level diffs** — the patch itself, with derivation context
* **Verification results** — test outcomes and exploit validation
* **SBOM, VEX, and provenance** — updated automatically with every Root Patch

See [SBOMs](/concepts/sbom), [VEX Statements](/concepts/vex), and [Provenance](/concepts/provenance).

## How Conformance Is Determined

Conformance is a holistic determination based on the complete set of artifacts and evidence. It reflects:

* The quality of the underlying analysis
* The soundness of the derivation from prior art
* The safety of the implementation in the target codebase
* The strength of the verification evidence

There is no single pass/fail metric. Conformance is the outcome of rigorous, artifact-based review across all five stages.

## Glossary

Terms specific to Root's Backport Conformance Framework. For general terms, see the [Glossary](/reference/glossary).

| Term                            | Definition                                                                                                          |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| **Fix Tree**                    | The source tree where the authoritative fix exists and from which the backport is derived.                          |
| **Target Tree**                 | The source tree and version to which the backported patch is applied and validated.                                 |
| **Semantic Gap**                | Structural or behavioral differences between the fix tree and target tree that must be addressed during adaptation. |
| **Derivation**                  | The documented adaptation of a fix from the fix tree to the target tree.                                            |
| **Secondary Security Analysis** | Focused review to identify new risks introduced by the backport or imported code.                                   |
| **Prior Art**                   | Existing fixes, commits, or design patterns that inform how a backport is derived.                                  |