如果更新到受影響軟體的最新版本無法修復報告的漏洞或錯誤配置，或者沒有更新來解決問題，則需要乙個過程來分類和確定優先順序。
漏洞評估將突出顯示需要注意的任何安全、配置或更新管理問題。 若要管理攻擊面，應至少每月對整個資產進行一次漏洞評估。 如果您的組織從未執行過組織範圍的漏洞掃瞄，則第乙個報告可能包含數百甚至數千個漏洞。 了解攻擊面（外部與內部）也很重要。
更成熟的組織應考慮更定期的評估，特別是對於外部可訪問的服務。 如果您使用的是內置於雲環境中的等效工具，則應遵循提供商建議的節奏。
儘管供應商通常有發布更新的節奏，但可以隨時發布更新（稱為帶外更新）。 如果發現嚴重漏洞，則可能會發生這種情況。 如果這可能會影響您的組織，那麼制定乙個流程非常重要，該流程允許您隨時評估關注的漏洞。
區分旨在識別漏洞的漏洞評估系統和用於確定軟體版本的軟體資產管理非常重要。 在某些情況下，單個工具可以同時執行這兩種功能，但情況並非總是如此。 有關更多資訊，請參閱我們的漏洞掃瞄工具和服務指南。
定期掃瞄制度對於讓您了解您的組織可能面臨的風險至關重要。 它不需要由外部合作夥伴操作，工作人員也不需要任何特殊培訓。 NCSC 提供有關如何選擇、實施和使用自動漏洞掃瞄工具的指導。
漏洞和配置掃瞄還可以突出顯示軟體更新無法解決的問題，或者自動更新機制無法正常工作的問題，這意味著需要手動修復。 這些漏洞應使用原則 4 中概述的過程進行分類。 漏洞掃瞄對於突出顯示未安裝更新的情況也特別有用。
如果您開發軟體或執行系統，您還應該考慮建立乙個流程，允許安全研究人員向您報告他們發現的任何漏洞。 NCSC 漏洞披露工具包旨在簡化披露流程的設定。
有時，安裝受影響軟體的最新版本可能無法修復報告的漏洞或配置錯誤，甚至可能沒有更新來解決問題。 在某些情況下，不更新可能是合適的：例如，如果系統即將停用，並且漏洞難以發現且難以利用。 通過合理的控制，例如確保繼續退役，不續約是完全合理的。
但更多時候，由於員工時間限制或對更新軟體相容性的擔憂等限制，組織覺得他們無法解決問題。 充分了解這對組織的潛在影響非常重要。
雖然漏洞評估軟體或供應商諮詢可能會為發現的問題（例如通用漏洞評分系統或 CVSS）提供嚴重性評級，但您必須考慮組織的業務影響和風險。
有時，組織可能會評估自動更新的風險太高。 在這種情況下，應將系統新增到例外列表中，並且更新將通過組織要求的任何安全測試。 由於額外的測試可能需要大量時間，因此應將其限制在可用性至關重要且沒有安全恢復到已知良好狀態的機制的系統中。
如果出於任何原因沒有可用的更新，則需要乙個過程來對修復進行會審和確定修復的優先順序。
您應該合併所有問題並應用相同的分類和優先順序排序過程，以便系統所有者能夠完全了解相應地管理問題。
會審過程應首先將所有相似的發現或需要相同緩解的結果組合在一起：例如，所有 SSL 問題都成為乙個問題。 或者，您可以按類別對它們進行分組，例如外部暴露的漏洞。
一旦分組，它們應分為三類：要解決的問題、要確認的問題或要調查的問題。
修復“適用於將確保系統預設更新的問題，或者將對其實施重新配置或緩解的問題。 應優先考慮漏洞：面向 Internet 的服務或應用程式。
如果成功利用，它將產生最大的負面影響，例如關鍵共享基礎設施中存在的影響
在確定列表的優先順序和編制列表時，應記錄問題解決的日期。 這可能是供應商表示將發布修復程式的日期，也可能是估計何時可以實施配置更改。 如果修補程式是臨時供應商解決方法或緩解措施，則應有時間限制並主動跟蹤它，以便在提供並應用完整的供應商修補程式後可以將其刪除。
承認“無論你決定在這個時候不解決什麼原因。 不立即解決漏洞是有正當理由的，這些原因應與計畫的審查日期一起記錄在案。 如果它們存在的風險級別足夠高，請在風險登記冊中記錄問題。 如果將來利用漏洞，則承認問題（而不是解決問題）的理由應足以證明所做出的決定是合理的。 您還應該考慮實施額外的監控，以便在已知漏洞已被利用時提醒您。 調查分類無法將其歸類為“修復”或“確認”問題。 調查只能用作臨時狀態。 這可能是因為解決問題的成本未知，或者有多種可能的解決方案，需要做更多的工作來確定哪乙個最有效。 漏洞評估軟體並非萬無一失，可能會發生誤報。 如果您懷疑此問題，則應先對其進行調查，然後再將其作為問題刪除。 此類問題的時間表將取決於問題的嚴重性。