什麼是 Backporting？運作方式與流程

近年來，已通報的 Common Vulnerabilities and Exposures (CVEs) 數量持續穩定增加。僅在 2024 年上半年，通報的 CVE 數量就達到 22,254 件，比 2023 年記錄的 17,114 件 CVE 大幅增加 30%。由於這些弱點一旦遭到利用，將帶來嚴重的財務與聲譽後果，企業面臨的唯一選擇就是及時修補弱點。但說來容易，做來難。有時候，對於舊版系統而言，將存在弱點的版本升級到包含安全修補程式的新版本根本不可行。這正是 backporting 發揮作用之處。

想像一下，你有一輛開了很多年的古董車。突然間，它的引擎和輪子開始出問題。令人難過的是，它是非常老的車型，所以你找不到零件。但你也不想把這輛車換成較新的車型。因此，你改請技師從新車型蒐集相容的零件，並安裝到你的古董車上。問題解決了！

Backporting 與此類似；它表示將最新軟體版本中的修補程式回補到舊有系統，以修正其中的問題。在本文中，我們將探討 backporting，聚焦其重要性、使用案例、相關漏洞與最佳實務。

什麼是 Backporting？

Backporting 是一種做法，將較新軟體版本中引入的安全修補或新功能移植到較舊的版本。

為什麼 backporting 很重要？作為漏洞管理的核心環節之一，當升級含有漏洞的軟體版本存在困難時，backporting 就成為必要手段。

請看這個真實案例： Red Hat 發布了 Red Hat Linux 8.0。 使用的是 Apache HTTP Server 2.0.40 版。不久之後，舊版 Apache 中發現了安全漏洞，於是發布了新版本——2.0.43。

雖然新版本修復了這些錯誤，但其中也包含程式碼變更，會使上游軟體與許多依賴它的下游部署不相容。因此，Red Hat 並未直接全面套用新版本，而是透過擷取相關程式碼片段並加以修改，使其適配舊版本，來回補該修補程式。

本質上，backporting 意味著你自行存取並改造某個軟體版本的原始碼，或從你的軟體發行商取得已 backport 的上游版本——例如上述的 Red Hat 範例。以下是一些常見的 backporting 情境：

• 舊有系統： 依賴舊版軟體的企業面臨獨特挑戰；現有系統通常與最新更新不相容。Backporting 可解決此問題，在不需要全面替換或重構的情況下，修復舊有系統中的效能與安全問題。
• 法規遵循： 對於處理客戶 Protected Health Information (PHI)、Payment Card Information (PCI) 與 Personal Identifiable Information (PII) 的組織而言，依循 HIPAA、GDPR 與 PCI DSS 等法規標準來保護敏感資料是優先事項。Backporting 讓這些企業無需面對軟體版本管理的麻煩，也能滿足合規要求。
• 資源限制： 當升級需要耗費大量人力、財務與系統資源，而許多企業根本無力負擔時，backporting 提供了一種更具資源效率的替代方案。

Backporting、Patching 與 Upgrading 之間的差異

Backporting、patching 與 upgrading 是相近的概念，功能類似，但方法不同。以下將回顧它們之間的差異。

Backporting 如何運作？

Backporting 的流程包含一系列步驟：

步驟 1: 識別你想要回補安全修補的漏洞。這可以透過內部團隊執行的安全檢查，或網際網路上發布的安全公告來完成。

步驟 2: 找出可修復該問題的新軟體版本。

步驟 3: 從新軟體版本中的其他變更中分離出修復內容，方法是擷取所需的程式碼片段。

步驟 4: 將分離出的修復內容調整為適用於舊系統。

步驟 5: 在受控環境中進行測試，以確保它確實修復了漏洞，且不會引入效能或安全問題，或其他不良影響——例如改變既有功能。

步驟 6: 將修復回補到舊系統、部署到正式環境，並持續監控。

與回溯移植相關的弱點

雖然回溯移植為無法升級特定軟體的組織提供了關鍵的生命線，但它並非毫無風險。回溯移植的一項主要風險是，較舊的系統可能原生不支援較新的安全性框架。因此，回溯移植的修補程式在您嘗試修復其他弱點時，最終可能會引入回溯移植弱點。

什麼是回溯移植弱點？

回溯移植弱點是指將為現代系統設計的安全性修補程式調整至較舊版本時所產生的風險，可能導致未預期的副作用。

回溯移植弱點的類型

當新舊軟體版本之間存在重大的架構或相依性差異時，回溯移植可能會引入以下類型的弱點：

 1. 安全性弱點

較新軟體版本中的安全性修復通常依賴於較舊版本中不存在的安全性範式。如果您回溯移植這些修復，就需要留意避免引入新的回溯移植弱點，或未正確處理舊有弱點。

例如，Microsoft 最近發布了一項更新，用於修補 .NET 遠端程式碼執行 (RCE) 弱點 (CVE-2024-38229)。雖然此更新在 .NET 8.0 和 9.0 系統中有效，但若回溯移植至 .NET 6.0，可能無法達到預期效果。這是因為作為該弱點重點的 HTTP/3 串流，在 6.0 版本中仍僅屬實驗性功能。

2. 相容性問題

在進行回溯移植時，需要考量的元件非常多，包括相依性、API、框架與程式庫、作業系統、分支應用程式等等。考量到這份冗長的清單，要確保回溯移植的修補程式能與所有元件完整整合，便成為一項挑戰。當舊有系統的架構與較新的系統根本不相容時，可能需要對修補程式進行大幅修改。

例如，較新的軟體版本會使用現代軟體開發套件 (SDK)，例如 Kubernetes SDK，而這些在舊有軟體中可能根本不存在。在這種情況下回溯移植修補程式，將需要開發人員重寫程式碼片段（包含修補程式），或安裝複雜的因應措施，而這些措施也必須具備相容性。

3. 效能下降

較新的軟體版本通常是為了速度與安全性而建置，這可能使其更耗用資源。將以這種方式設計的修補程式回溯移植到較舊、較慢的系統，可能會使系統的處理能力超載，導致回應時間變慢、發生錯誤，甚至更糟的是造成系統當機。

與回溯移植弱點相關的風險

• 安全性風險：回溯移植不當的修補程式可能會使弱點未獲解決，或引入新的弱點。
• 營運風險：為回溯移植分配資源可能導致潛在停機或服務中斷。
• 合規風險：回溯移植不足可能導致不符合安全性標準。

如何測試與驗證回溯移植的變更

在發佈前測試並驗證回溯移植的修補程式，對於確保安全且有效的回溯移植流程至關重要。這包括：

• 使用弱點管理解決方案來偵測回溯移植流程尚未完全解決的弱點。
• 使用弱點掃描器確認回溯移植流程未引入任何新的弱點。

• 使用回歸測試工具驗證修補程式是否正確整合，且不會對現有功能造成負面影響。

• 部署滲透測試人員，進一步測試回溯移植的修補程式是否存在潛在安全性弱點。

回溯移植的挑戰

雖然回溯移植是解決無法輕易替換之舊有系統弱點的有效方式，但企業可能面臨以下挑戰：

#1. 複雜性

當存在相容性問題時，回溯移植需要大量重寫程式碼，這通常是相當耗時的流程，而且企業還必須聘用高度專業化的工程師與工具。

#2. 未解決的風險

回溯移植即使具備相容性，也可能無法完全解決問題。如果弱點存在於架構設計本身，就可能發生這種情況。在這種情況下，回溯移植可能會讓企業產生安全無虞的錯覺，直到弱點遭到利用為止。

#3. CVE 編號混淆

許多安全性解決方案僅透過將弱點與弱點資料庫中的 CVE 識別碼進行關聯來偵測弱點。因此，即使回溯移植已完全解決弱點，這類工具仍持續將軟體版本標示為存在弱點的情況相當常見，進而導致誤判。

#4. 文件不足

組織仰賴服務供應商為作業系統、框架、程式庫等提供軟體修補程式。在無法升級的情況下，這些供應商會回溯移植修補程式。如果未針對每項已發布的安全性修復清楚記錄此事，使用者可能會無意間認為已執行的是升級而非回溯移植。

同樣的情況也適用於文件記錄稀少的內部回溯移植流程。文件不足會讓使用者對於為何在完成「更新」後仍然是較舊版本感到困惑。如果使用者未適當套用回溯移植的變更，也可能引入安全性弱點。

降低回溯移植弱點的最佳實務

以下是為實現無弱點回溯移植流程而應採行的 7 項回溯移植最佳實務。

1. 評估回溯移植需求： 在選擇回溯移植之前，請務必確認這是解決弱點最有效的方法。同時，請全面評估若選擇回溯移植或升級，將會面臨多少效能下降與營運複雜性，並在兩者之間取得平衡。
2. 遵循嚴謹的測試程序： 在發佈前，請徹底測試回溯移植的修復是否存在安全性弱點與效能問題。於受控環境中進行的健全測試，可確保既有弱點已獲解決，且回溯移植流程不會引入新的弱點。
3. 進行徹底的風險評估： 務必確保您將面臨的任何潛在回溯移植風險或挑戰，都遠遠小於其為企業帶來的安全性、營運與合規效益。
4. 維護完整的文件紀錄： 這對於長期追蹤回溯移植的變更，以及建立詳細的合規稽核軌跡至關重要。這對於未來的除錯與根本原因分析也同樣關鍵。
5. 使用版本控制系統（VCS）： Git 和 Azure DevOps 等 VCS 是追蹤回溯移植變更及維護程式碼完整性的絕佳工具。它們提供版本歷程記錄，若回溯移植版本出現不穩定問題，且需要還原至先前的穩定版本時，這些記錄會非常實用。
6. 建立變更管理流程： 這包括在發布回溯移植修補程式之前進行徹底審查與檢視、在不影響應用程式功能的情況下套用回溯移植變更，以及在實施回溯移植後持續監控 IT 堆疊是否出現效能下降或其他潛在問題。
7. 使用正確的工具： 合適的 弱點管理與安全測試工具 能大幅提升回溯移植流程的順暢度。

回溯移植的常見使用案例

回溯移植最常見的使用案例是無法進行完整升級的舊版軟體。這在醫療、金融及其他產業中特別常見，因為舊有系統對日常營運至關重要，而任何升級嘗試都可能導致大規模服務中斷。其他回溯移植的使用案例包括：

• 保護任務關鍵型正式環境系統，在這類環境中高可用性至關重要，例如銀行常用來處理高流量與快速資料處理需求的大型主機

• 保護開源專案的長期支援（LTS）版本，例如 Linux kernel LTS，雲端服務供應商常使用此版本來確保穩定性，並促進混合環境中的版本相容性。

• 滿足 金融與醫療等高度受監管產業中的合規要求。例如，透過回溯移植修補程式，醫院可以在不面臨與升級相關的重大服務中斷情況下，持續遵循 HIPAA 等資料保護法規。

Unleash AI-Powered Cybersecurity

Elevate your security posture with real-time detection, machine-speed response, and total visibility of your entire digital environment.

Get a Demo

結論

回溯移植可以修正許多問題，但也可能帶來新的挑戰。使用 AI 威脅監控解決方案來處理持續存在或可能出現的弱點，會是安全的做法。您可以將安全性修補程式從較新的版本回溯移植到較舊的版本，以修補弱點，而不會造成具破壞性的升級。

成功的回溯移植需要廣泛測試、完整文件紀錄、正確的風險分析，以及協助執行流程的專業安全工具。