如何管理函式庫與套件？

前一章已經把程式語言、套件管理工具與其他開發工具納入共同環境。環境可以重建之後，還要進一步管理目標系統使用的外部程式碼。只記住安裝指令，無法說明專案需要哪些功能、實際取得哪些版本，也無法在套件停止維護或出現安全弱點時判斷影響範圍。

相依管理需要回答四個問題：為甚麼採用這個相依項目、哪些程式會使用它、目前實際使用哪個版本，以及日後如何更新、替換或移除。這些資訊應該與原始碼一起變更，讓相依關係成為可以檢查的專案內容。

先區分函式庫、套件與框架

函式庫（Library）、套件（Package）與框架（Framework）描述的層面不同：

一個套件可以包含一個或多個函式庫，也可能包含命令列工具、型別定義或其他資源。因此，程式實際呼叫的是函式庫提供的介面，套件管理工具處理的則是套件及其相依關係。框架也可能透過套件發布，但採用框架通常會影響較大範圍的程式結構，不能只視為多安裝一個函式庫。

這些名稱有助於辨認責任，不能單獨決定採用方式。評估時仍要查看實際公開介面、套件內容、相依項目及框架限制，避免只按照名稱推測影響範圍。

列出目標系統的相依關係

專案在套件資訊清單中直接宣告的項目稱為直接相依。直接相依所需要的其他套件稱為間接相依或遞移相依。開發人員可能沒有在程式中呼叫間接相依，但其版本、授權與安全問題仍會進入實際安裝結果。

每個直接相依至少要記錄下列資訊：

• 說明套件在目標系統中提供的功能，以及對應的使用位置。
• 記錄允許的版本範圍、實際解析版本與套件來源。
• 確認套件支援的程式語言、執行環境及其他必要相依項目。
• 保存授權條款、維護狀態及已知限制的檢查結果。
• 定義更新時要執行的建置、測試與相容性確認方式。
• 記錄無法繼續使用時的替換方向或移除條件。

如果無法說明某個直接相依的用途，應該先確認它是否仍由程式、建置或測試流程使用。已經沒有用途的套件會增加更新與檢查範圍，也可能讓間接相依繼續留在專案中。

按照使用時機分類相依項目

套件管理工具提供的分類名稱不一定相同，但專案仍要區分套件在甚麼階段被使用：

分類應該反映實際用途。把所有項目都列為執行相依雖然可能暫時通過建置，卻會擴大正式執行需要取得與檢查的內容。相反地，把執行時需要的套件誤列為開發相依，則可能讓開發環境正常、正式執行結果卻缺少必要內容。

評估套件是否適合採用

套件能完成需要的功能，只是採用條件之一。加入目標系統前，還要確認下列面向：

• 功能與相容性：公開介面符合需求，並且支援已選定的程式語言、框架與執行環境版本。
• 維護狀態：近期仍有可確認的維護活動、問題處理方式與支援週期，停止支援時也有明確資訊。
• 變更成本：版本變更紀錄、升級說明與淘汰項目足以判斷更新影響，公開介面也能由測試保護。
• 來源與完整性：套件來自已指定的來源，實際取得內容可以透過摘要、簽章或套件管理工具支援的機制核對。
• 安全狀態：直接與間接相依的已知弱點、修補版本及實際可利用條件都有檢查方式。
• 授權條款：套件及其間接相依的使用、修改與散布條件符合目標系統的使用方式。
• 替換難度：程式對套件專屬介面的依賴範圍清楚，必要時可以估算替換或自行實作的成本。

下載次數、熱門程度與最近發布日期可以作為參考，但不能代替上述檢查。維護活動頻繁也不代表每次更新都適合專案。對相容性、效能或整合方式仍有疑問時，可以使用小範圍概念驗證確認最重要的不確定項目，再決定是否採用。

管理版本與相容範圍

語意化版本（Semantic Versioning）以主版號、次版號與修訂號表達公開介面的相容性變更。遵守這項規格的套件會在不相容變更時增加主版號，在向後相容的新功能與錯誤修正中分別增加次版號與修訂號。

版本號仍是套件發布者對變更的表達，不能取代專案測試。套件可能沒有遵守語意化版本，也可能在相容版本中改變專案依賴的非公開行為。專案應該根據實際風險設定版本範圍，並以鎖定檔案保存已經驗證的解析結果。重大版本更新要先閱讀變更紀錄與遷移說明，再調整程式並執行完整驗證。

固定所有直接相依的單一版本可以縮小變動範圍，但仍要處理間接相依與後續安全修補。允許過寬的版本範圍則可能讓不同時間的安裝取得尚未驗證的版本。版本範圍負責表達可接受條件，鎖定檔案負責保存本次選定結果，兩者需要配合使用。

建立更新、替換與移除流程

套件更新應該形成可以重複執行的流程：

1. 先確認更新原因，例如修補安全弱點、取得必要功能、恢復支援或處理相容性問題。
2. 閱讀版本變更紀錄、淘汰通知與遷移說明，列出可能受影響的公開介面及設定。
3. 在同一項變更中更新套件資訊清單與鎖定檔案，檢查直接及間接相依的實際差異。
4. 從乾淨狀態重新安裝，執行建置、靜態檢查、相關測試及必要的人工驗證。
5. 記錄採用版本、更新原因、驗證結果與仍存在的限制，再合併至共同版本。

安全修補需要按照弱點是否影響實際版本、功能是否會觸發弱點及可用修補方式決定處理順序。掃描工具的嚴重程度可以協助分類，但不能單獨決定系統的實際風險。如果暫時無法更新，應該記錄原因、降低風險的措施、重新檢查日期與停止接受例外的條件。

替換套件時，要先列出目前使用的公開介面與行為，再以相同測試比較候選方案。移除套件後，還要重新產生鎖定檔案，確認不需要的間接相依已經消失，並從乾淨狀態完成建置與測試。

用軟體物料清單保存組成資訊

軟體物料清單（Software Bill of Materials，簡稱 SBOM）記錄特定系統版本包含的套件、版本、相依關係與其他組成資訊。SPDX與CycloneDX都提供可以交換這類資訊的標準格式。

SBOM 應該從實際解析或建置結果產生，並且能對應到特定的原始碼與系統版本。只從人工維護的直接相依清單產生內容，可能遺漏間接相依或實際封裝項目。套件或鎖定檔案變更後，也要重新產生 SBOM，避免文件停留在先前版本。

SBOM 可以協助查詢特定套件的影響範圍及檢查授權，卻不會自行判定某個弱點是否能在系統中被利用。它提供的是組成資訊，仍要搭配弱點資料、系統實際用法與驗證結果進行判斷。

需要使用套件管理工具？

如果目標系統使用外部套件，或需要建立與發布內部套件，通常就應該使用所選技術生態系支援的套件管理工具（Package Manager）。它能把相依需求、版本解析及實際安裝結果轉換成可以重複執行的專案流程，減少人工下載、複製與更新造成的差異。

套件管理工具只能按照設定執行相依管理，無法替專案判斷套件是否值得信任、授權是否合適或更新後是否相容。採用工具之後，仍要定義套件來源、版本規則、檢查方式與變更流程。

套件管理工具處理哪些工作

不同工具的功能範圍不完全相同，常見責任包括：

• 讀取套件資訊清單，確認專案宣告的直接相依與版本條件。
• 解析直接及間接相依，找出符合條件且彼此相容的版本組合。
• 從指定來源取得套件，核對工具支援的內容完整性資訊。
• 按照相依分類安裝、更新或移除套件，並同步更新解析結果。
• 顯示相依關係與可用更新，協助查找特定套件由哪個直接相依帶入。
• 在生態系支援時，執行已知弱點檢查、授權資訊輸出、SBOM 產生或套件發布。

弱點檢查、授權分析與 SBOM 產生不一定由同一個工具內建，也可以由其他工具讀取套件資訊清單、鎖定檔案或建置結果後完成。選擇工具時應該確認整體流程能產生需要的結果，不必要求單一工具負責所有工作。

用資訊清單描述需求，用鎖定檔案保存結果

套件資訊清單（Manifest）描述專案直接需要哪些套件、允許的版本範圍及相依分類。鎖定檔案（Lockfile）保存套件管理工具解析出的確切版本，通常也包含間接相依、取得來源與內容完整性資訊。

兩種檔案的責任不同：

對需要產生可執行結果的目標系統，套件資訊清單與鎖定檔案通常都要納入版本管理。安裝時應該使用工具提供的鎖定或凍結模式，在兩個檔案不一致時停止，而非直接改寫鎖定結果。供其他專案引用的套件是否保存或發布鎖定檔案，則要按照該生態系與套件管理工具的規則決定。

鎖定檔案也不能單獨保證所有環境產生完全相同的結果。套件管理工具版本、套件來源、條件式相依、執行環境及建置設定都可能影響安裝內容。共同環境還要固定相關工具版本，並從乾淨狀態執行安裝、建置與測試，才能確認結果可以重現。

統一安裝入口與套件來源

專案應該提供一組共同安裝入口，讓開發、測試與自動化流程使用相同的套件管理工具及參數。文件至少要說明支援的工具版本、安裝指令、是否只安裝特定分類，以及鎖定檔案不一致時的處理方式。

套件來源（Registry）也要明確設定。專案如果同時使用公開與私有來源，應該按照套件命名範圍指定對應來源，並確認不同來源出現同名套件時的解析規則。離線或限制對外連線的環境，可以使用經過管理的內部來源或快取，但仍要保留原始來源、版本與完整性資訊，並定義同步及更新方式。

如果私有套件來源需要身分驗證，設定檔只記錄來源位置與取得敏感資訊的方式。實際存取權杖或發布用憑證要由適合的安全設定機制提供，不得寫入套件資訊清單、鎖定檔案、原始碼或執行紀錄。讀取範圍也應該按照安裝與發布用途分開，避免日常安裝流程取得發布能力。

將相依檢查納入共同流程

套件管理規則需要由固定流程驗證，不能只依賴開發人員記得執行。可以在相依檔案變更及建立正式結果前執行下列工作：

1. 使用指定工具版本，從沒有既有安裝內容的狀態開始。
2. 按照鎖定檔案安裝，並在解析結果可能被改寫時停止流程。
3. 輸出直接與間接相依的實際差異，確認來源及非預期新增項目。
4. 執行建置、測試與相容性檢查，確認套件變更沒有改變預期行為。
5. 檢查已知弱點與授權條款，記錄需要處理或接受例外的項目。
6. 由實際結果重新產生 SBOM，讓組成資訊與本次版本一致。

自動更新工具可以建立候選變更與提供版本資訊，仍要通過相同檢查後才能採用。把多個重大更新合併成一次變更會擴大問題定位範圍，適合按照相依關係及風險拆分，逐一確認結果。

甚麼情況可以不使用？

程式完全沒有外部套件、不需要發布內部套件，而且所選技術的標準功能已經涵蓋全部需求時，套件管理工具可能沒有實際工作。這種情況仍要記錄程式語言與建置工具版本，並從乾淨環境驗證建置結果。

如果外部程式碼無法透過所選生態系的套件管理工具取得，專案可以選擇將來源內容納入版本管理或建立內部套件。無論採用哪一種方式，都要記錄來源、版本、完整性、授權、修改內容與更新方法。人工複製檔案卻沒有留下這些資訊，不能視為完整的相依管理方式。

專案規模小也不能單獨作為不用套件管理工具的理由。只要存在一個需要下載、解析版本或持續更新的外部套件，使用標準工具通常就比個別維護檔案更容易重現與追蹤。

導入後的最低完成條件

完成套件管理工具設定後，應該可以確認下列結果：

• 每個直接相依都有明確用途、分類、版本條件與指定來源。
• 套件資訊清單與鎖定檔案已納入版本管理，且變更內容可以接受審查。
• 指定的套件管理工具版本能從乾淨狀態重建相同的相依結果。
• 執行結果不包含只供開發使用且不需要發布的套件。
• 直接與間接相依都有安全弱點、授權及來源檢查方式。
• 套件更新、重大版本升級、例外接受、替換與移除都有可執行流程。
• 私有來源的敏感資訊不會進入原始碼、相依檔案或執行紀錄。
• SBOM 能對應到特定版本，並隨相依或建置結果變更而重新產生。

重點整理

• 函式庫提供程式可呼叫的功能，套件是發布與安裝單位，框架則會規範較大範圍的結構與執行流程。
• 相依管理要同時記錄直接與間接相依，並按照執行、開發及選用等實際用途分類。
• 採用套件前要確認功能、相容性、維護狀態、來源、安全弱點、授權條款與替換成本。
• 版本範圍表達可以接受的條件，鎖定檔案保存已驗證的解析結果，套件更新後仍要重新建置與測試。
• 使用外部或內部套件時，通常應該使用技術生態系支援的套件管理工具，統一解析、安裝、更新與移除流程。
• 套件資訊清單、鎖定檔案、工具版本、套件來源與共同安裝入口需要一起管理，才能從乾淨狀態重現相依結果。
• 弱點與授權檢查要涵蓋直接及間接相依，SBOM 則要由實際結果產生並對應到特定版本。
• 不使用套件管理工具時，仍要保留外部程式碼的來源、版本、完整性、授權、修改內容及更新方式。