Document a security backport when an upgrade is blocked
Evaluate a backport against a normal corrective upgrade. Record the blocker, patch identity, maintenance owner, regression evidence, and exit plan.
A backport applies a correction to an older maintained code line. It creates a maintenance responsibility, not a shortcut around understanding the vulnerability. First determine why the supported corrective release cannot be adopted and whether that blocker can be removed within the required remediation window.
OWASP discusses managing vulnerable dependencies. The decision record below is a proposed engineering control for the exceptional case where a normal upgrade is blocked. It does not imply that Sourced maintains or certifies a patched fork.
Compare the available paths
Locate the maintainer's corrective change and any prerequisite changes. Check whether your distribution or vendor already provides a supported backport. Do not copy an isolated code fragment without understanding the behavior it relies on.
| Option | Evidence needed | Ongoing responsibility |
|---|---|---|
| Normal corrective upgrade | Compatibility and feature tests | Follow the supported release line |
| Vendor backport | Vendor advisory and exact package build | Track vendor support and updates |
| Internally maintained patch | Reviewed diff and reproducible artifact | Own later fixes, builds, and retirement |
| Temporary feature restriction | Verified reduction in exposure | Expiry and a permanent remediation plan |
Write the actual blocker, such as a specific incompatible API, rather than the general statement that upgrading is difficult.
Prove the patch belongs to the shipped bytes
Give the patched build an unambiguous identity. Record upstream revision, patch digest, build inputs, and resulting artifact digest. Preserve provenance for the change. A version string that still resembles the affected upstream release requires explanatory evidence for inventory and alert consumers.
Add a targeted regression for the corrected behavior and a positive test for ordinary use. Check prerequisite code paths and platform-specific behavior. Do not run an uncontrolled exploit against a customer deployment to validate the patch.
Give the exception an end
Assign an owner for monitoring subsequent advisories and upstream releases. Define when the application returns to a supported version and what would force an earlier migration. An internal patch that nobody owns can become more expensive than the original compatibility work.
Keep advisory suppressions specific to the exact patched artifact and evidence. Do not dismiss every occurrence of the upstream version across the organization. Review rollback carefully: the previous artifact may restore the vulnerability. A defensible backport decision identifies the corrected bytes, the verified behavior, the remaining limitations, and the person responsible for ending the exception.
Know which dependency risks need a fix
Check affected versions, the build and deployment evidence. Use the update checklist, or discuss the dependency risks in your application review.