開源軟體於PolicyAsCode中之角色與應用

– 13 分鐘閱讀

開源軟體的成本效益和社群支援使其成為Policy as Code專案的理想選擇，然而，安全性風險、授權許可和缺乏官方支援等挑戰也需要審慎評估。選擇開源軟體時，除了考量功能性，還需評估其安全性、活躍度和社群支援度，並搭配OpenSSF Scorecard等工具進行安全性評估。此外，建立明確的授權許可管理流程和內部技術支援能力，才能有效降低風險並確保專案順利進行。

開源軟體在Policy as Code中的關鍵角色

在探討Policy as Code（PaC）的實踐過程中，開源軟體（Open Source Software, OSS）扮演著舉足輕重的角色。本篇文章將深入分析採用OSS的優勢與挑戰，並探討如何在PaC專案中有效地利用OSS。

為何採用開源軟體

採用OSS具有多項顯著優勢。首先，OSS能夠提供潛在的成本文省。許多組織利用OSS專案和函式庫來減少整體開發工作量。由於他人已經編寫並測試了這些程式碼，若能滿足需求，則無需重複造輪子。在其他條件相同的情況下，使用OSS可以加快開發速度，通常意味著成本的降低。

其次，成熟的OSS專案往往擁有龐大的維護者和貢獻者社群。這意味著有更多的開發者關注該專案，並且貢獻來自不同背景和觀點。這種多元化的參與提高了專案的穩定性和安全性。OSS專案的維護者負責引導專案方向，而貢獻者則提供建議和潛在的改進，從而增強了專案的有效性。

開源軟體的優勢

  1. 成本文省：減少重複開發，降低整體成本。
  2. 多元化的貢獻：更多的開發者參與，提高了程式碼的品質和安全性。
  3. 更快的開發速度：利用現有的OSS專案，加速開發流程。

開源軟體的挑戰

儘管OSS具有眾多優勢，但也存在一些不可忽視的挑戰。首先，缺乏官方支援是OSS的一大缺點。雖然許多OSS維護者和貢獻者樂於為社群提供支援，但他們通常有自己的正職工作，這限制了他們對支援請求的回應速度。對於習慣於企業級支援協定或需要確定性回應時間的組織來說，這可能是一個問題。

其次，使用者對OSS專案的控制權有限。當你不是專案的維護者時，你無法完全控制專案的發展方向。雖然你可以透過貢獻程式碼或提供反饋來影響專案，但最終的決定權仍在維護者手中。

最後，風險管理是另一個需要考慮的問題。根據OWASP最近發布的《開源軟體前10大風險》和Synopsys的《開源安全與風險分析報告》，許多OSS專案存在安全風險。例如，89%的程式碼函式庫包含超過四年未更新的OSS元件，91%的程式碼函式庫包含超過兩年未進行新開發的元件。

  graph LR
    A[採用開源軟體] --> B[優勢]
    A --> C[挑戰]
    B --> D[成本文省]
    B --> E[多元化貢獻]
    C --> F[缺乏官方支援]
    C --> G[控制權有限]
    C --> H[風險管理]

圖表翻譯：

此圖示展示了採用開源軟體的主要優缺點。其中優勢包括成本文省和多元化的貢獻，而挑戰則涵蓋了缺乏官方支援、控制權有限以及風險管理等導向。

開源軟體的使用與維護

為了有效地利用OSS，需要注意以下幾個方面：

  1. 授權許可：確保所選用的OSS專案具有符合需求的授權許可。大多陣列織都有開源計畫辦公室（Open Source Program Office, OSPO）來定義可內部使用的授權型別。

  2. 安全性：評估OSS專案的安全性設計。OpenSSF Scorecard是一個用於評估OSS專案安全性的工具。

如何在Policy as Code中有效利用開源軟體

要在PaC專案中有效利用OSS，關鍵在於選擇具有持續發展動能和活躍社群的專案。這樣的專案能夠持續解決新的問題，並提供所需的更新和整合。同時，組織需要建立合適的風險管理機制，以應對OSS可能帶來的挑戰。

def evaluate_oss_project(project_url):
    """
    評估開源軟體專案的安全性和活躍度。
    
    :param project_url: 開源軟體專案的URL
    :return: 包含安全性評估和活躍度的字典
    """
    # 檢查專案安全性
    security_score = check_security(project_url)
    
    # 檢查專案活躍度
    activity_level = check_activity(project_url)
    
    return {
        "security_score": security_score,
        "activity_level": activity_level
    }

def check_security(project_url):
    # 使用OpenSSF Scorecard評估專案安全性
    # 省略具體實作細節
    pass

def check_activity(project_url):
    # 檢查專案的更新頻率和社群參與度
    # 省略具體實作細節
    pass

#### 內容解密：
evaluate_oss_project函式用於評估指定開源軟體專案的安全性和活躍度。它首先呼叫check_security函式來檢查專案的安全性，然後呼叫check_activity函式來評估專案的活躍度。最後，它傳回一個包含安全性評估和活躍度的字典。
此函式展示瞭如何系統性地評估開源軟體專案，以確保其符合組織的需求和安全標準。

總之，開源軟體在Policy as Code中扮演著關鍵角色。透過充分了解其優勢與挑戰，並採取適當的使用和維護策略，組織可以在PaC專案中有效地利用OSS，從而提高開發效率、降低成本並增強系統安全性。

隨著開源軟體的不斷發展，其在Policy as Code領域的應用前景將更加廣闊。未來，我們可以期待更多創新性的開源工具和解決方案出現，以滿足日益增長的安全和管理需求。

因此，持續關注開源社群的發展動態，並積極參與到相關專案中，將有助於組織更好地把握技術趨勢，提升自身的競爭力。

結語

總而言之，開源軟體在Policy as Code中的應用不僅能夠帶來諸多實質性的好處，同時也伴隨著一定的挑戰。透過謹慎選擇合適的開源專案，並採取有效的風險管理措施，組織可以在享受開源軟體帶來的好處的同時，將潛在風險降至最低。未來，我們應繼續關注開源領域的發展，並積極探索其在更多場景下的應用潛力。

開源軟體採用考量因素與政策即程式碼的整合

在企業環境中使用開源軟體（OSS）時，需要考慮多項重要因素以確保軟體的安全性、可靠性和可維護性。這些考量因素與組織的政策即程式碼（PaC）實踐密切相關。

開源軟體成熟度評估

評估開源軟體專案的成熟度是採用前的關鍵步驟。主要評估指標包括：

  1. 專案活躍度：檢查專案的貢獻頻率、最後一次更新時間和貢獻者數量。

    • 定期貢獻是專案持續發展的良好指標。
    • 最近的更新表明專案仍在積極維護。

  2. 版本發布情況：檢查專案的版本發布歷史和穩定性。

    • 穩定版本（GA）的存在表明專案已達到一定的成熟度。

  3. 錯誤和功能請求處理速度：瞭解專案對錯誤報告和功能請求的回應速度。

    • 快速回應和修復是專案健康運作的跡象。

  4. 變更管理機制：檢查專案如何處理變更，包括破壞性變更的處理方式。

    • 清晰的變更日誌和預警機制有助於使用者適應變更。

相關依賴管理

開源軟體專案通常依賴其他開源或商業軟體。有效的依賴管理至關重要：

  1. 依賴檔案化：檢查專案是否清晰記錄了所有依賴項。

    • 檔案化的依賴有助於風險評估和合規檢查。

  2. 依賴安全性：評估依賴項的安全性風險。

    • 使用工具定期掃描依賴項中的已知漏洞。

支援與維護能力

企業需要評估自身對開源軟體的支援和維護能力：

  1. 內部技術能力：評估團隊是否具備相關技術背景，能夠審查和維護開源軟體。

    • 團隊熟悉度直接影響軟體的可維護性。

  2. 正式支援協定：考慮是否需要與第三方供應商簽訂正式支援協定。

    • 商業支援可以提供額外的安全保障。

專案發展方向

瞭解開源軟體專案的發展方向對於企業採用至關重要：

  1. 專案路線圖：研究專案未來的發展計劃。

    • 確保專案方向符合企業需求。

  2. 使用案例匹配度：評估企業的使用場景是否符合專案的主要使用案例。

    • 主流使用案例通常獲得更好的支援。

組織內部管理機制

企業應具備管理開源軟體資產的能力：

  1. 資產管理系統：建立系統來儲存、管理分發開源軟體元件。

    • 確保元件的安全性和可靠性。

  2. 漏洞掃描工具：使用專業工具監測和檢測開源軟體中的漏洞。

    • 定期掃描有助於及時發現和修復安全問題。

開源軟體的管理與支援

對於關鍵的開源軟體專案，企業可以考慮提供支援：

  1. 貢獻程式碼：直接向專案貢獻程式碼，改進功能或修復錯誤。

    • 貢獻程式碼有助於建立良好的合作關係。

  2. 贊助專案或貢獻者：透過贊助的方式支援重要的開源專案或貢獻者。

    • 財務支援是對開源社群的回饋。

開源專案辦公室（OSPO）的作用

許多大型企業設立了開源專案辦公室（OSPO），以更好地管理和使用開源軟體。OSPO的主要職責包括：

  1. 提供指導和最佳實踐：OSPO可以為企業內部的開源軟體採用提供專業指導。

    • 利用OSPO的經驗可以避免常見陷阱。

  2. 風險管理：OSPO協助企業管理使用開源軟體的相關風險。

    • 風險管理的專業性有助於企業做出更明智的決策。

標準與控制措施的整合

企業通常制定嚴格的標準和控制措施來確保資訊安全和合規性。這些標準通常來源於行業最佳實踐，例如來自雲安全聯盟（CSA）、網際網路安全中心（CIS）和美國國家標準與技術研究院（NIST）的。

控制可追溯性矩陣示例

| 標準焦點區域 | ID | 控制措施 | 狀態 |
| --- | --- | --- | --- |
| 資訊安全-雲端運算 | ISCC-1 | 防止公有IP位址分配給運算資源 | 已核准 |
| 資訊安全-雲端運算 | ISCC-2 | 防止NAT與私有子網路關聯 | 開發中 |

政策即程式碼（PaC）的實施

企業透過PaC來實施標準和控制措施，將政策轉化為可執行的程式碼。具體步驟包括：

  1. 定義控制措施：與GRC（治理、風險和合規）團隊合作定義具體的控制措施。

    • 控制措施必須符合組織標準。

  2. 實施PaC：使用PaC工具實作這些控制措施，並生成可稽核的日誌和報告。

    • PaC自動化了合規檢查，提高了效率。

  3. 稽核與驗證：利用PaC生成的稽核工件，向GRC和管理階層證明控制措施的有效性。

    • 可稽核性增強了透明度和信任度。

策略追溯性與焦點金字塔模型

下圖展示了從組織政策到具體PaC政策的追溯性和焦點收斂過程：

  graph TD
    A[組織政策] --> B[行業標準]
    B --> C[具體控制措施]
    C --> D[PaC實施]
    D --> E[可稽核結果]

圖表翻譯：

此圖示展示了從廣泛的組織政策到具體的PaC實施之間的層級關係和焦點轉移過程。每一層都將高層次的要求逐步細化為可執行的技術控制措施，最終產生可稽核的結果用於驗證合規性。

內容解密：

本章節詳細闡述了企業在採用開源軟體時需要考慮的多個關鍵因素，以及如何將這些因素與組織的政策即程式碼實踐相結合，以確保安全性和合規性。透過對開源軟體成熟度、依賴管理、內部技術能力等方面的評估，企業能夠更好地管理相關風險。同時，文中介紹了開源專案辦公室（OSPO）的作用以及如何利用PaC實作標準和控制措施的自動化，最終達到提升企業整體安全性和合規性的目標。

策略即程式碼（Policy as Code）：改變我們對程式碼的利用方式

在過去幾年中，我們見證了一場與IT資源的供應和使用方式相關的變革：我們正在向**一切皆程式碼（Everything as Code, EaC）的方向邁進。許多我們現在用來供應、變更或驗證IT資源的流程，都使用-as-code（某某即程式碼）的構件（artifacts）。對於我們許多人來說，等待數周或數月才能獲得計算資源的日子已經過去了。現在，我們只需透過應用基礎設施即程式碼（Infrastructure as Code, IaC）**構件（如JSON或YAML，甚至是Terraform計畫），透過我們的公有或私有雲端服務，就可以輕鬆獲得所需的資源。我們甚至可以使用像Tinkerbell這樣的工具來供應裸機資源。

雖然通常仍有控制檯可用於供應資源，但使用IaC使我們能夠像管理應用程式碼一樣管理基礎設施資源。我們現在使用原始碼管理（Source Code Management）工具，以及持續整合（Continuous Integration, CI）工具，甚至是GitOps，來管理和應用基礎設施。雖然我們通常以宣告式的方式應用IaC，但現在我們甚至已經模糊了**命令式（imperative）和宣告式（declarative）之間的界限，並透過像Amazon Web Services（AWS）的雲端開發套件（Cloud Development Kit, CDK）或HashiCorp的Terraform雲端開發套件（Cloud Development Kit for Terraform, CDKTF）**這樣的工具將兩者結合起來。

無論你正在做什麼或使用什麼，如果你能夠透過程式碼來完成，那麼你就能獲得多項實質的好處，而這些好處在手動執行任務時是無法獲得的。例如，你可以利用由集中式原始碼管理提供的單一事實來源（Single Source of Truth, SSOT）。你還可以利用EaC提供的協作機會。這些工具和流程經過多年的原始碼管理已經變得非常成熟。

使用和佈署程式碼形式的構件可以提高可重複性，因為自動化流程減少了整合和佈署之間的變異性；由於構件和佈署是程式碼，能被底層系統理解，因此具有確定性行為的可擴充套件性也得到了改善。

策略即程式碼在一切皆程式碼中的應用

原始碼管理和CI工具提供自動化管理你的**-as-code（某某即程式碼）**構件。你可以自動化測試以及原始碼掃描。透過自動化測試和PaC，你將策略應用於程式碼，以在允許合併之前評估變更。更多的自動化帶來更快的問題檢測，並允許你更快地失敗和成功，結果更加確定。換句話說，你獲得了更多的可重複性和可再現性——正如我之前所說，更少的意外通常是件好事。

程式碼範例：使用 PaC 進行變更評估

def evaluate_change(change, policy):
    if policy.validate(change):
        print("Change is compliant with the policy.")
    else:
        print("Change violates the policy.")

# 假設 Change 和 Policy 是定義好的類別
change = Change(attributes={"author": "John Doe", "lines_added": 10})
policy = Policy(rules=[{"attribute": "author", "expected": "John Doe"}])

evaluate_change(change, policy)

內容解密：

此範例展示了一個簡單的變更評估函式，它接受一個變更和一個策略作為輸入，並根據策略驗證變更。如果變更符合策略，則輸出「變更符合策略」。否則，輸出「變更違反策略」。此範例中使用了假設的 Change 和 Policy 類別，分別代表變更和策略。

將PaC應用於你的原始碼也有助於你實作合規即程式碼（Compliance as Code, CaC）。透過CaC，合規策略被用作測試，通常在CIPipeline中使用，以在允許下游變更之前驗證**-as-code（某某即程式碼）**構件。

CaC 和 SaC 使用 PaC 的流程

  graph LR;
    A["EaC 構件"] --> B["PaC 評估"];
    B --> C["CaC 驗證"];
    B --> D["SaC 驗證"];
    C --> E["合規檢查"];
    D --> F["安全檢查"];
    E --> G["允許合併"];
    F --> G;
    G --> H["佈署"];

此圖示展示了 CaC 和 SaC 如何使用 PaC 對 EaC 構件進行策略評估和驗證。

圖表翻譯： 此圖表呈現了 EaC 構件如何透過 PaC 評估進行 CaC 和 SaC 驗證。首先，EaC 構件被提交給 PaC 評估，接著進行 CaC 和 SaC 驗證。只有當 EaC 構件透過了合規檢查和安全檢查後，才會被允許合併並佈署到生產環境中。

策略引擎與語言

作為PaC解決方案的一部分，策略引擎透過解釋策略語言和評估資料來完成繁重的工作。根據Bruce A. Fette在他的書《認知無線電技術，第二版》（學術出版社）中的說法，「策略引擎是一個能夠讀取機器可讀的策略並將其應用於特定問題領域以約束網路資源行為的程式或過程。」

我喜歡這個定義，因為它揭示了我認為正確描述PaC策略引擎的三個特徵：

  • 讀取機器可讀的策略（PaC）
  • 將策略應用於特定的問題領域（資料）
  • 約束行為（結果）

策略引擎評估流程圖

  graph TD;
    A["開始評估"] --> B["讀取策略"];
    B --> C["讀取資料"];
    C --> D["匹配檢查"];
    D -->|匹配| E["評估資料"];
    D -->|不匹配| F["傳回錯誤或空值"];
    E --> G["產生結果"];
    F --> G;
    G --> H["結束評估"];

此圖表展示了一個典型的策略引擎評估流程。

圖表翻譯： 此圖表詳細描述了策略引擎的評估過程。首先，策略引擎讀取相關的策略和資料，接著進行匹配檢查。如果資料與策略匹配，則進行資料評估；如果不匹配，則傳回錯誤或空值。最終，根據評估結果產生相應的輸出。

一個策略引擎讀取要用於評估的策略、要被評估的資料以及要使用的查詢。然後，策略引擎根據提供的策略評估提供的資料，並產生一個答案，供整合或服務該策略引擎的系統使用。策略是以與它們評估的資料相匹配的方式編寫的；此外，這種匹配發生在策略評估資料之前和任何輸入處理（如解析）之後。

玄貓

玄貓

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