技術與實務

SBOM 雖說 VEX 並不盡然需要依賴於 SBOM，但在討論 VEX 之前，肯定必須先了解一下 SBOM（Software Bill of Materials, 軟體物料清單），因為這樣才能了解 VEX 的必要性和它所想解決的問題。 軟體物料清單提供了軟體組成的相關資訊。這些相關資訊會說明這些組成是由誰提供、由誰開發、包含哪些項目、何時建置和依賴訊息等訊息。這些資訊對於提升軟體的透明度相當有幫助。因為使用者能夠透過這些資訊了解該軟體所採用的套件或其他工具是否存在可被利用的漏洞而需要立即進行修補。 SBOM 之所以受到關注還是要歸因於從 2020 年後的三起重大的資安事件，包括 Solarwinds[1]、燃油管事件[2]和 Log4j[3]。這三個重大資安事件促使美國總統在 2021 年時簽署了行政命令，責令美國商務部和美國國家電信暨資訊管理局（National Telecommunications and Information Administration, NTIA）需要在 60 天內制定 SBOM 的最基本要件。雖然 SBOM 對提升透明度的確有所幫助，但它畢竟仍是一個靜態的資訊。軟體使用者仍需要從軟體供應者處取得該軟體相關組成的漏洞狀態，才能夠進一步確認當前軟體受到漏洞影響的狀態，而 VEX 正是提供此關鍵訊息的機制。

前言 GitLab CI/CD 的 job 如何獲取程式碼庫時提供三種策略，分別為： clone fetch none 在比較這三個策略的差異之前，我們需要先了解 Executor 主要的初始作業與結束作業是怎麼運作的。 Executor 初始作業 我們先以一個基礎的 GitLab CI/CD 範例來看，該範例將會運行一個 build job： stages: - build build: stage: build script: - echo "building.

前言 前陣子在 DevOpsDays Taipei 2023 參加了一場 OST，該場討論的主題是《DevOps 與資安的平衡（ISO 27001）》，當中聊到了 DevSecOps 成熟度模型（DSOMM）時，有位與會者提到兩年前有人成功運行了 DSOMM，但現在那個方法已經失效，不確定現在組織要怎麼自己架設 DSOMM 的網站… （…突然感受到我該更新兩年前所寫的 DSOMM 文章了…🧐）於是這篇文章就出現啦！ 不過 DSOMM 的概念與組織如何運用與先前的介紹差異不大，所以本篇不會太著墨在 DSOMM 介紹，對於 DSOMM 有興趣的讀者可以先參考之前的介紹文：DEVSECOPS 成熟度模型（DSOMM）。而本篇主要會針對以下幾個變化進行介紹： DevSecOps 的成熟度級別 ISO 27001:2022 的對照 基於團隊的評估 自行架設 DSOMM 網站 一、DevSecOps 的成熟度級別 如同大多數的成熟度模型（例如：CMMI、DMM）將成熟度分為五個級別，今年 DSOMM 亦將成熟度從四個級別重新劃分為五個級別1：

啊哈！DevOps Handbook 第二版 DevOps Handbook 是 DevOps 領域的經典書籍，同時也是 EXIN DevOps Professional 國際認證的核心教材，不論技術者或管理者，對於任何想學習 DevOps 核心概念與實踐的人來說，這本書就是最好的起點，也是大家書櫃上不能錯過的一本好書。 最近 Nicole Forsgren 博士（另一本 DevOps 經典書籍 «Accelerate» 的作者之一）為本書第二版添加了新的內容，包括： 15 個案例分享 近年來 DORA1、Puppet2 «State of DevOps Report» 的調研結果 «Accelerate» 所提及的關鍵指標 當前適用的技術工具 …等其他有趣的主題 當中，最主要新增的篇幅為 15 個案例分享，而這些案例多是來自企業在 DevOps Enterprise Summit (DOES)3 上精彩的分享。由於篇幅限制與章節分佈，因此有些案例在書中只能呈現部分的內容。我們將這些原始內容的相關資訊作了整理，並且提供十分扼要的註解。讓大家可以很快地找到感興趣的主題，然後前往觀看4 :sunglasses: