Docker 容器安全掃描與授權遵循實務：從漏洞檢測到合規管理完整指南

– 24 分鐘閱讀

容器化技術徹底改變了現代軟體的開發與佈署模式，Docker 作為最廣泛採用的容器平台，已經成為許多企業技術架構的核心元件。然而，這種技術革新也帶來了新的安全挑戰。每個 Docker 映像檔都承載著完整的執行環境，包含作業系統、系統函式庫、相依套件以及應用程式本身。這種封裝特性雖然提升了可攜性與一致性,但也意味著任何一層的安全漏洞都可能成為攻擊者的入口點。根據統計資料,超過 80% 的容器映像檔存在已知的安全漏洞,而這些漏洞中約有 40% 屬於高危險等級。更值得關注的是,許多組織在將映像檔佈署到生產環境之前,並未進行系統化的安全檢查,這無疑為資訊安全埋下了隱患。

在實際維運經驗中,我們經常遇到開發團隊基於過時的基礎映像檔建立應用程式容器的情況。舉例來說,某個採用 Alpine Linux 3.14.1 版本建立的映像檔,在經過容器安全掃描後發現超過 30 個預設安裝套件存在已知漏洞。這個版本發布距離掃描時點僅約十個月,卻已經累積了相當數量的安全問題。這個案例凸顯了一個重要事實:基礎作業系統的版本選擇與更新策略,直接影響整個容器的安全基準。Alpine Linux 之所以成為許多 Docker 映像檔的首選,正是因為它採用極簡設計理念,預設安裝的套件數量遠少於 Ubuntu 或 Debian 等發行版。套件數量的減少不僅降低了映像檔大小,更重要的是顯著縮小了潛在的攻擊面。

除了映像檔本身的安全性,開源軟體授權的合規性也是容器化應用必須面對的重要課題。現代應用程式往往依賴數十甚至數百個開源函式庫,每個函式庫都受到特定授權條款的約束。這些授權條款的法律效力不容忽視,違反授權規定可能導致嚴重的法律後果與商業風險。MIT 與 BSD 等寬鬆型授權允許幾乎不受限制的使用方式,但 GPL 系列授權則要求衍生作品必須採用相同的授權條款。這種「分享協定」特性對於封閉原始碼的商業軟體而言構成了重大限制。更複雜的情況是,某些授權明確禁止特定產業使用,例如軍事相關應用,或對使用國家設有地理限制。在管理數量龐大的相依套件時,若缺乏系統化的授權追蹤機制,很容易在無意間引入不相容的授權組合,進而衍生法律糾紛。

GitLab 平台提供了完整的安全與合規工具鏈,讓容器掃描與授權遵循可以無縫整合到 CI/CD 流程之中。這種整合的價值在於能夠在開發的早期階段就發現問題,避免將安全漏洞或授權衝突帶入生產環境。透過持續整合管線的自動化掃描,每次程式碼提交或映像檔建置都會觸發安全檢查,形成持續性的安全防護機制。這種左移測試的理念不僅降低了修復成本,也讓安全成為開發流程的內建特性而非事後補救。當安全掃描發現問題時,開發人員可以立即在同一個平台上檢視詳細資訊、評估風險等級,並採取對應的修復措施。授權遵循功能更進一步,允許組織建立授權政策,在合併請求階段就能自動阻擋引入不合規相依套件的程式碼變更,從源頭確保專案的授權合規性。

Docker 容器安全掃描的技術架構

要理解容器安全掃描的運作機制,首先需要釐清 Docker 映像檔的組成結構。Docker 映像檔採用分層架構設計,每一層都代表檔案系統的增量變更。最底層通常是基礎作業系統的檔案系統快照,接著是應用程式執行所需的系統函式庫與工具,最後是應用程式本身的執行檔與資源檔案。這種分層設計帶來了儲存效率與快取優勢,但也意味著安全問題可能存在於任何一個層級。Dockerfile 作為建置映像檔的藍圖,定義了從基礎映像檔開始的每個建置步驟。選擇哪個 Linux 發行版作為基礎、安裝哪些系統套件、如何配置執行環境,這些決策都會影響最終映像檔的安全態勢。

容器掃描技術的核心是漏洞資料庫的比對機制。掃描工具會解析映像檔的每個層級,識別其中安裝的套件及其版本資訊,然後與持續更新的漏洞資料庫進行比對。這些漏洞資料庫收錄了各種作業系統發行版與軟體套件的已知安全問題,包括 CVE 編號、嚴重程度評級、影響範圍以及修復建議。掃描結果不僅列出發現的漏洞,還提供詳細的上下文資訊,協助開發團隊評估風險並決定處理優先順序。值得注意的是,掃描工具的覆蓋範圍有其限制。主流的容器掃描器通常支援常見 Linux 發行版的近期版本,例如 Alpine、Ubuntu、Debian、CentOS 等最新的兩到三個主要版本。對於較為冷門的發行版或過於老舊的版本,可能無法獲得完整的掃描支援。

@startuml
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

package "Docker 映像檔結構" {
  [應用程式層] as App
  [相依套件層] as Deps
  [系統函式庫層] as Libs
  [基礎作業系統層] as OS
}

package "容器掃描流程" {
  [映像檔解析] as Parse
  [套件版本識別] as Identify
  [漏洞資料庫比對] as Match
  [風險評估分析] as Risk
}

database "漏洞資料庫" {
  [CVE 記錄] as CVE
  [修復資訊] as Fix
  [嚴重度評級] as Severity
}

App --> Deps
Deps --> Libs
Libs --> OS

Parse --> App
Parse --> Deps
Parse --> Libs
Parse --> OS

Identify --> Parse
Match --> Identify
Match --> CVE
Risk --> Match
Risk --> Severity

note right of Risk
  產生包含以下內容的掃描報告
  - 漏洞清單與 CVE 編號
  - 影響範圍與風險等級
  - 修復建議與可用補丁
  - 套件版本升級路徑
end note

@enduml

Container Scanning 功能預設會檢查 GitLab 專案 Container Registry 中儲存的映像檔。Container Registry 為每個專案提供私有的映像檔儲存空間,相較於公開的 Docker Hub,它提供了更嚴格的存取控制與審計追蹤能力。這種設計確保了組織內部的映像檔不會意外洩露,同時也便於進行集中化的安全管理。掃描流程通常整合在 CI/CD 管線的測試階段,當建置流程產生新的映像檔並推送到 Registry 後,自動觸發安全掃描作業。這種自動化機制確保了每個版本的映像檔都經過安全檢查,避免人為疏忽導致的安全漏洞。

Container Scanning 提供了語言套件掃描的選項功能,這項功能預設為停用狀態。啟用後,掃描器會檢查透過語言套件管理工具安裝的函式庫,例如 Ruby 的 Bundler、Python 的 pip、Node.js 的 npm 等。這些語言特定的相依套件同樣可能存在安全漏洞,但這個掃描範圍與 GitLab 的 Dependency Scanning 功能重疊。實務上,許多組織選擇依賴專門的 Dependency Scanning 來處理應用程式層級的相依套件,讓 Container Scanning 專注於作業系統與系統層級的套件檢查。這種職責分工避免了重複掃描造成的資源浪費,也讓掃描結果更易於解讀與管理。

不同的 Linux 發行版在安全性、套件管理、社群支援等面向各有特色。Alpine Linux 以其極致的輕量化設計著稱,完整的基礎映像檔大小僅約 5MB,遠小於 Ubuntu 或 Debian 動輒數百 MB 的體積。這種輕量特性不僅加快了映像檔的傳輸與啟動速度,更重要的是大幅減少了預設安裝的套件數量。較少的套件意味著較小的攻擊面,也降低了需要持續追蹤與更新的安全漏洞數量。然而,Alpine 使用 musl libc 而非傳統的 glibc,某些應用程式可能面臨相容性問題。Ubuntu 與 Debian 則提供了更完整的套件生態系統與廣泛的社群支援,適合需要較多系統工具的應用場景。Red Hat Enterprise Linux 衍生的 CentOS 或 Rocky Linux 則強調企業級的穩定性與長期支援。選擇基礎映像檔時,需要在安全性、相容性、維護成本之間找到適當的平衡點。

Container Scanning 的啟用與組態策略

啟用 Container Scanning 功能可以透過直接編輯 .gitlab-ci.yml 檔案或使用 GitLab 的圖形化介面來完成。對於熟悉 GitLab CI/CD 配置的團隊,直接編輯配置檔案是最快速的方式。首先確保管線定義包含測試階段,這是大多數安全掃描工具的慣例執行階段。接著引入 GitLab 提供的官方範本,這個範本封裝了 Container Scanning 所需的完整作業定義與預設參數。範本的使用大幅簡化了配置複雜度,開發團隊不需要深入了解掃描工具的細節即可快速導入。

stages:
  - test

include:
  - template: Security/Container-Scanning.gitlab-ci.yml

這個最精簡的配置已經足以啟動基本的容器掃描功能。當管線執行時,Container Scanning 作業會自動搜尋專案 Container Registry 中的映像檔進行掃描。預設行為適用於標準的容器開發流程:建置映像檔、推送到 Registry、觸發掃描、產生報告。然而,實際的專案需求往往更為複雜,可能需要掃描存放在外部 Registry 的映像檔、調整漏洞嚴重度門檻、啟用語言套件掃描等進階功能。

圖形化介面提供了更直觀的啟用方式,特別適合不熟悉 YAML 語法或偏好視覺化操作的使用者。在專案的左側導航選單中選擇「Security & Compliance」選項,進入「Configuration」頁面後可以看到所有可用的安全掃描工具。找到 Container Scanning 項目並點擊啟用按鈕,GitLab 會自動產生一個合併請求,將必要的配置變更加入 .gitlab-ci.yml 檔案。這個合併請求包含了範本引入與基本配置,開發團隊可以在合併之前檢視變更內容,確認沒有衝突或不符合專案需求的設定。合併這個自動產生的 MR 後,Container Scanning 功能即正式啟用。

進階配置需求可以透過環境變數來實現。GitLab 的安全掃描工具普遍採用環境變數作為組態機制,這種設計保持了配置的靈活性與可維護性。環境變數可以在全域層級或作業層級定義,全域變數適用於整個管線的所有作業,而作業層級變數則只影響特定的掃描作業。對於 Container Scanning 而言,常見的組態需求包括指定要掃描的映像檔位置、設定漏洞嚴重度門檻、啟用或停用語言套件掃描等。

variables:
  CS_IMAGE: "$CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG"
  CS_SEVERITY_THRESHOLD: "high"
  CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN: "false"

include:
  - template: Security/Container-Scanning.gitlab-ci.yml

映像檔位置的指定透過 CS_IMAGE 變數完成。預設情況下,這個變數指向專案 Container Registry 中基於當前分支名稱標記的映像檔。GitLab CI/CD 提供了豐富的預定義變數,例如 $CI_REGISTRY_IMAGE 代表專案的 Registry 路徑,$CI_COMMIT_REF_SLUG 則是經過規範化的分支或標籤名稱。這種動態組合確保了不同分支建置的映像檔都能被正確掃描。如果映像檔存放在外部 Registry,例如 Docker Hub 或私有的 Harbor 伺服器,可以將 CS_IMAGE 設定為完整的映像檔 URL,包含 Registry 位址、命名空間、映像檔名稱與標籤。

嚴重度門檻的設定決定了掃描報告包含哪些等級的漏洞。CS_SEVERITY_THRESHOLD 變數接受的值包括 critical、high、medium、low 等標準嚴重度分類。將門檻設定為 high 意味著只有高危或嚴重等級的漏洞會被納入報告,中低風險的漏洞會被過濾掉。這種設定在處理大型專案時特別有用,因為完整的掃描報告可能包含數百個漏洞項目,其中許多屬於低風險或需要特定攻擊條件才能利用的漏洞。透過門檻設定,團隊可以優先關注最需要處理的高風險問題,避免被過多的低優先級警告淹沒。

語言套件掃描的啟用與停用透過 CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN 變數控制。預設值為 true,代表這項功能是停用的。將其設定為 false 會啟用對語言特定相依套件的掃描。需要注意的是,這會增加掃描時間與資源消耗,且可能與 Dependency Scanning 功能產生重複結果。實務上的建議是維持預設的停用狀態,讓 Dependency Scanning 專責處理應用程式層級的相依套件分析。這種職責劃分不僅避免重複,也讓不同掃描器專注於其最擅長的領域。

容器掃描結果的解讀與處理

當掃描作業完成後,結果會整合到 GitLab 的安全儀表板與漏洞報告介面中。這些介面提供了多層次的資訊檢視,從高階的風險概覽到個別漏洞的詳細資料,協助不同角色的使用者快速掌握專案的安全狀態。專案層級的漏洞報告提供了整體視圖,列出所有已發現的安全問題,包含來自 Container Scanning、Dependency Scanning、SAST 等不同掃描器的結果。這種整合視圖讓安全團隊能夠從全域角度評估風險,識別需要優先處理的關鍵問題。

每個漏洞項目包含豐富的上下文資訊。CVE 編號提供了漏洞的標準識別碼,透過這個編號可以在國家漏洞資料庫或其他安全資訊平台查詢更多技術細節。嚴重度評級採用業界標準的分類,critical 代表可能造成嚴重後果的漏洞,high 表示高風險但可能需要特定條件才能利用,medium 與 low 則代表相對較低的風險等級。漏洞描述說明了安全問題的性質,例如是緩衝區溢位、SQL 注入、權限提升或其他類型的攻擊向量。影響範圍標示了哪些套件版本受到影響,以及是否有已知的攻擊實例或概念驗證程式碼。

@startuml
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

actor "開發團隊" as Dev
participant "CI/CD 管線" as CI
participant "Container Scanning" as CS
database "漏洞報告" as Report
participant "修復作業" as Fix

Dev -> CI: 提交程式碼變更
activate CI

CI -> CI: 建置 Docker 映像檔
CI -> CS: 觸發容器掃描
activate CS

CS -> CS: 解析映像檔結構
CS -> CS: 識別套件版本
CS -> CS: 比對漏洞資料庫
CS -> Report: 產生掃描報告
deactivate CS

Report -> Dev: 通知發現漏洞
Dev -> Report: 檢視漏洞詳情

alt 存在高風險漏洞
    Dev -> Fix: 評估修復策略
    activate Fix
    
    Fix -> Fix: 更新基礎映像檔
    Fix -> Fix: 升級受影響套件
    Fix -> Fix: 套用安全補丁
    
    Fix -> Dev: 提交修復變更
    deactivate Fix
    
    Dev -> CI: 重新觸發建置
else 僅存在低風險漏洞
    Dev -> Dev: 評估風險接受度
    Dev -> Report: 標記例外處理
end

CI -> Report: 更新掃描狀態
deactivate CI

note right of Report
  掃描報告包含內容
  - CVE 編號與連結
  - 嚴重度分級
  - 受影響套件
  - 修復建議
  - 風險評估
end note

@enduml

修復建議是掃描報告中最具實用價值的部分。對於作業系統層級的套件漏洞,最直接的修復方式通常是升級到包含安全補丁的套件版本。掃描工具會檢查是否有可用的更新版本,並建議在 Dockerfile 中明確指定安全的版本號。例如,如果 Alpine Linux 的 openssl 套件存在漏洞,修復建議可能是將 Dockerfile 中的基礎映像檔標籤從 alpine:3.14 更新為 alpine:3.15,或在安裝指令中明確要求特定版本的 openssl。對於無法透過套件升級解決的漏洞,可能需要考慮更換基礎映像檔,或採用其他緩解措施,例如透過 Runtime 安全策略限制容器的能力。

實際案例中,使用十個月前發布的 Alpine Linux 3.14.1 建置的映像檔,掃描結果顯示超過 30 個預設套件存在已知漏洞。這個數字看似驚人,但需要理解的是,並非所有漏洞都具有相同的實際風險。某些漏洞可能需要本機存取權限才能利用,某些則需要特定的服務處於執行狀態,這些在容器化環境中可能並不成立。風險評估需要結合漏洞的技術細節與實際的部署環境來進行。對於無法立即修復的漏洞,可以透過 GitLab 的漏洞管理功能標記為已知風險,並設定處理時程與負責人員。這種追蹤機制確保了安全問題不會被遺忘,同時也提供了風險接受的正式流程。

掃描報告的檢視方式依據使用情境而有所不同。對於預設分支或主要開發分支,安全儀表板提供了最完整的視圖,匯總了所有安全掃描器的發現。這個視圖適合安全團隊進行定期檢查,掌握專案的整體安全態勢。對於功能開發分支或修復分支,合併請求介面會顯示相較於目標分支新增或解決的安全問題。這種差異化檢視讓程式碼審查者能夠快速判斷變更是否引入了新的安全風險,是否符合合併條件。如果掃描發現新的高風險漏洞,合併請求可以被設定為阻擋狀態,要求先行修復後才允許合併。

漏洞的生命週期管理是持續安全的關鍵。發現漏洞只是第一步,後續需要評估、修復、驗證、關閉的完整流程。GitLab 的漏洞追蹤功能提供了狀態管理機制,可以標記漏洞為待處理、進行中、已修復、風險接受等不同狀態。每個漏洞可以指派負責人、設定到期日、新增註解等。這種管理機制確保了安全問題有明確的擁有者與處理時程,避免遺漏或延宕。定期的安全審查會議可以基於這些追蹤資料,討論高風險問題的處理進度,決定風險接受的標準,以及調整安全政策。

開源授權遵循的法律與技術層面

軟體授權是現代開發中經常被低估的重要議題。當專案依賴數十個甚至數百個開源函式庫時,每個函式庫的授權條款都成為專案整體授權的一部分。這些授權條款不僅是法律文件,更反映了軟體作者對其作品使用方式的期望與限制。忽視授權要求不僅可能導致法律糾紛,也違背了開源社群的互惠精神。了解不同授權類型的特性,是建立合規開發流程的第一步。

寬鬆型授權是開源生態系統中最常見的授權類型。MIT 授權以其簡潔性著稱,核心條款僅要求保留原始的授權聲明與版權通知。這意味著使用者可以幾乎不受限制地使用、修改、分發、商業化採用 MIT 授權的軟體,唯一的義務是在分發時保留授權文字。BSD 授權系列與 MIT 類似,主要的變體包括兩條款、三條款與四條款版本,差異在於對於軟體推廣與背書的限制。Apache License 2.0 在寬鬆型授權中較為特殊,除了基本的使用自由外,還包含了明確的專利授權條款與貢獻者協議。這些條款提供了更強的法律保護,降低了專利訴訟的風險。

分享協定授權代表了開源理念中更具限制性的一端。GNU General Public License 及其衍生版本是最著名的分享協定授權。GPL 的核心理念是確保軟體的自由能夠延續,任何基於 GPL 軟體的衍生作品都必須採用相同的 GPL 授權。這種機制確保了一旦軟體進入開源領域,就無法被封閉化。然而,這對於封閉原始碼的商業軟體構成了重大障礙。如果一個商業應用程式使用了 GPL 授權的函式庫,根據授權條款,整個應用程式都必須開源並採用 GPL 授權。這種「傳染性」特質是 GPL 被稱為病毒式授權的原因,雖然這個比喻帶有貶義,但確實反映了其對衍生作品的強制性要求。

@startuml
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

package "開源授權分類體系" {
  
  package "寬鬆型授權" {
    [MIT License] as MIT
    [BSD License] as BSD
    [Apache License 2.0] as Apache
  }
  
  package "分享協定授權" {
    [GPL v2] as GPL2
    [GPL v3] as GPL3
    [AGPL] as AGPL
    [LGPL] as LGPL
  }
  
  package "限制型授權" {
    [軍事限制授權] as Military
    [地理限制授權] as Geo
    [用途限制授權] as Usage
  }
  
}

package "授權相容性分析" {
  [相容性矩陣] as Matrix
  [衝突檢測] as Conflict
  [風險評估] as Risk
}

package "專案授權決策" {
  [允許授權清單] as Allow
  [拒絕授權清單] as Deny
  [例外處理機制] as Exception
}

MIT --> Matrix : 可與大多數授權相容
BSD --> Matrix : 可與大多數授權相容
Apache --> Matrix : 可與大多數授權相容

GPL2 --> Conflict : 要求衍生作品採用 GPL
GPL3 --> Conflict : 要求衍生作品採用 GPL
AGPL --> Conflict : 要求網路服務開源

Military --> Deny : 禁止軍事用途
Geo --> Deny : 特定國家限制
Usage --> Deny : 特定產業限制

Matrix --> Allow : 標記為允許使用
Conflict --> Deny : 標記為禁止使用
Risk --> Exception : 需要法律審查

note right of Matrix
  相容性判斷依據
  - 授權條款限制
  - 專案授權類型
  - 商業使用意圖
  - 分發方式
end note

note bottom of Allow
  授權政策建議
  - 預先定義允許授權
  - 明確列出禁止授權
  - 建立審查流程
  - 定期更新政策
end note

@enduml

AGPL 是 GPL 的網路服務變體,針對軟體即服務的應用場景。傳統的 GPL 僅在軟體分發時觸發開源義務,但如果軟體以網路服務形式提供,例如運行在雲端伺服器上,使用者透過網頁存取,這種情況不構成分發,因此不受 GPL 約束。AGPL 填補了這個漏洞,規定即使軟體以服務形式提供,只要使用者能夠透過網路與其互動,就必須提供原始碼。這對於 SaaS 商業模式構成了更大的限制。LGPL 則是較為寬鬆的變體,允許動態連結而不要求整個專案採用 GPL 授權,這使得 LGPL 函式庫在商業軟體中的使用變得可行。

某些授權包含特定的使用限制,這些限制超越了一般的開源授權範疇。軍事限制條款明確禁止軟體被用於武器系統或軍事目的,這種限制反映了作者的政治或倫理立場。地理限制條款可能禁止特定國家或地區使用軟體,這在國際貿易制裁的背景下偶爾出現。產業限制條款則針對特定的商業領域,例如某些授權禁止在核能產業使用,或限制在博弈產業的應用。這些限制型授權在主流開源社群中相對罕見,但在特定領域或具有強烈意識形態的專案中仍然存在。

授權相容性是管理多重相依套件時必須面對的複雜問題。當專案使用多個不同授權的函式庫時,必須確保這些授權條款之間不存在衝突。例如,MIT 授權的函式庫可以被整合到採用任何授權的專案中,因為 MIT 沒有對衍生作品授權的限制。但如果專案同時使用了 MIT 授權的函式庫 A 與 GPL 授權的函式庫 B,那麼根據 GPL 的要求,整個專案必須採用 GPL 授權。這意味著即使函式庫 A 本身使用寬鬆授權,其在這個專案中的使用也受到了 GPL 的約束。更複雜的情況是不同版本 GPL 之間的相容性,例如 GPLv2 與 GPLv3 在某些情況下並不相容,需要仔細檢查授權條款的具體用詞。

建立授權政策需要多方參與。法務部門需要評估各種授權對公司智慧財產權策略的影響,判斷哪些授權可以接受,哪些必須排除。技術團隊需要了解專案的實際授權需求,評估限制特定授權對技術選型的影響。產品團隊需要考慮商業模式與授權的相容性,確保產品的分發與商業化不會違反授權條款。這種跨部門的協作應該在專案啟動之初就開始,而非等到發現授權衝突時才進行補救。預先建立清晰的授權政策,明確列出允許與禁止的授權類型,可以避免開發過程中的反覆修改與技術債務。

GitLab License Compliance 的實務應用

GitLab 的 License Compliance 功能提供了系統化的授權管理解決方案,從自動化的授權識別到政策執行,涵蓋了授權遵循的完整生命週期。這個功能的核心是授權掃描作業,它會分析專案的相依套件檔案,識別每個套件所採用的授權類型。對於不同的程式語言與套件管理工具,掃描器能夠解析各自的相依性描述檔案,例如 Python 的 requirements.txt 或 Pipfile.lock、Node.js 的 package.json 與 package-lock.json、Ruby 的 Gemfile.lock 等。這種多語言支援確保了在多元技術堆疊的專案中,授權遵循檢查能夠覆蓋所有相依套件。

啟用 License Compliance 功能需要在 CI/CD 配置中引入相應的範本。與 Container Scanning 類似,這個過程透過在 .gitlab-ci.yml 檔案中加入範本引用即可完成。需要注意的是,授權掃描作業需要存取專案的相依套件資訊,因此必須在安裝相依套件之後執行。在典型的 CI/CD 流程中,建置階段會安裝所有相依套件,測試階段進行授權掃描,這樣確保了掃描器能夠存取到完整的相依性清單。

stages:
  - test

include:
  - template: Security/License-Scanning.gitlab-ci.yml

這個基本配置會在測試階段加入授權掃描作業。當管線執行時,掃描器會自動偵測專案使用的程式語言與套件管理工具,讀取對應的相依性檔案,解析每個套件的授權資訊。掃描結果包含了所有識別出的授權類型,以及使用該授權的套件清單。這個資訊為後續的授權政策制定提供了基礎數據。

授權政策的建立是 License Compliance 功能的核心環節。政策定義了組織對不同授權類型的接受度,明確哪些授權是允許的,哪些是禁止的,哪些需要進一步審查。政策的制定應該基於組織的智慧財產權策略、商業模式、法律風險承受度等多重考量。對於計劃以封閉原始碼形式商業化的軟體專案,GPL 系列授權通常會被列入禁止清單。對於內部使用的工具或純粹的開源專案,授權限制可能會更為寬鬆。

@startuml
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

actor "法務團隊" as Legal
actor "技術團隊" as Tech
participant "License Compliance" as LC
database "授權政策庫" as Policy
participant "CI/CD 管線" as CI
participant "合併請求" as MR

Legal -> Policy: 定義授權政策
activate Policy

Policy -> Policy: 建立允許清單
Policy -> Policy: 建立拒絕清單
Policy -> Policy: 設定審查規則

Tech -> CI: 新增相依套件
activate CI

CI -> LC: 觸發授權掃描
activate LC

LC -> LC: 解析相依性檔案
LC -> LC: 識別套件授權
LC -> Policy: 比對授權政策

alt 使用允許授權
    LC -> MR: 標記為合規
    MR -> Tech: 允許合併
else 使用拒絕授權
    LC -> MR: 標記為違規
    MR -> MR: 阻擋合併
    MR -> Tech: 要求移除套件
    Tech -> Tech: 尋找替代方案
    Tech -> CI: 更新相依套件
else 使用未分類授權
    LC -> MR: 標記為待審查
    MR -> Legal: 通知需要審查
    Legal -> Legal: 評估法律風險
    Legal -> Policy: 更新政策
    Policy -> LC: 重新評估合規性
end

deactivate LC
deactivate CI
deactivate Policy

note right of Policy
  授權政策內容
  - 允許授權清單
  - 拒絕授權清單
  - 審查流程定義
  - 例外核准機制
  - 更新週期規範
end note

note left of MR
  合併請求檢查項目
  - 新增授權識別
  - 政策合規驗證
  - 風險等級評估
  - 審查狀態追蹤
end note

@enduml

授權政策的管理介面位於專案的「Security & Compliance」區域。在「License Compliance」頁面的「Policies」標籤中,可以檢視當前的政策設定,新增或修改授權的分類。GitLab 支援數百種開源授權的識別,覆蓋了絕大多數常見的授權類型。對於每個授權,可以設定為允許、拒絕或無分類三種狀態。允許狀態表示該授權符合組織政策,使用該授權的套件不會觸發任何警告或阻擋。拒絕狀態則相反,任何使用被拒絕授權的套件都會被視為違規,合併請求會被自動阻擋。無分類狀態適用於尚未評估或較為罕見的授權,這些授權需要人工審查才能決定是否接受。

一個實務上的重要細節是,授權政策的編輯需要先執行至少一次授權掃描作業。這是因為 GitLab 需要先識別專案中實際使用的授權類型,才能提供完整的授權清單供管理。在首次啟用 License Compliance 功能後,應該先觸發一次管線執行,等待掃描完成並產生授權報告,之後才能在政策介面中看到可編輯的授權清單。這個設計避免了在沒有實際數據的情況下盲目建立政策,確保政策是基於專案實際情況制定的。

授權掃描的結果檢視方式與容器掃描略有不同。對於預設分支,授權資訊顯示在「Security & Compliance」下的「License Compliance」頁面。這個頁面列出了所有識別出的授權,以及使用每種授權的套件清單。每個授權項目會標示其當前狀態,例如允許、拒絕或未分類。對於功能開發分支,授權資訊會顯示在該分支管線的詳細頁面中,特別是「Licenses」標籤。這個檢視會比較功能分支與目標分支的授權差異,突顯新增的授權類型,讓程式碼審查者能夠快速識別潛在的授權風險。

合併請求的自動阻擋是 License Compliance 功能最強大的執行機制。當開發人員在功能分支中引入了新的相依套件,而該套件使用被拒絕的授權時,對應的合併請求會進入阻擋狀態。GitLab 會在合併請求頁面顯示明確的警告訊息,說明哪些套件違反了授權政策,並停用合併按鈕以防止程式碼合併。這種即時的回饋機制確保了不合規的相依套件無法進入主分支,從源頭控制了授權風險。開發人員必須移除違規套件或尋找使用允許授權的替代方案,才能解除合併阻擋。

授權政策的例外處理機制提供了必要的彈性。在某些情況下,可能需要使用特定的套件,即使其授權不在允許清單中。這可能是因為技術上沒有可行的替代方案,或該套件的使用方式不會觸發授權限制。GitLab 的核准規則功能可以用於處理這類例外情況。透過定義特定的核准規則,例如 License-Check,可以指定特定人員有權核准被授權檢查阻擋的合併請求。這些核准者通常是法務人員或資深技術領導,他們有足夠的知識與權限來評估風險並決定是否接受例外。當核准者批准合併請求後,授權阻擋會被解除,程式碼可以正常合併。

授權政策應該是動態演進的,而非一次設定後就永不更改。隨著組織業務的發展、技術堆疊的變化、開源授權的演進,授權政策需要定期檢視與更新。新的授權類型可能出現,現有授權的法律解釋可能改變,商業策略的調整可能影響授權接受度。建立定期的政策審查機制,例如每季度或每半年由法務與技術團隊聯合檢視授權政策,討論是否需要調整允許或拒絕清單。這種持續改進的方法確保了授權遵循策略與組織需求保持一致。

License Compliance 功能的價值不僅在於技術實現,更在於它將授權管理從被動的事後檢查轉變為主動的預防機制。透過在 CI/CD 流程中整合授權掃描,每次程式碼變更都會自動進行授權檢查,開發人員能夠即時得到回饋。透過授權政策的明確定義,組織的法律要求轉化為可執行的技術規則。透過合併請求的自動阻擋,不合規的程式碼無法進入主分支。這種系統化的方法顯著降低了授權違規的風險,保護了組織的智慧財產權,也維護了對開源社群的法律義務。

整合安全掃描與授權遵循的完整策略

建立完整的容器安全與授權遵循體系,需要將各個獨立的掃描工具整合為協調運作的防護機制。這種整合不僅是技術層面的配置整合,更是流程、文化、組織結構的系統性變革。DevSecOps 的理念強調將安全融入開發流程的每個環節,而非作為獨立的事後檢查階段。實現這個理念需要自動化工具的支援,也需要開發團隊對安全議題的認知與承諾。

CI/CD 管線的設計應該將安全掃描視為必要的品質門檻,而非可選的附加步驟。在典型的管線流程中,建置階段產生應用程式構件與容器映像檔,測試階段執行單元測試與整合測試,安全掃描應該在測試階段同步進行。Container Scanning 檢查映像檔的作業系統與系統套件,Dependency Scanning 分析應用程式的相依套件,SAST 掃描原始碼中的安全漏洞,License Compliance 驗證授權遵循。這些掃描作業可以平行執行以節省時間,也可以依據優先級序列執行以更快地發現關鍵問題。

stages:
  - build
  - test
  - security
  - deploy

build_image:
  stage: build
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG

unit_tests:
  stage: test
  script:
    - pytest tests/

container_scanning:
  stage: security
  needs: ["build_image"]

dependency_scanning:
  stage: security
  needs: ["build_image"]

license_compliance:
  stage: security
  needs: ["build_image"]

include:
  - template: Security/Container-Scanning.gitlab-ci.yml
  - template: Security/Dependency-Scanning.gitlab-ci.yml
  - template: Security/License-Scanning.gitlab-ci.yml

這個配置展示了如何將多個安全掃描工具整合到統一的管線中。建置階段產生 Docker 映像檔並推送到 Registry,測試階段執行功能驗證,安全階段同時進行容器掃描、相依套件掃描與授權掃描。透過 needs 關鍵字定義作業間的依賴關係,確保安全掃描在映像檔建置完成後才執行。這種結構化的管線設計讓安全檢查成為發布流程的內建環節,而非獨立的手動步驟。

安全掃描的結果應該直接影響程式碼的合併決策。GitLab 提供了合併請求核准規則,可以根據掃描結果自動阻擋或要求額外核准。例如,可以設定規則要求容器掃描未發現高危漏洞才允許合併,或要求授權掃描通過才能合併到主分支。這些規則的設定需要在自動化執行與開發效率之間找到平衡。過於嚴格的規則可能導致大量合併請求被阻擋,影響開發速度。過於寬鬆的規則則無法有效防護安全風險。實務上的建議是針對關鍵或嚴重等級的問題設定強制阻擋,對於中低風險問題設定警告但允許合併,並透過定期的安全審查追蹤這些待處理問題。

安全度量與持續改進是長期維護安全態勢的關鍵。GitLab 的安全儀表板提供了多維度的安全指標,包括發現的漏洞總數、不同嚴重度的分布、修復所需的平均時間、授權合規率等。這些指標不僅反映了當前的安全狀態,也揭示了安全流程的效能。例如,如果發現漏洞後的平均修復時間過長,可能表示團隊缺乏安全知識或修復流程存在瓶頸。如果特定類型的漏洞反覆出現,可能需要加強對應領域的安全培訓或改進程式碼審查標準。透過定期分析這些指標,可以識別改進機會,逐步提升組織的安全成熟度。

教育與培訓是技術工具之外的重要投資。開發人員需要理解為什麼安全重要,如何解讀掃描報告,以及如何正確修復安全問題。單純的工具部署不足以建立安全文化,還需要透過培訓、工作坊、內部分享等方式,提升團隊的安全意識與技能。對於授權遵循,更需要跨部門的協作與溝通。開發團隊需要了解不同授權的法律意涵,法務團隊需要理解技術實施的限制,產品團隊需要考慮授權對商業模式的影響。建立定期的跨部門會議,討論安全與合規議題,分享最佳實踐,解決實際問題,是培養協作文化的有效方式。

容器安全與授權遵循不是一次性的專案,而是持續的實踐。技術環境不斷演進,新的漏洞持續被發現,授權規則可能隨時間改變。保持掃描工具的更新,定期審查安全政策,持續優化 CI/CD 流程,是維護長期安全態勢的必要投入。透過將安全與合規嵌入開發流程,透過自動化減少人為疏失,透過指標追蹤持續改進,可以建立起可靠的軟體供應鏈安全防護體系,在快速創新與風險控制之間取得平衡。

玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。