【公益譯文】安全控制評估自動化支援：軟體漏洞管理

NISTIR 8011專項能力卷針對各資訊保安能力就安全控制評估的自動化進行了規範。各卷圍繞NISTIR 8011第1卷中的相關概述內容進行了詳細闡述，可作為模板，為實施符合NIST標準的具體的自動化評估做好準備。本文為NISTIR 8011第4卷，詳細介紹瞭如何自動評估與軟體漏洞管理安全能力相關的安全控制措施，以便管理軟體缺陷帶來的網路風險。本文件中，軟體漏洞管理針對的是系統中所使用軟體的已知缺陷。通用缺陷列表（CWE）為不規範編碼實踐所導致且有可能導致軟體漏洞的缺陷提供了識別符號，常見漏洞與暴露（CVE）列舉了大量已知漏洞。可結合使用CVE和CWE來識別軟體缺陷和導致特定缺陷的問題。有漏洞的軟體是攻擊者的重要目標，被用於發起內部攻擊並擴大控制。

一、前言

1.1      目的和範圍

NISTIR 8011第4卷為自動化評估與軟體漏洞管理（VUL）中的資訊保安持續監控（ISCM）安全能力相關的NIST SP 800-53[SP800-53]安全控制措施提供了操作方法。VUL能力符合NISTIR 8011第1卷[IR8011-1]中概述的原則。

本報告的範圍僅限於對NIST SP 800-53中定義的管理軟體安全漏洞和編碼缺陷的安全控制/控制項進行評估。

1.2      目標讀者

NISTIR 8011第4卷針對的是VUL能力，與授權、下載、安裝和/或執行軟體（尤其是軟體補丁）的人強相關，還與設計、編寫和測試軟體的人員以及希望瞭解非軟體資產中潛在軟體風險的人相關。

1.3      內容簡介

第2節簡要介紹了VUL能力，確定了範圍和目的，提供了VUL能力補充資訊的連結。第3節詳細介紹了VUL缺陷檢測以及如何使用缺陷檢測來自動評估支援VUL能力的NIST SP 800-53安全控制和控制項的有效性。第3節還提供了一些工具供組織使用，為支援軟體漏洞管理的大多數控制項生成自動安全控制評估計劃。

1.4      與本NISTIR中其他卷的關係

本NISTIR第1卷（《概述》）提供了自動化安全控制評估的概念性資訊、定義和背景，方便讀者理解本卷和後續卷中內容。[1]NISTIR 8011第4卷假設讀者熟悉第1卷中的資訊以及NIST風險管理框架[SP800-37]中的概念和術語。

VUL能力可檢測目標網路中已載入或執行中的有漏洞軟體，並根據組織的策略進行響應。識別有漏洞的軟體可以緩解漏洞。VUL能力依賴軟體資產管理（SWAM）能力[IR8011-3]提供已安裝軟體的清單。後續要檢查清單，確定是否存在已知漏洞和不規範編碼實踐。有時，特別是在沒有補丁的情況下，可更改配置設定（NISTIR 8011下一卷《配置設定管理》（CSM）能力的主要內容），透過禁用或以其他方式保護有漏洞的的軟體功能來緩解漏洞，從而支援軟體漏洞管理。

實際場景中，常使用漏洞掃描軟體檢測有漏洞的軟體。如果軟體掃描所基於的後設資料條理清晰[2]，則可使用白名單[IR8011-3]中使用的數字指紋來準確可靠地識別有漏洞的程式碼，如2.5.2.3節所述。

二、軟體漏洞管理（VUL）能力定義、概述和範圍

軟體漏洞管理基於這樣一個認識：即使是經過組織評估和批准在系統上執行的授權軟體，也可能存在已知漏洞和導致漏洞的編碼缺陷（潛在未知情況）。網路裝置上執行的授權軟體若存在編碼缺陷，也會被利用。內外部攻擊者的重要攻擊途徑是利用軟體缺陷，要麼直接攻擊軟體本身，要麼將軟體作為平臺，進而攻擊其他資產。

攻擊也會利用之前未知的軟體漏洞（通常稱為零日漏洞），儘管攻擊已知漏洞更為常見。VUL能力將存在缺陷的軟體分配給個人或團隊進行響應，可以降低攻擊者發現和利用軟體缺陷和漏洞的機率。

2.1      發現缺陷/確定響應優先順序

運用VUL能力，組織可發現已授權或待授權軟體[3]中的漏洞。發現了漏洞，組織才能有效地管理和保護自己。VUL能力還提供了軟體管理責任檢視，方便相關管理人確定已識別缺陷的優先順序，做出風險響應決策（例如緩解或接受）。

VUL能力可識別網路上存在的軟體（實際狀態），並將其與期望狀態的軟體清單進行比較，以確定是否存在漏洞較少（通常較新）的軟體版本可供部署，或者是否需要使用打補丁以外的緩解策略。[4]VUL能力的重點是儘可能確保目標網路上執行的所有軟體不受已知漏洞的影響，並應用有效的修補和響應策略[5]。

注意，NISTIR 8011第3卷定義的軟體包含韌體。本卷使用相同的定義。

 這裡的軟體（程式碼）指各種資產，包括有時可能並未當作軟體的資產。具體軟體資產包括：

2.1.1 作業系統軟體資料庫（如Windows登錄檔、Linux軟體包管理器）中列出的已安裝軟體檔案和產品；

2.1.2 硬碟上存在但未列示在作業系統資料庫中的軟體檔案和產品；

2.1.3 移動程式碼；

2.1.4 可以修改的韌體（通常包括BIOS）；

2.1.5 記憶體中的程式碼（可以就地修改）。

2.2      VUL攻擊場景和期望結果

NISTIR 8011使用攻擊步驟模型總結了網路攻擊的六大步驟，這裡的“網路攻擊”指NIST SP 800-53中的控制措施共同攔截或延緩的攻擊。VUL安全能力僅限於在圖1和表1所列的攻擊步驟中攔截或延緩攻擊。

圖1.   VUL對攻擊步驟模型的影響  

表1.   VUL對攻擊步驟模型的影響

需求層級之間的可追溯性。表1顯示了軟體漏洞管理對示例攻擊步驟的影響，但通常更有用的是觀察其他需求集之間的可追溯性。為了檢視這種可追溯性，可以使用表2來顯示不同需求型別之間的可追溯性，方法是在對應的行和列中查詢單元格，然後單擊連結。例如，點選“示例攻擊步驟”一列中表6的連結，可以發現該攻擊步驟和子能力/缺陷檢測ID、名稱和目的之間的關係。 

控制措施和攻擊步驟之間的完整可追溯性要求在路徑中加上以下連結：

1.     控制到控制項（在控制項名稱中提供）

2.     控制項到判斷語句（見3.3節）

3.     判斷語句到缺陷檢測（即子能力；見3.3節）

4.     缺陷檢測（即子能力）到能力（在子能力名稱中提供）

5.     缺陷檢測（以及能力）到攻擊步驟（見表6）

6.     能力到攻擊步驟（見圖1（對表6的總結））

表2.   需求層級之間的可追溯性

 各四級標題（如3.3.1.1）為支援該能力的一個控制項。

見各缺陷檢測的“支援控制項”部分的表格。

2.3      VUL管理和評估的評估物件

VUL能力管理和評估的物件包括軟體漏洞和透過軟體緩解的硬體漏洞。[6]VUL能力直接管理、評估的軟體漏洞有兩種：（1）在裝置上使用的軟體檔案的特定版本和補丁級別中發現、分析並確定存在的CVE[CVE]；（2）在裝置上使用的軟體產品和檔案的軟體程式碼中暴露出的不規範程式設計實踐，即CWE[CWE]。當裝置上執行的軟體中包含的CVE和CWE引起的風險若在組織可容忍的範圍內，即認為裝置受到保護。

系統上的軟體漏洞數量隨著時間的推移而有增有減。發現了新漏洞，則數量增加；漏洞被修復，則數量減少。需要定期重複評估，以保持資訊的時效性。

VUL能力重在防護已知漏洞，因為針對這些漏洞，潛在攻擊者能夠以很低的成本輕鬆獲取攻擊知識和工具。大多數已知漏洞有修補程式（否則，該漏洞被視為零日漏洞，因為該漏洞雖被披露，卻沒有可用的緩解措施；見2.3.1節）。遺憾的是，已知漏洞並不總能及時修補，也就是說，在任何時候，某些系統和系統元件都可能存在未修補的、可利用的軟體漏洞。

合理的漏洞管理程式，即使是隻關注已知漏洞，也有助於抵禦有錢、有幹勁、有能力的攻擊者。老練的攻擊者會花費大量資源來發現、武器化和隱藏未知漏洞。他們在部署武器化的未知漏洞方面非常謹慎，因為這種行為有暴露漏洞的風險（即從未知變為已知），一旦暴露，可能會被防禦方緩解和修復。因此，有錢、有幹勁、有能力的攻擊者通常更傾向於利用已知漏洞進行攻擊，因為已知漏洞的攻擊成本低，利用這些漏洞就不需要浪費寶貴的未知漏洞資源來實現攻擊目標。因此，若軟體針對已知漏洞做了保護，即使是老練的攻擊者也會增加攻擊成本。

VUL能力還可能會處理未知漏洞，例如，掃描不規範的編碼實踐（如CWE）。掃描CWE可以讓未知漏洞變成已知，進而處理這些漏洞。因此，雖然VUL能力主要關注的是已知漏洞（如CVE），但也會透過關注軟體缺陷的常見來源（如CWE）來解決與未知漏洞相關的風險。

 2.3.1         CVE

CVE專案[CVE]提供了漏洞列表，每條漏洞都包含唯一的標識號、描述以及至少一個公開參考連結。[7]這些漏洞均為特定軟體中發現、公開披露且上報給https://cve.mitre.org的網路安全漏洞。CVE因為具有如下重要特徵，因而適用於自動評估：

·       CVE是描述軟體中包含的公開披露的網路安全漏洞的標準方法；

·       CVE列表是一個字典，每個漏洞或暴露就是一個條目；

·       每個CVE具有唯一識別符號，可在業界各軟體系統間通用；

·       同一CVE在不同的產品、工具和服務間具有相同含義。

漏洞一旦被公開且被分配CVE ID，維護軟體的廠商組織[8]就會著手開發補丁來修復該漏洞。對編碼缺陷進行修復（打補丁等方法）的目的是在攻擊者發現並利用它們之前發現並緩解問題。對於防禦者來說，挑戰在於在管理不斷增加的程式碼複雜性的同時，還要領先於攻擊者一步。

從（某人）發現漏洞到軟體控制組織知道漏洞並提供補丁期間，該漏洞被稱為零日漏洞。在這段時間內，軟體一直暴露在風險之下，直到釋出並應用補丁。在暴露期間，防禦攻擊的選項僅限於白名單、[9]應用常見的安全配置、隔離或刪除。

在評估風險時，應明白上報的軟體漏洞數量不一定與軟體廠商和產品中的實際軟體漏洞數量相一致。攻擊者希望經濟高效地利用漏洞，這樣，跨平臺（如Acrobat和Java）實現的軟體或在主流平臺（如微軟或思科）上實現的軟體最具吸引力，因為所需要的時間最少。所以，基於主流平臺的軟體程式碼報告的漏洞最多。

上報的漏洞數量多可能是由於漏洞研究和報告越來越集中於主流軟體。通常情況下，某一系列軟體版本中公開披露的漏洞數量越多，說明軟體提供商的成熟度越高。軟體平臺提供商常擁有強大的漏洞披露、上報和管理程式，這些都說明軟體提供商具有良好的風險管理實踐。反之，沒有上報漏洞的產品不一定就沒有漏洞。

國家漏洞資料庫[NVD]以標準的機器可讀格式向公眾釋出CVE資訊。就已知軟體漏洞和漏洞資訊分析而言，NVD是美國政府最全面的一種公開資訊來源。CVE專案還維護了一個CVE資料集，該資料集可能包含更多的漏洞[10]，但提供的漏洞相關資訊較少。在本檔案中，術語NVD同時指nvd.nist.gov和cve.mitre.org。有時，業界會發現尚未在NVD中分類的公開披露的漏洞，但此類來源通常是未公開的私有渠道。

漏洞一般透過以下方式識別：

·       NVD[NVD]中的每條CVE由CVE[CVE]編號機構[CNA]分配ID。CNA可以是廠商、開源提供商或研究人員。NVD從CVE獲取資料。

·       知名的軟體製造商擁有成熟強大的漏洞管理程式，它們會上報已驗證漏洞。

·       第三方道德駭客上報漏洞。

 有些可利用的程式碼漏洞未透過CVE專案公開，因此未作為CVE列入NVD。[11]已知漏洞未公開披露的原因可能有多種，包括但不限於：

·       只有犯罪分子和/或情報機構發現了漏洞，他們打算有朝一日利用該漏洞，因此不想披露。

·       漏洞可能只存在於定製軟體和/或工業控制系統中。由於使用者數量有限且所涉及系統具有潛在敏感性，漏洞未在NVD中列出，可能的原因是披露這些漏洞或會增加攻擊的風險，而不是保護受影響的系統。

·       漏洞存在於商用現成（COTS）軟體中，但在補丁出現之前不會公佈，因為披露該漏洞可能會增加攻擊風險，而不是保護系統。

·       漏洞掃描提供商可能在分配CVE ID之前已發現漏洞。

由於廠商和攻擊者在公開漏洞方面存在的差異，再加上攻擊者發現漏洞後有意瞞報，軟體產品的CVE數量不一定能反映產品的實際漏洞數量。

2.3.2         CWE

CWE是一種廣為人知的分類法，針對的是生產軟體過程中發現的不規範編碼實踐[CWE]，例如“輸入驗證問題”，CWE網站上對此描述如下：

“軟體不能正確驗證輸入時，攻擊者就能構造輸入，讓應用程式的其他部分無法識別，這樣，系統的某些部分就會接收到意外輸入，導致控制流改變、任意資源控制或任意程式碼執行。” [CWE]

缺乏充分驗證的話，攻擊者就能以意外方式更改程式流，造成安全漏洞。更多例子，見[CWE]。

與自動化評估相關的常見缺陷具有以下重要特徵：

·       程式碼分析器一般要麼是靜態，要麼是動態。靜態程式碼分析器用於檢查原始碼（程式語言級別）或編譯程式碼（機器語言級別）。動態程式碼分析器用於觀察程式碼執行時的行為、探測應用程式以及分析應用程式響應。

·       雖然NVD中的CVE描述通常會提供導致CVE的不規範編碼實踐（即CWE）的相關資訊，但CWE並不一定會導致CVE。如果沒有對程式碼進行分析、探測，或者未檢測缺陷，那麼就可能忽略缺陷。這種情況下，缺陷可能最終會發展為CVE。

·       即使對程式碼進行了分析且將一段程式碼標記為了CWE，仍不一定會實際導致CVE，因為用於檢測不規範編碼實踐的程式碼分析器會有大量誤報（程式碼分析器將程式碼標識為包含不規範的編碼實踐，而實際並非如此）。

·       程式碼分析器識別出的、未驗證為誤報的不規範編碼實踐被視為軟體漏洞。由於程式碼分析器報告經常出現誤報，一般透過對所識別的不規範編碼實踐進行單獨確認和驗證進行修正。對所謂的不規範編碼實踐需要進一步分析，確定應該忽略（確定是誤報），還是採取行動（問題確實存在），進行恰當響應或上報。

·       CWE主要是控制、維護原始碼的開發或測試人員最為關注，這類人群所在的組織主要開發COTS、政府現成（GOTS）或定製程式碼。此外，將軟體部署到生產環境中之前需要驗證軟體安全性（即需要額外的軟體安全保證）的組織也會關注CWE。

確保程式碼不包含CWE的方法主要有三種，按有效性排序，分別為：

1.     招募有安全編碼實踐經驗的開發人員，同時確保現有開發人員接受安全編碼實踐培訓；

2.     採用流程：確保程式碼由具有安全編碼實踐經驗的程式設計師團隊獨立審查；

3.     使用程式碼分析器：在編寫或編譯程式碼後，程式碼分析器常常能發現程式碼中的不規範程式碼實踐；此外，程式碼分析器還會自動檢查應用程式。

2.3.3         CVE和CWE緩解角色

要理解NISTIR 8011所定義的漏洞管理角色，首先要了解組織角色。卡內基梅隆CERT的特別報告《CERT漏洞協同披露指南》[SEI]描述了漏洞管理角色，如下圖所示。

圖2.   漏洞資訊披露中的組織角色[SEI]

角色有時是組織，有時是個人。

·       最常見的個人角色包括：發現者、上報者和部署者（例如家庭使用者、組織使用者、系統管理員）。

·       最常見的組織角色包括：廠商和協調者，若軟體為政府或商業組織所使用，還有部署者（例如軟體漏洞管理人、補丁管理人）。

“廠商”這一角色需要進一步解釋。這類實體指當前維護有漏洞軟體的一方。正如卡內基梅隆CERT報告所述，“廠商是負責更新有漏洞產品的一方。”因此，在漏洞管理方面，廠商並非部署者（個人使用者或組織）所購買軟體的第三方廠商。

請注意，對於定製或內部軟體程式碼，“負責更新產品的一方”可能是部署者組織內部的員工或團隊，也可能是部署者組織合作的服務提供商。

 圖2中所示的協調者角色通常獨立於評估組織，不屬於NISTIR 8011範圍，在此不予贅述。通常，協調者角色由SEI、漏洞掃描器廠商和源文件中列出的其他團隊執行。

對於維護和授權的軟體，NISTIR 8011定義的CWE和CVE緩解角色包括軟體漏洞管理人（SWFM）（與CERT定義的廠商角色對應）和補丁管理人（PatMan）（與CERT定義的部署者角色對應）。[12]圖3列舉了NISTIR 8011為緩解CWE和CVE而定義的角色及其職責。請注意，對於未授權軟體，不會為CVE開發補丁，除了隔離或刪除之外，可能沒有其他的緩解辦法。

圖3.   CVE和CWE緩解角色

SWFM和PatMan角色的職責不一定是隻完成圖3中的任務，相反，這些任務可能是某個角色多項職責中的一部分。

2.3.3.1  軟體漏洞管理人（SWFM）

SWFM是廠商組織角色。因此，軟體漏洞管理可能是第三方廠商組織的責任，軟體所有組織對此幾乎沒有控制權（例如，對於大多數COTS軟體），也可能是軟體所有組織本身的責任（例如，對於內部開發的定製軟體）。

當發現並確認廠商組織維護的軟體存在新漏洞時，將漏洞上報給CVE專案，以便將其列為CVE（或決定不上報漏洞或何時上報漏洞[15]）。廠商組織（維護軟體原始碼的組織）內部的軟體漏洞管理人（SWFM）隨後開發新補丁以緩解漏洞。

·       對於COTS或外部維護的GOTS軟體，補丁由外部廠商組織的SWFM開發。

·       對於定製或內部維護的GOTS軟體，補丁由內部組織（廠商和部署者）的SWFM開發。

無論是緩解CVE還是CWE，SWFM都負責向廠商組織上報所維護軟體中發現的不規範編碼實踐和漏洞，評估需修復的程式碼數量，進行必要的修復，準備補丁，進行整合，測試補丁，撰寫文件，並將補丁傳送給部署者組織。

2.3.3.2  補丁管理人（PatMan）

補丁管理人（PatMan）是部署者組織角色，存在於授權和使用軟體的組織（部署者組織）中。

PatMan負責檢測裝置和授權軟體中存在的CVE，並應用補丁或臨時規避方案。此處提到的軟體（即程式碼）通常按以下級別進行分析和管理：

·       軟體檔案（透過數字指紋識別）

·       軟體原始碼（即版本/補丁級別的軟體檔案內容）

·       軟體產品（版本/補丁級別）

·       可修改的韌體（通常包括BIOS，版本/補丁級別）

就漏洞管理而言，準確檢測軟體的具體版本和補丁級別非常重要。這是因為不同的軟體版本根據所應用的補丁，包含不同的漏洞。數字指紋唯一地標識軟體檔案的特定版本和補丁級別。

PatMan在檢測系統中存在的CVE時使用的主要工具是商業漏洞掃描器。漏洞掃描器自動發現系統中各個裝置上安裝的所有軟體檔案中的CVE和所需的補丁程式。同時，補丁程式也會提供它們所緩解的CVE資訊。

PatMan負責從內部或外部開發組織（即廠商組織）接收補丁，測試本地系統上補丁的互通性，並將補丁應用到生產環境中的裝置上。在廠商提供補丁之前，可以其他方法來緩解某些CVE。這種情況下，PatMan負責在過渡期內應用臨時規避方案。

補丁通常透過軟體包管理系統應用，該系統自動執行軟體檔案的安裝、升級、配置和刪除。[16]此外，也可以手動打補丁。

有些軟體產品的補丁必須按順序應用，在這種情況下，應指定補丁級別。有些產品允許按不同順序選擇性應用補丁。在這種情況下，“補丁集”一詞比“補丁級別”更準確。[17]“補丁集”本質上比“補丁級別”複雜，因為補丁應用順序有多種組合方式。本文件中，“補丁級別”一詞根據實際情況可指補丁級別，也可以指補丁集。

共享程式碼帶來的修補複雜性。有些可執行檔案由多個軟體產品共享。動態連結庫（DLL）可執行檔案就是共享軟體的典型例子。就修補DLL而言，一個產品可能為其他產品帶來保護，也可能將其他產品暴露於風險中，具體是保護還是暴露取決於DLL最新補丁中有哪些漏洞以及依賴軟體如何使用該庫。例如，在OpenSSL加密庫中存在“心臟出血”（Heartbleed）漏洞，但該漏洞隻影響OpenSSL提供的傳輸層安全性（TLS）實現，OpenSSL加密演算法應用程式程式設計介面（API）不受該漏洞影響。也就是說，OpenSSL的TLS實現暴露了“心臟出血”漏洞，但加密函式實現卻沒有。因此，部分軟體產品的共享性增大了軟體漏洞管理的難度。

補丁之上摞補丁。遺憾的是，補丁本身也可能包含漏洞，後續才會發現。即使補丁當前沒有已知漏洞，也有可能、甚至很可能在今後發現新的或其他的不規範編碼實踐，成為NVD中的新CVE條目或導致新的零日攻擊。

[1] NISTIR 8011第1卷（2017年6月）將VUL能力作為NISTIR 8011的第5卷。但是，後來發現，NISTIR 8011各功能卷的釋出順序需要最佳化，因此將VUL能力調整到第4卷。NISTIR 8011各能力卷的釋出順序將在第1卷的勘誤版本中進行修訂。

[2] 條理清晰是指已知哪些軟體程式碼檔案（透過其數字指紋識別）存在漏洞，並使用軟體白名單來確定是否存在有漏洞的檔案。

[3] 特定的軟體產品得到授權後，作為元件在聯網或未聯網的系統上執行。而考慮到效率和有效性，系統和系統元件需要網路連線進行自動化評估。獨立的系統/系統元件不適合自動評估。有關授權範圍（系統）與自動評估範圍（網路）的資訊，參見NISTIR 8011第1卷。

[4] 關於實際和期望狀態的描述，見2.5.1和2.5.2節。

[5] 修補和響應策略可納入組織的漏洞管理策略。

[6] 硬體漏洞通常透過軟體來防護，例如為韌體或作業系統打補丁，控制硬體訪問或關閉硬體功能。在NISTIR 8011中，軟體漏洞包括透過軟體緩解的硬體漏洞。若硬體漏洞無法透過軟體防護，需要對硬體進行物理修改或更換，這種漏洞不在NISTIR 8011第4卷討論之列。

[7] 本文釋出時，CVE專案正處於過渡期，CVE專案的管理組織和相關網站可能會發生變化。

[8] 有關廠商組織的定義，參見2.3.3節。

[9] 請注意，雖然惡意軟體因為未授權而無法在白名單環境中執行，攻擊者仍然可以透過白名單軟體本身的未緩解漏洞進入環境。因此，即使在白名單軟體環境中，軟體漏洞管理也是高優先順序事項。

[10] MITRE網站[CVE]上列出的CVE描述不夠完整，所以連結到NVD以提供更多資訊。本文釋出時，CVE專案正處於過渡期，CVE專案的管理組織和相關網站可能會發生變化。

[11] 有些廠商組織選擇不向CVE專案報告漏洞，而是透過本公司專有流程維護漏洞資訊並提供補丁。

[12] 有關支援VUL能力的各個角色，參見2.7節。

[13] 注意，SWFM角色通常是軟體開發/維護人員或軟體開發/維護管理人的子角色，而不是完全獨立的角色。這裡指定SWFM角色有助於緩解軟體漏洞，構成VUL能力的一部分。

[14] 在他人開發的軟體中查詢CWE主要適用於如下情況：部署組織有內部SWFM並使用動態程式碼掃描器來檢測他人開發的COTS或GOTS產品中的不規範編碼實踐（CWE）。

[15] 例如，直到開發出補丁後再上報漏洞，防止在此期間被攻擊。

[16] Microsoft Windows Store、Linux Red Hat RPM package Manager、Apple Mac App Store、Debian DPKG和Perl綜合典藏網（Comprehensive Perl Archive Network）都是軟體包管理系統。

[17] 如果指定了補丁集，則補丁的應用順序仍會影響結果（例如，當兩個或多個補丁更改同一個檔案時）。