修補程式管理（patch management）是指定期找出、排序、測試及安裝業務所用軟件的更新（修補程式），範圍由網站外掛程式到伺服器作業系統。大部分修補程式用來修正已公開的錯誤或保安漏洞。漏洞一旦公開，攻擊者便會搜尋仍未更新的系統，所以由修補程式推出到實際安裝之間相隔多久，影響很大。
對中小企而言，更新本身通常不難。問題多數出在不清楚哪些系統要更新、不清楚由誰負責，或擔心更新後系統出錯。
哪些地方需要修補
一個商業網站或網上應用程式，依賴的不只是當初委託開發的程式碼：
- 作業系統：伺服器、虛擬機器和員工電腦。
- 伺服器軟件：網頁伺服器、資料庫，以及 PHP、Node.js、.NET 等執行環境。
- 平台和 CMS：例如 WordPress、Magento 或其他電子商貿及內容管理系統。
- 外掛程式、佈景主題和擴充功能。
- 程式庫和相依套件：自訂程式碼內使用，很多由套件管理工具自動加入。
- 網絡及保安設備：防火牆、路由器和 VPN 設備都有各自的韌體。
- 雲端和託管服務：供應商負責修補部分層面，其餘仍由你負責。
實用的修補流程
1. 建立清單
不知道自己有甚麼系統，就無從修補。可以用一份簡單清單，記錄每個系統、所用軟件及版本、負責維護的人和寄存位置。清單應包括外掛程式和主要程式庫，不只伺服器。
2. 留意更新和保安公告
訂閱所用軟件供應商和項目的保安公告，並留意 CMS 或寄存控制台的更新提示。如果開發商或支援供應商已代為跟進，應向對方確認。
3. 按風險排序
不是每個更新都要即時處理。CVSS 等嚴重程度評分可作參考，但另外兩個問題往往更重要：漏洞是否正被攻擊者利用，以及受影響的系統是否可從互聯網直接連接。美國網絡安全及基礎設施安全局（CISA）發布的「已知被利用漏洞」（Known Exploited Vulnerabilities，KEV）目錄，列出有證據顯示已被實際利用的漏洞，可用來判斷哪些更新應優先處理。公開網站上的嚴重漏洞，一般應排在內部工具的小修正之前。
4. 先測試，再上線
先把更新安裝到 Staging 環境，再檢查對業務重要的流程，例如登入、結帳、預約和表格。回歸測試不論人手或自動進行，都有助確認現有功能在更新後仍然正常。
5. 安排維護時段
預先約定在流量較低的時間進行例行更新；如網站可能短暫停用，應通知員工或客戶。緊急保安修補未必能等到下一個時段，所以要另設較快的處理途徑。
6. 預備還原方案
更新前先備份或建立快照，並確定還原方法。記下原有版本號碼，萬一更新出問題，便可盡快復原。
7. 核實及記錄
更新後確認新版本已經運行，網站運作正常。網站監察可以發現之後出現的錯誤或停機。每次更新的內容、時間和負責人都應記錄下來。
已停止支援的軟件
每個軟件版本最終都會停止支援（end of life），之後供應商不再推出保安修補，新發現的漏洞便不會修正。應記錄作業系統、執行環境和平台的支援期限，在到期前預早安排升級。跨越多個大版本的升級往往需要開發工作，一再押後更新，正是技術債累積的原因之一。
由誰負責？
修補責任經常不清晰，尤其是網站由一間公司開發、由另一間公司寄存的時候。應寫明每個層面由誰處理：寄存供應商、開發商、內部 IT 還是支援夥伴。軟件支援 SLA 可以訂明包括哪些更新、緊急保安修補要多快完成，以及如何測試。如果沒有書面列明，便應假設沒有人在做。
網站應用程式防火牆（WAF）可在測試修補期間減低風險，但不能取代更新。technine.io 的託管支援及 SLA 服務把保安修補和相依套件更新納入日常維護。
常見問題
應該多久修補一次？
不少團隊會定期（例如每月）進行例行更新，緊急保安修補則在完成測試後盡快安裝。合適的頻率視乎每個系統的對外程度和重要性。
應否開啟自動更新？
部分元件適合自動更新，例如支援完善的軟件所推出的小型保安更新。對業務關鍵的網站和自訂系統，先測試再更新通常較穩妥，因為未經測試的更新可能令外掛程式或系統整合在無人察覺下失效。
選用託管寄存方案是否已經足夠？
視乎方案內容。寄存供應商通常會修補伺服器和作業系統，但未必包括 CMS、外掛程式或自訂程式碼。應確認方案涵蓋哪些層面。
更新後網站出錯怎麼辦？
先還原備份或舊版本，再在 Staging 環境找出原因。如果該更新是保安修補，可在找到可用的更新前採取臨時措施，例如加設防火牆規則或暫停受影響的功能。