OSS-RISK-1: Known Vulnerabilities in Dependencies

此類風險意指開源元件已經在 CVE 或其他通路被揭露具備弱點，但工控系統仍持續使用這些含漏洞的版本且無法及時修補，最終讓攻擊者利用「已知弱點」進行滲透。

常見的實際情況:

在工業控制系統與關鍵基礎設施的情境中，軟體一經上線往往長期運行；若為避免高昂的停機維護成本而延後升級計畫，先前已經揭露的漏洞便可能長期存在並持續帶來潛在風險。由於生產線或基礎設施若停擺，往往會遭受重大的經濟與社會衝擊，因此管理階層多半在風險與營運考量之間權衡，進而暫緩修補已知的弱點。

可應對方式:

若在短期內無法停機或處理相容性問題，可先採用網段隔離、防火牆策略及入侵偵測工具等方法，局部阻擋可能的攻擊向量作為補償性控制。之後，可於離線或測試環境中驗證更新程式的功能與相容性，再利用維護時段完成正式修補。同時，也可以在企業層面導入自動化或半自動化的漏洞掃描與版本盤點流程，及早偵測並控管所有已知漏洞，進一步減少系統暴露風險。

OSS-RISK-2: Compromise of Legitimate Package

此風險在於開源專案或其散佈管道被駭客入侵，導致原本「合法」的套件在最新版本中被植入惡意程式，進一步讓使用者在更新時毫無防備地將惡意程式帶入系統。

常見的實際情況:

工控系統由於作業週期長且多仰賴供應商固定提供的更新版本，一旦官方檔案庫或維護者帳號遭到駭入，下游便可能大規模受到影響。過往也曾出現維護者帳號被盜用或套件檔案庫遭到駭入的案例，讓原本安全的專案成為攻擊跳板，且受害者在初期常不自知。

可應對方式:

每次下載更新檔案時，先進行數位簽章（驗證真實性）或雜湊值（檢查完整性）比對，避免在未經檢驗的情況下直接套用「官方更新」。若條件許可，也可導入離線檢測流程或檔案比對機制。供應鏈安全稽核同樣不可忽視，可要求供應商採用多因子驗證、嚴謹的版本管理與安全審查，以降低供應商階段就遭植入惡意程式的風險。

OSS-RISK-3: Name Confusion Attacks

駭客利用與常見套件或函式庫名稱高度近似的手段（例如 typosquatting、brand-jacking），在使用者下載或安裝時造成混淆，最終讓惡意元件被誤以為是官方版本。

常見的實際情況:

開發環境裡，工程師與外包廠商有時候基於習慣或者時間考量，僅透過關鍵字搜尋來定位開源套件；若名稱只差一字或發音類似，容易在匆促中下載錯誤的惡意版本，無意間將其導入生產系統核心區域。

可應對方式:

企業內部可建置受控檔案庫或鏡像系統，集中管理經過稽核的開源套件。不論新安裝或升級，都須經過離線比對程序，核對維護者帳號、專案文件與社群活躍度等資訊，確保所下載的版本確為官方專案。此作法有助於降低名稱混淆攻擊在工控環境中的危害。

OSS-RISK-4: Unmaintained Software

若部分開源元件或其特定版本已停止維護，一旦發生功能缺陷或安全漏洞，也不會再獲得官方修補，長期下來導致風險不斷累積。

常見的實際情況:

工控系統往往運作數年或甚至十數年，若核心函式庫或驅動程式在此期間遭到社群或維護者棄養，當後續發生漏洞時便無法及時獲得修補。過去不乏專案因維護度不足而令下游廠商得自力修補或整體替換，帶來高昂的技術與管理挑戰。

可應對方式:

在設計或採購階段可優先選擇具有長期支援（LTS）或維護週期明確的開源專案。若發現已導入的元件缺乏維護度，則可在社群中尋求替代方案，或於企業內 fork 該專案並持續維護必要功能。同時可在內部實施活躍度檢測並預留足夠安全資源，以應對可能的替換或增修需求。

OSS-RISK-5: Outdated Software

系統長期使用上游已釋出更新版本或安全修補的舊版軟體，卻未能及時升級，導致在舊版本中持續累積已知漏洞與相容性風險。

常見的實際情況:

工控環境向來對穩定度以及可用性高度重視，因此企業常因顧慮升級帶來的營運中斷或者相容性問題而停留在老舊版本。上游雖然持續推出新功能與安全修補，但若下游遲遲不更新，就會堆積大量潛在漏洞，最後在重大事故或系統崩潰時面臨更大的升級難題。

可應對方式:

企業層面可透過 SBOM 定期盤點所有關鍵開源套件版本，並視離線測試結果評估小幅或大幅升級策略。先在沙箱或測試環境檢驗相容，確保在生產中實施時能降低風險。此有計畫的升級方式有助於平衡系統安全與功能可用性，免於被動面對嚴重事故。

OSS-RISK-6: Untracked Dependencies

系統中可能存在經由非標準或間接管道加入的開源套件，開發與維運人員並不知情，無法評估與監控其潛在漏洞或合規風險。

常見的實際情況:

在工控系統的建置與維運過程中，常會因不同功能需求而採用「客製化的驅動程式（custom driver）」、「特定協定介面的程式庫（protocol interface）」或「外包開發團隊撰寫的附加程式碼」，這些都屬於可能由第三方或內部自行打造、非標準管道安裝的軟體元件。若未在軟體物料清單（SBOM）中妥善記錄，便無法使用一般的掃描工具加以偵測，也就無法及時掌握這些元件是否存在漏洞。結果是，一旦某個元件出現安全缺陷，就可能在毫無防備的情況下被引入工廠的生產核心，對整體系統造成潛在風險。

可應對方式:

可從合約與管理流程著手，要求供應商與內部團隊提供並定期更新 SBOM，並採用多種掃描工具（如 FOSSology、Dependency-Check）進行交叉比對，將所有直接或間接依賴統一列入安全報告。一旦發現未被控管的隱藏套件，應立即評估其維護度與授權合規性，並迅速納入正常維運機制，避免成為潛在危害。

OSS-RISK-7: License and Regulatory Risk

開源套件的授權條款或法規相容性若與企業商業模式、產業法規互相衝突，可能引發法律與合規疑慮。若缺乏明確授權，企業亦有可能面臨侵權訴訟風險。

常見的實際情況:

有些開源專案未標示清晰授權，或帶有不適用於工控領域的約束條款，企業在未審查下便導入系統後，若之後牽涉政府採購、出口管制或客戶合約等，恐怕引發重大法規合規風險，也可能因授權爭議被迫中斷使用。

可應對方式:

宜依循 OpenChain ISO/IEC 5230 等標準建立開源合規流程，並結合自動化工具檢測各套件的授權細節，及早排除不明或衝突的元件。亦可在供應商合約條款中規範開源合規責任，要求合作廠商對所採用的套件負起授權符合性義務，避免未來出現版權糾紛或法規違規的狀況。同時也可參考 OpenChain ISO/IEC 18974 開源資安國際標準，以確保在工控環境中導入開源軟體時，兼顧更全面的資安風險管控。

OSS-RISK-8: Immature Software

不成熟的開源專案往往缺乏完善的測試、版本控管和程式碼審核，程式品質與安全性因此無法得到保證，一旦在高負載或特定情境下運行，可能導致崩潰或重大漏洞。

常見的實際情況:

工控環境對系統穩定度要求極高，若選用功能仍不穩定或缺乏安全檢核的新興套件，生產線在面臨高負載或意外情況時可能出現大範圍停工或設備危害。許多處於早期階段的開源專案尚未建立足夠的測試覆蓋率與審核機制。

可應對方式:

在正式導入前，可先於離線環境進行壓力測試、靜態程式碼掃描、已知弱點掃描或模糊測試，並針對高風險環境額外實施滲透測試，以評估各種可能的攻擊向量。此外，也需觀察專案的社群維護度、版本釋出頻率與程式碼審核流程，以及是否已在 CI/CD 或 DevOps 中整合測試程式，綜合判斷該工具是否符合工控領域所需的穩定度與安全門檻。若評估結果顯示該專案尚未達到成熟標準，可考慮採用其他更完善的替代方案，或投入更多資源強化其測試體系，確保能滿足工控環境的要求。

OSS-RISK-9: Unapproved Change (Mutable)

若開源元件的下載方式無法確保版本已固定或透過安全通道進行傳輸，駭客可能在過程中竄改檔案，使最終導入的程式碼與預期不符，導致系統潛在安全風險。

常見的實際情況:

工控系統對版本變動相當敏感，但若開發人員或工程師透過 HTTP 或動態無版本連結下載更新檔，極有可能在毫無警覺的狀態下接收被調包的檔案。這種「未經批准的變更」若進入生產核心區域，將成為難以溯源的安全隱患。

可應對方式:

企業應明訂相關規範，禁止使用 HTTP 或動態 URL 下載開源元件，並強制所有檔案必須具備版本標記、雜湊值驗證或者數位簽章，經測試環境驗收後方可投入生產。同時，需結合完善的變更管理、紀錄制度與組態管理機制，將檔案來源、對應版本、雜湊值與審核意見完整備查，確保在發生異常時能夠迅速追蹤並釐清責任歸屬。

OSS-RISK-10: Under/over-sized Dependency

無論是功能少的套件還是龐大的函式庫，都可能出現規模不成比例的安全與維護風險。前者若維護者帳號遭駭，所有下游使用者都難以倖免；後者若包含許多不必要的功能模組，則會擴大攻擊面並增加潛在漏洞。

常見的實際情況

部分小型專案僅有極少數開發者維護，一旦作者停止維護或帳號被駭，就會大面積波及所有下游使用者。另有一些大型函式庫在工控場景下實際只用到極小部分功能，卻同時承擔其餘模組的安全風險。這種規模失衡常使系統維運的複雜度不斷提升。

可應對方式:

可落實『最小功能原則』，在工控系統中只導入真正需要的功能，避免隨意堆疊過度微小或體量龐大的套件。若預期必須整合大型函式庫，可透過分層網路與功能隔離，將不必要或高風險模組置於次要區域。同時，若能自行開發輕量功能或選擇維護度更佳的替代方案，也有助於降低維運與安全管理上的負擔。

總結：面向工控的開源供應鏈安全

綜觀而言，OWASP 所歸納的這十大風險在工控（OT/ICS）環境中格外明顯。由於系統週期長、穩定度與合規要求嚴苛，任何開源元件若管理不當或包含漏洞，都可能造成大規模停工或公共安全風險。為應對上述挑戰，建議從設計初期便導入安全理念並妥善規劃整體供應鏈控管。

• 採行 Secure by Design
  在專案初期就把安全規劃納入系統架構與開發流程，避免後期出現重大漏洞才臨時補救。
• 使用 SBOM（軟體物料清單）
  透過 SBOM 全面掌握所用開源元件的版本、來源與維護狀況，有助於在脆弱性爆發時及早確認影響範圍，並快速採取對應措施。
• 落實真實性或完整性驗證
  針對所有更新檔案與套件，宜先進行數位簽章或雜湊檢查，避免不明改動在上游被植入；同時也可在組織內建立離線驗證或檔案比對機制，確保「官方更新」實際為官方所發佈。
• 結合分層防禦、嚴謹變更程序與補償性控制
  配合網路隔離、防火牆策略、漏洞掃描與多層監控，即使短期內無法立即修補，也能先以臨時補償方案壓制風險擴散。
• 長期維護與合規落實：
  工控系統週期長，宜選用維護期清晰且授權合規的開源元件；同時定期評估法規與標準動向，如 OpenChain ISO/IEC 5230、ISO/IEC 18974等，使整體供應鏈安全更具備持久性。

在數位化轉型的趨勢下，上述策略能協助工控業者在提升效率的同時，維持系統韌性與安全，確保關鍵基礎設施及產業營運得以穩定運作。

SBOM 的重要性與 OpenChain 電信 SBOM 指引的角色

SBOM 是軟體元件清單的正式記錄，包含軟體構建過程中的所有組件及其依賴關係。其主要目的是提升供應鏈的透明度，降低供應鏈攻擊風險，並確保組織能夠即時應對安全漏洞。

OpenChain 電信 SBOM 指引基於 ISO/IEC 5962:2021（SPDX） 標準，規範電信產業如何建立、交付與使用 SBOM，以確保高效與一致的安全管理機制。該指引適用於電信業者、設備供應商及軟體開發商。

主要標準與規範

1. SBOM 類型與資料格式

SBOM 可分為以下類型：

• 設計（Design）
• 原始碼（Source）
• 構建（Build）
• 分析（Analyzed）
• 部署（Deployed）
• 運行（Runtime）

符合 OpenChain 電信 SBOM 指引的文件應遵循 SPDX 2.2 或 2.3 格式，並包含以下關鍵元素：

• SPDX 文件生成資訊：版本、授權、文件 ID、建立者等。
• 軟體套件資訊：套件名稱、版本、供應商、下載來源、授權條款等。
• 元件依賴性資訊：確保所有傳遞性依賴（Transitive Dependencies）均被記錄。
• 數位簽章驗證：建議使用 Sigstore 進行數位簽章，以確保 SBOM 文件的完整性。

2. SBOM 交付方式與存取機制

• 內嵌交付：SBOM 應盡可能內嵌於軟體套件內，以提升存取便利性。
• 線上存取機制：若技術上無法內嵌 SBOM，應提供至少 18 個月 的線上存取，確保使用者能夠下載與驗證。
• 交付時機：SBOM 必須在軟體交付時同步提供，以確保合規性。

3. SaaS 環境與容器化應用的 SBOM

• OpenChain 指引對於 SaaS 服務並無強制 SBOM 要求，但供應商可選擇提供 SaaS 服務中使用的開源軟體及其依賴清單。
• 容器 SBOM 應包含所有安裝於容器內的軟體套件及相關元件，以確保完整性與可追溯性。

4. SBOM 合併與管理

• 允許透過 SPDX Relationship 定義 合併多個 SBOM，以簡化大型專案的管理。
• 可使用 SBOM Composer（GitHub 連結）進行多文件整合。
• 確保 SBOM 一致性：應建立內部機制驗證 SBOM 內容與軟體交付版本相符。

5. SBOM 保密性與法律限制

• SBOM 可受保密協議（Confidentiality Agreements）保護，但不得限制接收者重新散佈與開源軟體相關的部分。
• 針對商業元件，若未納入 SBOM，應明確標示為 已知但未包含的元件（Known Unknowns）。
• 確保合規性：應確保 SBOM 符合相關法規，如 GDPR、NIST 及 CISA 指南。

OpenChain 電信 SBOM 指引的實務應用

1. 內部政策與程序制定

• 建立 SBOM 生成與維護 流程，確保所有軟體產品均附帶符合標準的 SBOM。
• 明確 SBOM 責任歸屬，確保供應商與開發團隊遵循 OpenChain 指引。

2. 工具與自動化導入

• 使用 SPDX 相容工具（如 SPDX Tools）自動生成 SBOM。
• 部署 SBOM Composer 進行多 SBOM 合併與管理。
• 採用自動化檢測機制，確保 SBOM 更新同步於開發生命周期。

3. 供應鏈合規與審查

• 要求供應商提供符合 OpenChain 指引的 SBOM，並納入 採購合約條款。
• 針對 SBOM 進行 定期稽核，確保符合性與準確性。
• 建立供應鏈安全監控機制，確保 SBOM 更新與風險管理同步。

總結

OpenChain 電信 SBOM 指引為電信產業提供了一套完整的 SBOM 管理標準，確保供應鏈透明度與安全性。透過標準化的 SBOM 生成、交付與驗證機制，企業能夠有效降低供應鏈風險，確保軟體資安合規。

美國 CISA（網路安全與基礎設施安全局） 聯合多國資安機構，包括 美國國家安全局（NSA）、聯邦調查局（FBI）、美國環境保護署（EPA）、美國運輸安全管理局（TSA）、歐洲委員會、德國資訊安全聯邦局（BSI）、英國國家網路安全中心（NCSC-UK）、澳洲網路安全中心（ACSC）、加拿大網路安全中心（CCCS）、荷蘭網路安全中心（NCSC-NL）等，共同發布了 《Secure by Demand》指引，強調攻擊者通常鎖定特定 OT 產品，而非特定組織。

許多 OT 產品未落實 Secure by Design（安全即設計） 原則，導致系統普遍存在以下資安風險：

• 弱鑑別（Weak Authentication）：如共用帳號、靜態密碼、簡單密碼策略。
• 已知漏洞（Known Software Vulnerabilities）：未經處理的資安弱點。
• 記錄與日誌不足（Limited Logging）：缺乏事件監控與可追溯能力。
• 預設不安全的設定（Insecure Default Settings）：如開放不必要的通訊埠、啟動不需要的程式、使用硬編碼憑證等不安全的出廠設定。
• 不安全的傳統通訊協議（Insecure Legacy Protocols）：如 Telnet、SNMPv1/2、SSL、TLS 1.0/1.1，這些過時的協議缺乏可靠的加密與安全鑑別機制，使攻擊者能輕易攔截與操控通訊。

上述資安弱點使攻擊者得以輕易橫向移動、獲取控制權限，甚至影響多個受害者的營運環境。當 OT 產品在設計階段未納入安全性，企業往往需投入大量資源補強，如加裝防火牆、強化存取控制、手動修補漏洞等。然而，這種事後補救的方式不僅成本高昂，還可能無法有效防禦新興威脅。因此，OT 產品應在設計與開發階段即納入 Secure by Design 原則，確保設備具備內建的資安機制，從根本上降低網路攻擊風險。

Secure by Demand：改變 OT 資安責任的不均衡現象

目前，工業資安的負擔大多落在 OT 擁有者與營運商身上，而非產品製造商，儘管後者具備最佳條件來提升產品安全性並降低風險。為了改變這種不均衡的現象，各國正積極推動更安全的產品開發，例如：

• 美國 CISA 推動的 Secure by Design 計畫：確保技術產品在設計時即納入安全性，使客戶能夠信賴其資安能力，而非被迫自行補強。
• 歐盟通過的《網路韌性法案（Cyber Resilience Act）》：強制要求軟硬體製造商在產品設計階段即納入安全性，確保設備具備最低防禦能力。

因此，CISA《Secure by Demand》指引 提出 OT 產品採購 12 項安全要素，鼓勵 OT 擁有者與營運商優先選擇具備內建安全機制的產品，以降低長期的安全風險與維運負擔。

Secure by Demand：OT 產品採購 12 項資安關鍵要素

1. 組態管理（Configuration Management）

• 產品應支援組態管理機制，可記錄並追蹤所有設定與工程邏輯變更。
• 應提供安全的備份與還原機制，確保發生事故時能快速恢復。
• 具備防篡改機制，防止未授權的設定變更影響系統運作。

2. 內建記錄與日誌（Logging in the Baseline Product）

• 預設啟用 所有操作、設定變更、安全事件的記錄。
• 採用開放標準格式（如 Syslog），確保可整合至 SIEM 或 SOC 監控系統。

3. 採用開放標準（Open Standards）

• 產品應符合 ISA/IEC 62443 國際標準、NIST 800-82 指引，確保可互通，避免供應商綁定風險（Vendor Lock-in）。
• 此外, 開放標準（Open Standards） 提供系統擁有者與營運者更大的彈性，使其能夠根據市場上最適合的產品選擇供應商，而非受限於系統最初建置時的供應商技術。這些標準涵蓋記錄格式（如 Sysmon）、網路通訊協議（如 OPC-UA）、程式語言（如 IEEE 61131-3）、加密通訊協定（如 TLS）等，有助於提升跨供應商的互通性（Interoperability），避免供應商綁定帶來的高昂轉換成本與長期技術支援風險。因此，在評估新功能或技術時，應優先選擇符合開放標準的解決方案，並關注供應商是否積極支持互通性，例如公開技術解析器（Parsers）或參與國際標準工作小組，以確保系統長期維護的靈活性與安全性。

4. 營運自主權（Ownership）

• 設備擁有者應具備完整控制權，可自主維護、設定與升級，而不受供應商限制。
• 允許 OT 營運商 自行選擇第三方資安解決方案，而不影響設備保固或合約條款。

5. 資料保護（Protection of Data）

• 產品應確保 資料的完整性與機密性，防範未經授權的存取或變更。
• 限制供應商存取 OT 設備上的運作資料，確保關鍵資料安全。

6. 預設安全（Secure by Default）

• 將資安納入 OT 產品的預設設定，使其具備防範最常見威脅的能力，且不對買方產生額外成本負擔。對於現今的 OT 系統而言，「預設安全（Secure by Default）」尤為重要，因為 OT 設備具有長生命週期、停機修補（Patching）條件受限，且維持持續運作為首要考量。
• 要實現「設計即安全（Secure by Design）」的 OT 產品，應達成以下核心目標：
  • 將客戶資安納入核心業務要求，而非僅視為技術功能。
  • 內建預設設定應具備防範常見威脅的安全防護機制，並全面移除預設密碼。
  • 對內部 OT 設備連接至公共網際網路實施持續性存取控管機制，以降低資安風險。
  • 確保設備內建完整的安全功能，且無需額外收費。
  • 產品應內建安全部署指引或強化設定指引（Hardening Guide），並明確說明操作人員變更預設配置可能導致的資安風險。

7. 安全通訊（Secure Communications）

• 買方應要求安全通訊解決方案具備以下特性：
  • 易於部署與管理，即使非資安專業人員亦能正確操作。
  • 避免操作者因設定錯誤導致風險。
  • 內建鑑別機制，而非事後補充，確保與 OT 營運流程緊密整合。
• 在 OT 環境中，證書管理並不普及，因此可考慮下列過渡性方案：
  • TLS 簽章模式（Sign-only TLS）：不加密但仍使用私鑰簽章，以確保訊息未遭篡改。
  • 機會式 TLS（Opportunistic TLS）模式：當證書過期時仍允許通訊，但會產生警告記錄。
• 安全通訊應在產品開發初期即納入考量，否則可能導致難以部署或影響可用性。內建安全通訊機制 是縱深防禦（Defense in Depth）和零信任網路（Zero Trust Network）的基礎。買方應尋找理解 OT 操作流程的製造商，確保安全通訊功能能夠順利融入現有工作流程。

8. 安全控制（Secure Controls）

• OT 設備應內建 異常行為偵測機制，可識別並防範惡意指令影響系統安全。
• 產品應對 未經授權的操作進行警告或自動阻擋，確保營運穩定性。

9. 強化鑑別（Strong Authentication）

• 支援角色型存取控制（RBAC）與多因子鑑別（MFA），避免共用帳號與密碼外洩風險。
• 確保安全關鍵操作（如變更控制邏輯）時，要求 額外驗證機制。

10. 威脅建模（Threat Modeling）

• 供應商應提供 完整的威脅模型，分析可能的攻擊途徑與對應防禦措施。
• 產品應具備 定期更新的安全白皮書，幫助 OT 營運商進行風險評估。

11. 漏洞管理（Vulnerability Management）

• 供應商應建立 漏洞揭露政策（CVD），確保漏洞修補透明化。
• 提供免費的安全更新，確保設備維持最新安全狀態。

12. 升級與更新管理（Upgrade and Patch Tooling）

• OT 設備應提供 可驗證的更新機制，確保更新安全性與完整性。
• 供應商應支援 操作系統升級，避免設備因 OS 停止支援而形成資安風險。

結論：確保 OT 環境的長期安全與韌性

CISA 《Secure by Demand》指引 強調，OT 資產擁有者與營運商應將 Secure by Demand 納入決策標準，並要求供應商提供符合 ISA/IEC 62443 及 Secure by Design 準則的 OT 產品，以確保設備具備內建資安機制，有效降低網路攻擊風險，同時減少長期維運負擔。

在未來的 OT 採購計畫中，企業應優先選擇符合 Secure by Demand 原則及 12 項安全標準的產品，以強化營運安全、提升關鍵基礎設施的資安韌性，並確保系統的長期穩定與可持續發展。

此外，這些安全原則的落實將幫助企業在未來數十年內持續強化 OT 環境的資安基礎。選擇符合 Secure by Demand 要求的製造商，不僅能確保企業符合法規，更能建立一個彈性且可擴展的資安架構，以因應未來的資安挑戰，確保企業長期的營運穩定性與競爭力。

CISA 適用職務：

InfoSec Institute 網站建議 [1] 下列職務人員可考慮擁有 CISA 證照

• Internal auditor
• Public accounting auditor
• IS analyst
• IT audit manager
• IT project manager
• IT security officer
• Network operation security engineer
• Cyber security professional
• IT consultant
• IT risk and assurance manager
• Privacy officer
• Chief information officer

成為 CISA 流程：

1. 確認報考資格
2. 決定筆試準備方式
3. 報名並進行筆試
4. 填寫資格申請表
5. 進行審核
6. 繳交會費
7. 累積持續教育積分 Continuing Professional Education (CPE)

1. 確認 CISA 報考資格：

決定準備 CISA 考試前, 請先確認具備基本要求. 否則即便考過筆試也無法獲取證照, 而考試成績只保留 5 年.

發證組織 ISACA 規定需具備下列五個領域至少五年以上工作經驗. 若滿足特定條件進行抵免, 最少也要有兩年的工作經驗.

• DOMAIN 1 – Information Systems Auditing Process
• DOMAIN 2 – Governance And Management Of It
• DOMAIN 3 – Information Systems Acquisition, Development And Implementation
• DOMAIN 4 – Information Systems Operations And Business Resilience
• DOMAIN 5 – Protection Of Information Assets

抵免條件:

最多抵免一年:

• 一年稽核經驗或一年資訊系統稽核經驗

最多抵免三年:

• 有副學士學位可抵免一年
• 有任何領域學士、碩士或博士學位可抵免 2 年
• 有資訊系統或相關領域的碩士學位可抵免 3 年
• 有 CIMA – Chartered Institute of Management Accountants, full certification 資格可抵免 2 年
• 有 ACCA member status from the Association of Chartered Certified Accountants 資格可抵免 2 年

這邊建議先找好一位 verifier (建議找直接主管). 屆時 CISA 筆試通過後, 會需要他的具名推薦.

ISACA 也提供一些題目, 讓想報考的人了解目前的知識程度:

https://www.isaca.org/-/media/info/cisa-practice-quiz/index.html

2. 決定筆試準備方式

由於每個人學習方法, 以及準備時間皆有所差異. 所以可根據自身需求來選擇下列筆試準備方式.

1. 課程
   • ISACA 官方線上課程
   • ISACA台灣分會 / 中華民國電腦稽核協會實體課程
   • 臺灣許多訓練中心都有開 CISA 實體課程
2. 自修
   • ISACA 官方建議書單

以下是我準備 CISA 所使用到的書單、學習網站以及手機 APP:

• ExamTopics
• ISACA^® CISA Exam Prep
• CISA Review Manual, 27th Edition

個人主要準備方式為

1. 先進行由中華民國電腦稽核協會開的實體課程, 想參與課程的初衷除了想瞭解其他公司的資安稽核經驗跟狀況, 還想多認識一些資安業界同好.
2. 上完課程後, 瀏覽 CISA review manual, 並結合自身的經驗, 進行知識微調.
3. 下載 CISA Exam Prep APP, 這個 APP 提供 600 個題目, 且每個題目都會附上 Review Manual 的出處, 以及詳細講解. 好處是隨時都可以找空檔練習並加強觀念. 不過我認為此 APP 在 CISA 的題目設計上有很大的進步空間, 因許多題目在考名詞解釋, 而非情境題.
4. 接著在 ExamTopics 網站開始練習題目, 做了約 311 題. 我覺得 ExamTopics 的好處是, 若答案有問題, 可以提出來跟其他人討論.
5. 大概做了 600 + 311 題後前去應考.
6. ISACA 有不錯的論壇, 裡面有許多資訊可供準備考試的人討論及參考
   • https://engage.isaca.org/

認證考試範圍

CISA 考試範圍涵蓋了下列四個領域

• Information Systems Auditing Process (21%)
• Governance And Management Of It (17%)
• Information Systems Acquisition, Development And Implementation (12%)
• Information Systems Operations And Business Resilience (23%)
• Protection Of Information Assets (27%)

3. 報名並進行筆試

ISACA 委由 PSI 進行考試, 由於疫情關係, 我選用 PSI remote proctor , 也就是遠端監考方式進行 CISA 測驗

考試方式:

CISA 提供許多語言以供應試選擇, 其中包含簡體中文以及英文. 

• 考試時間: 4 小時
• 題數: 150 題
• 形式: 單選題

應試當天:

• 記得帶護照
• 好好閱讀題目敘述, 避免誤解題意
• 遞交答案後, 系統會顯示初步是否通過考試

我個人選用英文考試, 整體作答時間約 118 分鐘.

要注意的是, 作答時要以稽核員的角度來思考該採取哪一種方法較為合適. 畢竟不同角色對於問題的處理方式會有所差異. 如果之前考過 CISM, 務必注意在 CISA 的測驗要轉換角度來思考, 因同一個事件發生, CISA 跟 CISM 的處理方式跟心態都會有所不同.

4. 填寫資格申請表

測驗後約莫 10 個工作天, ISACA 就會透過 email 正式寄送成績單. 若通過測驗, 即可透過 ISACA 官方網站填寫 CISA 資格申請表. 除了自己的資料外, 也須請推薦人填寫相關表單並簽名以進行推薦.

5. 進行審核

一切填寫完畢後, 發證組織 ISACA  就會進行審核. 約兩三天通過審核並授證.

6. 繳交會費

審核完畢, 確定已繳交會員年費 USD: 195 即可生效.

此外, ISACA 與 Acclaim 進行合作, 能在網站上查到證照訊息

7. 累積持續教育積分 Continuing Professional Education (CPE)

• 每年完成最少20小時的持續教育積分。
• 每 3 年完成最少120小時的持續教育積分。

CPE 可以透過參加資安論壇、擔任資安會議講者、參加資安 webinar、寫書或者開課等等方式獲得.

關於 CPE 的詳細資訊, 可參考官方資料

心得:

經由準備 CISA 的過程, 讓我了解稽核技巧, 以及相關稽核風險. 透過不同面向的學習, 能更了解資安全貌.

如果考過 CISSP 再來挑戰 CISA, 準備上會輕鬆不少.

準備時間:

大概十個日曆天, 主要為六日以及週間下班時間.

所花費用:

• CISA Premium (CISA Pocket Prep) NTD: 1460
• Membership USD: 195 (已於 CISM 考照時繳交)
  • ISACA USD: 135
  • New Member Fee USD: 10
  • 142-Taiwan Chapter: USD: 50
• 考試: USD 575
• 申請認證: USD 50

Reference:

[1] https://resources.infosecinstitute.com/certification/job-outlook-cisa-professionals/

[2] https://www.isaca.org/credentialing/cisa

[3] https://www.isaca.org/credentialing/cisa/get-cisa-certified

[4] https://www.caa.org.tw/cisa-license.php?id=CISA

睽違兩年多的發行, 跟前一版 Debian 10 – Buster 有什麼差異呢?

img src: https://wiki.debian.org/DebianArt/Themes/Homeworld?action=AttachFile&do=get&target=blog_banner.png

支援 CPU 架構 [2]

異動部份

• 移除 MIPS mips (big-endian) 支援

目前官方支援的架構

• 32-bit PC (i386) and 64-bit PC (amd64)
• 64-bit ARM (arm64)
• ARM EABI (armel)
• ARMv7 (EABI hard-float ABI, armhf)
• little-endian MIPS (mipsel)
• 64-bit little-endian MIPS (mips64el)
• 64-bit little-endian PowerPC (ppc64el)
• IBM System z (s390x)

此次發行版異動 (完整清單可見 release note [3])

套件相關

相較 Debian 10,  Debian 11 新增 11294 個套件, 更新 42821 個套件, 並移除 9519 個套件.

目前內含超過 59551 個套件.

主要套件更新訊息如下:

img src: https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.html

除此之外, 桌面套件也都進行升級

• Gnome 3.38,
• KDE Plasma 5.20,
• LXDE 11,
• LXQt 0.16,
• MATE 1.24,
• Xfce 4.16.

重點功能

Driverless scanning and printing

透過 CUPS [4] 套件來進行 driverless printing, SANE [5] 套件進行 driverless scanning.

Control groups v2

從 Debian 11 開始, systemd 預設使用 control groups v2 (cgroupv2), 若想改回 cgroup v1, 可參考這篇設定

Persistent systemd journal

Bullseye 中的 systemd 預設啟動 persistent journal 功能, 將相關資料儲存在 /var/log/journal/ 中。更多設定以及資訊可參考 systemd-journald.service(8) manpage；

New Fcitx 5 Input Method

更新 Fcitx 輸入法, 新版本支持 Wayland 並支持 plugin, 更多資訊可參考這篇說明

支援 exFAT 格式

因 Debian 11 Bullseye 使用 kernel 5.10, 所以可使用在 kernel 5.4 就加入的 exFAT 功能. 除了 kernel configuration 要開啟外, 也須搭配 userspace 程式, 如 exfatprogs [9].

改善了對於 systemd 之外 init systems 的支援

眾所皆知, Debian 8 開始即採用 systemd 為預設 init system. 即便如此, 還是有許多使用者使用 sysvinit or openrc 等等的 init system, 有鑑於此, Debian 11 也改善了相關支援, 詳情可參考這篇說明

密碼雜湊演算法預設使用 yescrypt

Debian 11 Bullseye 使用 yescrypt 來取代原本的預設 hash algorithm SHA-512, 為了加強針對字典的密碼猜測攻擊的安全性. 由於 Debian 10 Buster 不支援 yescrypt, 所以升級上要特別注意, 詳情可參考這篇說明

進行 Debian 10 -> 11 升級前, 建議閱讀此文件, 確保了解升級須注意的地方

References:

[1] https://wiki.debian.org/DebianBullseye

[2] https://www.debian.org/releases/stable/amd64/ch02s01.en.html

[3] https://www.debian.org/releases/stable/amd64/release-notes/

[4] https://wiki.debian.org/CUPSQuickPrintQueues

[5] https://wiki.debian.org/SaneOverNetwork

[6] https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#openstack-cgroups

[7] https://manpages.debian.org/bullseye/systemd/systemd-journald.service.8.en.html

[8] https://wiki.debian.org/I18n/Fcitx5

[9] https://packages.debian.org/bullseye/exfatprogs

[10] https://wiki.debian.org/Init

[11] https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#pam-default-password

[12] https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html

Global Information Assurance Certification (GIAC)  2013 年底推出 Global Industrial Cyber Security Professional (GICSP) 全球工業網路安全專家認證 [1]

這張認證是由數間 OT/ ICS 公司, 如 Shell, Chevron, Saudi Aramco, BP, Rockwell Automation, Yokogawa Industries, Emerson, ABB, Cimation 和 SANS Institute 一起討論並設計框架. 透過此證照來評估 OT/ ICS 相關人員是否具備工控安全知識.

GICSP 在臺灣雖然相對冷門, 但其實在國外曝光度來說還蠻高的, 除了在 ISA99 committee (制定 ISA/ IEC 62443 標準組織) 看到不少成員都擁有此證照外, 也看到許多在 OT/ ICS 公司服務的朋友都具備此證照, 再加上 DoDD 8140 [2] 也把 GICSP 列入為 Information Assurance Technical (IAT) Level II – 同時也是 DoDD 8140 唯一的 OT/ ICS 資安證照. 所以對於從事工控安全領域的人員來說, 值得參考.

截至 2021/3/13, 全球擁有此證照的人數大約為三千多人 [3].

GICSP 涵蓋領域 [4]：

• 工業控制領域元件, 目的, 部署, 重要推動因素和限制
• 控制系統攻擊層面, 方法和工具
• 控制系統方法和網路防禦架構和技術
• 控制系統環境中的安全事件應變技能
• 工業網路安全專業人員的治理模型與資源

GICSP 適用職務 [4]：

GIAC 建議下列職務人員可考慮擁有 GICSP 證照

• ICS IT practitioners (includes operational technology support)
• ICS Security analysts (includes operational technology security)
• Security engineers
• Industry managers and professionals

成為 GICSP 流程：

1. 填寫報名表及相關資料
2. 決定筆試準備方式
3. 報名並進行筆試
4. 累積持續教育積分 Continuing Professional Education (CPE)

1. 填寫報名表及相關資料：

GICSP 報考前須填寫報名表, 除了個人資料外, 也須提供下列資訊給 GIAC 進行人工審核, 大約七個工作天內就會收到審核結果.

• Please summarize your security-related experience, training completed, or certifications earned.
• Please describe your study methods and the materials you will bring to the testing center for your certification exam.

2. 決定筆試準備方式

由於每個人學習方法, 以及準備時間皆有所差異. 所以可根據自身需求來選擇下列筆試準備方式.

1. 課程
   • SANS 官方線上課程 (GICSP 官方建議課程) – ICS410: ICS/SCADA Security Essentials
   • SCADAHacker 線上課程
2. 自修 (列出個人看過, 覺得還不錯的書目)
   • Applied Cyber Security and the Smart Grid: Implementing Security Controls into the Modern Power Infrastructure
   • Industrial Network Security: Securing Critical Infrastructure Networks for Smart Grid, SCADA, and Other Industrial Control Systems

個人主要準備方式

1. 雖本身對工控資安已有經驗以及相關知識, 但對於工控無線網路 (WirelessHART, ISA100) 以及 Windows 相關實作並沒有機會接觸, 加上 GICSP 資訊相對稀少, 所以選擇 SANS 官方線上課程來補齊這方面的知識. 課程本身提供許多實作練習, 除此之外也會贈送一塊 PLC 板子.
2. 上完課即報名測驗.

GICSP 內容相當的廣, 從工控資安標準 (ISA/ IEC 62443, NERCCIP 直到 CSF), 工控 Protocol, 工控無線網路, Purdue 模型, Linux/ Windows 上的相關實作, 到資安事件處理皆有含括在內.

認證考試範圍

GICSP 考試範圍涵蓋了下列領域

• Hardening ICS Operating Systems
• ICS Communications and Compromises
• ICS Intelligence Gathering
• ICS Level 0 and 1 Technology Overview and Compromise
• ICS Level 2 and 3 Technology Overview and Compromise
• ICS Overview and Concepts
• ICS Procurement, Architecture, and Design Fundamentals
• ICS Program and Policy Development
• ICS Wireless Technologies and Compromises
• Risk Based Disaster Recovery and Incident Response

3. 報名並進行筆試

GICSP 提供兩種方式進行

1. ProctorU 遠端應考
2. 前往 PearsonVUE 中心應考

由於疫情關係, 我選用 ProctorU 遠端測驗, 也就是遠端監考方式進行 GICSP 測驗. 報名完的確認信件會告知應試相關注意事項.

測驗前請記得找一個密閉空間, 因為遠端監考官會要求檢視空間內的狀態.

GICSP 的測驗跟其他資安證照不太一樣, 採 open book 方式, 也就是可攜帶紙本文件以及紙本筆記, 但禁止存取網路資源以及電子設備

考試方式:

• 考試時間: 3 小時
• 題數: 115 題
• 最低及格分數為 71 %
• 形式: 單選題

應試當天:

• 記得帶護照
• 記得帶第二證件(需英文), 我使用 (ISC)² 核發的 CISSP 會員證件作為第二英文證件
• 好好閱讀題目敘述, 避免誤解題意
• 遞交答案後, 系統會直接告知分數, 以及是否通過測驗

個人整體作答時間約 160 分鐘, 我個人認為是參加過資安測驗中最精實的, 有的題目出得很偏又細, 相當不好回答.

測驗通過後, GIAC 除了透過電子郵件即時告知外, 也會在一兩天後核發 Digital Certification Badge.

GIAC 的認證不需繳交會員年費, 但每四年需支付一次 USD 429 維護費.

4. 累積持續教育積分 Continuing Professional Education (CPE)

GIAC 的要求為四年內必須完成 36 CPEs

CPE 可以透過從事資安工作、參加資安論壇、擔任資安會議講者、參加資安 webinar、寫書或者開課等等方式獲得.

關於 CPE 的詳細資訊, 可參考官方資料

心得:

透過準備 GICSP, 能以更寬廣的姿態來學習工控資安相關知識, 搭配實作課程的學習, 來強化工控安全的觀念以及相關資安技能.

準備時間:

大概兩週, 主要為六日以及週間下班時間.

所花費用:

• ICS410: ICS/SCADA Security Essentials 課程: USD 7,020
• 考試: USD 799

Reference:

[1] https://en.wikipedia.org/wiki/Global_Information_Assurance_Certification

[2] https://www.giac.org/certifications/dodd-8140

[3] https://www.giac.org/certified-professionals/directory/gicsp

[4] https://www.giac.org/certification/global-industrial-cyber-security-professional-gicsp

[5] https://www.giac.org/certifications/renewal

常見的軟體開發生命周期包含了:

1. 需求分析 (Requirement Analysis)
2. 設計 (Design)
3. 實作 (Implementation)
4. 測試 (Testing)
5. 維護/ 改版 (Maintenance/ Evolution)

產品開發中常見的謬誤是 – Vulnerabilities 或 CVE 只要在維護/ 改版階段再來處理就好了, 但這樣的觀念忽略掉越後期處理 vulnerabilities 成本會越高.

除了修改難度加高外, 研發人員也會疲於奔命在現有專案以及舊有專案維護上進行工作切換, 更不用說通常 vulnerabilities 都來的又急又快, 長期來說會嚴重傷害研發人員身心健康.

所以說, 比較好的做法是以系統性方法來管理 kernel vulnerabilities, 在軟體開發生命周期每個階段中都考慮 vulnerabilities 相關元素, 這樣做除了降低維護成本外, 也能讓研發資源好好地被配置.

以下根據個人經驗, 列出每個開發階段如何加入vulnerabilities 管理元素

1. 需求分析 (Requirement Analysis)
   • 好好定義出真正的產品/ 應用需求, 以提供資訊給設計階段來選取 kernel 
2. 設計 (Design)
   • 根據產品/ 應用需求來選取並使用相對適合的 kernel 類型以及版本
   • 使用定版 kernel, 而不是滾動中的版本 (rolloing version)
3. 實作 (Implementation)
   • 遵循 “upstream first" policy, 所有的修改盡量都送到上游, 以避免因時間累積大量 in-house patch, 導致維護上的困難
   • 最佳化 kernel configuration, 沒用到或不需要的選項全部關閉.
4. 測試 (Testing)
   • 善用自動化工具, 除了確保軟體品質外, 也能降低進版測試的人力/ 物力成本
5. 維護/ 改版 (Maintenance/ Evolution)
   
   • 可使用 vulnerability scanning tool 來即時監控 kernel vulnerabilities 狀態.

更多相關資訊, 可參考以下投影片.

CISM 適用職務：

InfoSec Institute 建議 [1] 下列職務人員可考慮擁有 CISM 證照

• Information Security Manager
• Information/Privacy Risk Consultant
• Information System Security Officer

成為 CISM 流程：

1. 確認報考資格
2. 決定筆試準備方式
3. 報名並進行筆試
4. 填寫資格申請表
5. 進行審核
6. 繳交會費
7. 累積持續教育積分 Continuing Professional Education (CPE)

1. 確認 CISM 報考資格：

決定準備 CISM 考試前, 請先確認具備基本要求. 否則即便考過筆試也無法獲取證照, 而考試成績只保留 5 年.

發證組織 ISACA 規定需具備下列四個領域至少五年以上工作經驗. 若滿足特定條件, 得抵免一至兩年工作經驗 [2], 最多也只能抵免兩年. 而我本身直接使用 CISSP 證照來抵免兩年工作經驗.

• DOMAIN 1 – Information Security Governance
• DOMAIN 2 – Information Risk Management
• DOMAIN 3 – Information Security Program Development and Management
• DOMAIN 4 – Information Security Incident Management

這邊建議先找好一位 verifier (建議找直接主管). 屆時 CISM 筆試通過後, 會需要他的具名推薦.

ISACA 也提供一些題目, 讓想報考的人了解目前的知識程度:

https://www.isaca.org/-/media/info/cism-practice-quiz/index.html

2. 決定筆試準備方式

由於每個人學習方法, 以及準備時間皆有所差異. 所以可根據自身需求來選擇下列筆試準備方式.

1. 課程
   • ISACA 官方線上課程
   • ISACA台灣分會 / 中華民國電腦稽核協會實體課程
   • 臺灣許多訓練中心都有開 CISM 實體課程
2. 自修
   • ISACA 官方建議書單

以下是我準備 CISM 所使用到的書單、學習網站以及手機 APP:

• ExamTopics
• ISACA^® CISM Exam Prep
• CISM Review Manual, 15th Edition

個人主要準備方式為

1. 先進行由中華民國電腦稽核協會開的實體課程, 想參與課程的初衷除了想瞭解其他公司的資安治理經驗跟狀況, 還想多認識一些資安業界同好.
2. 上完課程後, 瀏覽 CISM review manual, 並結合自身的經驗, 進行知識微調.
3. 下載 CISM Exam Prep APP, 這個 APP 提供 600 個題目, 且每個題目都會附上 Review Manual 的出處, 以及詳細講解. 好處是隨時都可以找空檔練習並加強觀念.
4. 接著在 ExamTopics 網站開始練習題目, 做了約 800 題. 我覺得 ExamTopics 的好處是, 若答案有問題, 可以提出來跟其他人討論.
5. 大概做了 1400 題後前去應考.
6. 考完才發現 ISACA 有不錯的論壇, 裡面有許多資訊可供準備考試的人討論及參考
   • https://engage.isaca.org/

認證考試範圍

CISM 考試範圍涵蓋了下列四個領域

• Security and Risk Management (24%)
• Asset Security (30%)
• Security Architecture and Engineering (27%)
• Communication and Network Security (19%)

3. 報名並進行筆試

ISACA 委由 PSI 進行考試, 由於疫情關係, 我選用 PSI remote proctor , 也就是遠端監考方式進行 CISM 測驗

考試方式:

CISM 提供許多語言以供應試選擇, 其中包含簡體中文以及英文. 

• 考試時間: 4 小時
• 題數: 150 題
• 形式: 單選題

應試當天:

• 記得帶護照
• 好好閱讀題目敘述, 避免誤解題意
• 遞交答案後, 系統會顯示初步是否通過考試

我個人選用英文考試, 整體作答時間約 180 分鐘.

要注意的是, 作答時要以管理者的角度來思考該採取哪一種方法較為合適. 畢竟不同角色對於問題的處理方式會有所差異. 對我最挑戰的是, 日常工作所能使用的解決方案, 不一定是業界的最佳解 (最佳解或許就接不了地氣…), 所以知識微調就很重要.

4. 填寫資格申請表

測驗後約莫 10 個工作天, ISACA 就會透過 email 正式寄送成績單. 若通過測驗, 即可透過 ISACA 官方網站填寫 CISM 資格申請表. 除了自己的資料外, 也須請推薦人填寫相關表單並簽名以進行推薦.

5. 進行審核

一切填寫完畢後, 發證組織 ISACA  就會進行審核. 一般須等 3~4 週左右. 我自己是等了接近十週都還沒有消息, 詢問後發現是他們系統轉換造成一些問題, 客服約三天內就協助我通過審核並授證.

6. 繳交會費

審核完畢, 並繳交會費後會員年費 USD: 195 即可生效.

此外, ISACA 與 Acclaim 進行合作, 能在網站上查到證照訊息

7. 累積持續教育積分 Continuing Professional Education (CPE)

• 每年完成最少20小時的持續教育積分。
• 每 3 年完成最少120小時的持續教育積分。

CPE 可以透過參加資安論壇、擔任資安會議講者、參加資安 webinar、寫書或者開課等等方式獲得.

關於 CPE 的詳細資訊, 可參考官方資料

心得:

良善資安治理對於公司營運甚至資安產品, 技術發展為重要基石. 透過準備 CISM 的過程, 讓我能適當調校一些資安治理以及管理觀念, 以系統性規劃來推動資安發展. 

準備時間:

大概三週, 主要為六日以及週間下班時間.

所花費用:

• CISM Premium (CISM Pocket Prep) NTD: 1460
• Membership USD: 195
  • ISACA USD: 135
  • New Member Fee USD: 10
  • 142-Taiwan Chapter: USD: 50
• 考試: USD 575
• 申請認證: USD 50

Reference:

[1] https://resources.infosecinstitute.com/certification/common-cism-job-titles/

[2] https://www.isaca.org/credentialing/cism

[3] https://www.isaca.org/credentialing/cism/get-cism-certified

[4] https://www.caa.org.tw/cisa-license.php?id=CISM

這篇主要是介紹 OpenChain 流程、規格以及如何一步步地符合 OpenChain 開源合規規格.

英文規格書

• https://wiki.linuxfoundation.org/_media/openchain/openchainspec-current.pdf

繁體中文規格書

• https://github.com/OpenChain-Project/Specification-Translations/raw/master/zh-Hant/2.0/OpenChain-Specification-2-0-zh-Hant.pdf

基本概念 – 建立 OpenChain 流程的六大要點:

1、方案建立規範範圍、 開源政策書建立框架

2、聯絡窗口、資源配置、角色及責任

3、開源軟體清單的建立流程

4、開源軟體清單的驗證、合規稽證產出流程

5、與開源社群互動規範

6、確認以上要點皆被妥善記錄、保存、以及定期更新

OpenChain 是以方案 (program) 為單位, 意及同個組織內允許擁有多個 OpenChain program, 以因應不同單位因使用特性等因素而不能共用 open source policy 或者其他 program 內容.

OpenChain 核心元素

根據類型, OpenChain 核心可分為四個元素, 分別為

1. 政策書

• Open Source Policy
  • 組織如何看待及使用 Open source software
• Open Source Contribution Policy
  • 組織如何看待開源貢獻, 以及跟社群之連結

2. 流程

• Policy Implementation
  • 實作開源政策
• Program R&R and Implementation
  • 方案中對參與者的角色以及責任實作
• License Obligations
  • 授權之義務
• Open Source Content Review and Approval
  • 審核及核可開源相關內容
• Compliance Artifact Creation and Delivery
  • 合規稽核產出以及交付
• Open Source License Compliance Inquiry
  • 開源授權合規查詢
• Documentation
  • 資訊文件化
• Regularly updated
  • 定期更新

3. 人員

• Open Source Liaison
  • 對外聯絡窗口, 專門處理開源議題.
• Software Staff
  • 軟體開發人員
• Program Participants
  • 方案參與者

4. 技術

• License Scanning Tools
  • 軟體授權掃描工具
• SPDX Tools
  • Software BOM 工具
• Software BOM Management Tools
  • 管理 Software BOM (bill of materials) 列表工具

深入淺出 OpenChain 規格書

將規格書內的文字具像化並佐以步驟以滿足規格書之要求.

1. 每個方案都需有開源政策書以及開源貢獻政策書.

2. 開源政策書以及開源貢獻政策書需有方法或途徑 (如: wiki, 訓練等等) 能夠提供給軟體開發人員.

3. 需配置對外聯絡窗口, 專門處理開源議題.

4. 定義方案範圍並文件化之.

5. 建置方案中所需的人員 – 定義角色、責任, 並確認參與人員皆具備應有之意識, 並核對參與人員是否可勝任該所屬之職責 – 以上結果皆需進行文件化.

6. 建立開源審核流程, 釋出流程, 以及貢獻流程

7. 所使用的開源軟體清單透過開源審核流程產出相對應之 copyright, obligation, 以及 use cases

8. 所使用的開源軟體清單透過釋出流程產生合規稽證, 並提供相對應的文件化資訊.

9. 確保方案合乎 OpenChain 規範

10. 保存相關文件化資訊至少 18 個月以上

OpenChain 評核流程

想獲得 OpenChain 流程認證, 可透過以下三種方法:

1. Self-Certification / 線上自我測驗

• 組織/ 單位自行評定是否合規, 並至下列網站進行註冊確認
• https://certification.openchainproject.org/

2. Independent Compliance Assessment/ 獨立合規評估

• 由第三方進行獨立合規評估, 並至下列網站進行註冊確認
• https://certification.openchainproject.org/

3. Third-Party Certification / 公正第三方驗證

• 由第三方進行獨立合規評估, 通過後給予認證

更多內容可參考下列投影片:

2019 年在 Open source summit China & Japan 的技術會議上分享了使用開源軟體打造嵌入式平台的相關經驗.

常見的一個嵌入式 Linux 平台中基本軟體包含了:

• 硬體或其他 SoC 相關程式
• bootloader
• Linux kernel
• rootfilesystem

對於多變的嵌入式產品應用環境而言, 沒有最好的方法, 只有相對適合的解決方案. 所以需要先瞭解嵌入式 Linux 平台實際應用, 再根據相關應用產生的需求來決定相關設計以及方法. 透過合宜的軟體開發流程可以有結構的來打造專屬的嵌入式 Linux 平台.

下列為分享之簡報, 內容主要是對設計、構建、維護 Embedded Linux 平台進行系統性的介紹.