收到套件漏洞警示後，小型網站團隊應先修補甚麼？

先確認警示影響哪個系統

掃描器警示只是起點，不是完整風險結論。警示可能涉及開發者直接選用的套件、由其他套件引入的間接依賴、只在開發環境使用的工具，或已不在正式版本中的舊版本。OWASP 的依賴套件指引強調先弄清組件，以及應用程式哪些功能使用它。記下套件名稱、實際解析出的版本、公告或 CVE 編號、受影響版本範圍、如有提供的修補版本，以及包含該套件的網站或工作程序。查看鎖定檔及實際建置成果，不要只看套件宣告的版本範圍。存檔實驗項目的警示，不應擠掉正式客戶服務中可觸及的問題；但若舊環境仍對外開放，也不能完全忽略。

把顧客輸入如何到達套件的路徑畫清楚。由上載接口呼叫的檔案解析器，與只在離線轉檔工作中使用的同一套件，暴露程度不同。伺服器套件可能已部署但不會送往瀏覽器；瀏覽器套件則可能送給每位訪客。記下受影響功能有否被呼叫、甚麼資料能到達它、程序擁有甚麼權限，以及成功利用後可能改變甚麼。若短時間內無法判斷能否觸及，應記錄不確定性，暫時採取審慎的優先次序。不要因為團隊沒人記得使用某函式庫就直接消除警示；間接依賴很容易被忽略。決策記錄應指向程式碼或部署清單，方便另一位開發者複核。

根據證據排次序，別只看一個分數

先閱讀供應商本身的安全公告和套件官方版本說明，核對受影響版本，以及公告列出的利用前提是否符合公司的應用程式。之後查看該 CVE 是否在美國 CISA 的 Known Exploited Vulnerabilities 清單。CISA 指出，這份清單記錄已在現實中被利用的漏洞，可作為優先處理的依據。清單內針對美國聯邦機構的修補期限，並不會自動變成香港中小企的法定期限。列入清單是應加快處理的重要證據，但團隊仍須確認正式環境中的受影響組件和適合的補救方法。沒有列入清單，亦不能證明漏洞無害或不可能被利用。

嚴重程度評分有助整理工作，但不能取代對本地利用路徑的判斷。對這個應用程式而言，無法被呼叫的高評分函式，可能不及接收不可信輸入的公開接口中的較低評分缺陷迫切。相反，管理頁面使用人數少，也不代表安全；帳戶被盜和權限變動仍須考慮。每個個案應按實際利用證據、暴露範圍、資料或服務影響、是否有可安全採用的修補，以及尚存疑問來排序。把理由寫清楚，讓業務負責人可選擇發佈時段。若證據主要是定性資料，不要憑空造出精密風險分數。真正有用的結果是負責人、下一步措施、需要時的臨時控制，以及重新檢討的日期。

測試可維護的修補方案

若維護者已發佈修補版本，OWASP 建議先在測試環境嘗試更新，並執行涵蓋使用該套件功能的測試。這不只是確認安裝指令成功。以結帳系統為例，應測試套件參與的解析、驗證、登入工作階段或網絡路徑，以及相鄰的顧客流程。更新後在鎖定檔和最終建置成果中核對實際版本；宣告版本改了，另一個間接引入的舊副本仍可能存在。若跨主要版本更新改變接口，先調整呼叫程式碼，再重做測試。按原有發佈程序保留舊版以應對真正的功能回歸，但不能一見問題就無條件退回已知可被利用的狀態。

若沒有可用的修補版本，就按實際利用路徑選擇暫時緩解措施，例如停用受影響功能、限制進入解析器的不可信輸入、收緊接口存取，或移除不再需要的套件。這些只是例子，並非通用解藥；是否有效取決於漏洞及應用程式設計。OWASP 將補償控制、更新受阻及自行維護修補分作不同情況。團隊應寫明為何未能採用更新、如何測試臨時措施、由誰負責，以及甚麼情況下重新檢討。只有對特定套件及漏洞作出可複核的記錄判斷後，消除掃描警示才可能合理；消除警示本身並不是修補。

一個發佈決策例子

假設一家小型零售商的掃描結果指出影像處理函式庫有漏洞。團隊發現兩個副本：一個在開發者預覽工具，另一個在正式產品上載服務。正式副本接收商戶檔案，所以優先於預覽副本。官方公告指出危險路徑涉及特製影像格式；開發者確認正式接口接受該格式，然後查看維護者的修補版本及 CISA 清單中的實際利用證據。他們不會把未列入清單當成安全證明。團隊在測試環境更新函式庫，用一般產品圖片及可安全使用、對應公告情況的回歸測試檔，測試從上載到刊登的整個流程。預覽工具中的副本亦列入追蹤更新，不會從清單中消失。

若修補版本令縮圖生成失效，團隊要記錄選擇，不能直接關閉個案。他們可以修正整合後重測、暫時阻擋受影響格式而保留其他上載功能；如果沒有足夠控制，則考慮暫停該路徑。負責人須同時衡量顧客受影響程度和漏洞暴露。發佈後，再確認正式建置確實包含預期版本，並檢查上載、縮圖及錯誤處理是否正常。這是示範方法的假設例子，沒有聲稱曾發生商戶事故或利用事件。它說明同一公告對不同部署可能需要不同處理，也說明驗收證據須兼顧安全及正常業務用途。

以可驗證記錄結案

有效的結案記錄應列出受影響應用程式、修補前後的套件實際版本、公告編號、優先次序理由、採用的措施、測試證據、發佈識別資料和接受結果的人。若問題只靠臨時控制處理，記錄應明確說明仍未結案，並以修補版本出現或暴露情況改變作為複查觸發條件。對已部署成果重新掃描，確認警示狀態符合預期。掃描結果乾淨固然有用，但若掃錯環境就不足以證明安全；若使用已驗證的回移修補，警示亦可能仍然存在。每次應用程式增加功能時重看套件清單，因為原本不可觸及的漏洞函式可能因新功能而變得可觸及。

調查亦需要明確的停點。若安全公告含糊，可向維護者查詢，或檢查其官方問題紀錄及版本資訊；但若對外服務仍接收可能有害的輸入，不能無限期等待答案。記下哪些事實已確認、哪些仍有疑問，以及哪項臨時限制能減少合理的攻擊路徑。若決定延後修補，要指定收到新證據時由誰重開判斷，例如公告修正、出現實際利用證據，或推出兼容的修補版本。相反，若可證明所有正式建置都不含該套件，便保存證據，針對這些建置關閉警示，不應只為令掃描儀表板變綠而冒險升級。這是可重複的業務決策：團隊能說清技術狀態，也能解釋在選定發佈時段內，顧客服務如何得到足夠保護。

小型團隊可為每項警示保留一行共用記錄，而不是每次掃描都開一串新訊息。該行列出公告連結、受影響建置、負責人及目前狀態。同一 CVE 在新掃描中再次出現時，更新原有證據，避免形成互不相連的工作單。要分清修補版本已備妥但尚未部署，以及臨時緩解措施已在正式環境運作；兩者剩餘風險不同。若要緊急更新，先說明哪些正常檢查仍會執行，以及受影響功能需要哪些額外定向測試。部署後確認正在運行的建置，並觀察可能受更新影響的顧客操作。好的安全決策應經得起交接：另一位工程師毋須翻查一星期訊息，也能看出當初為何採取措施、測試過甚麼，以及尚有甚麼工作。