安全與合規

這些年，AI 的蓬勃發展和誘人的可能性，早已讓組織一股腦地投入 AI 相關應用與探索，以便提升自身的競爭力。不過隨著技術漸漸落地，應該也不難發現 AI 所帶來的不確定性。比方說，即便發送相同問題的請求，AI 也無法保證次次給出相同或預期的結果，而且這還不討論近幾年大語言模型的幻覺現象。因此，想要從 AI 獲得好處，我們需要思考的是如何管控這些不確定性，並且做出合理的權衡決策。 NIST AI RMF 便是用來協助組織管理 AI 所帶來的風險與影響，讓組織能在控制潛在危害的同時，真正取得 AI 所帶來的效益。 想要了解這個工具，首先得先來聊聊 Risk 在風險管理情境下的概念。在日常情境下，聽到 Risk 這個字多半會先想到負面的事件。不過在風險管理的角度上來看，Risk 卻有更為寬廣的定義。 ISO 31000 定義 Risk2 為不確定性對既定目標所產生的影響(effect of uncertainty on objectives)

今年剛好有機會受國家資通安全研究院的邀請去參加 DevSecOps 人才培養的討論，與會者有的來自學界而有的來自產業界。整個討論以核心、次核心、外圍的任務、知識和技能的超大表來進行，項目總計應該有近百項，所幸研究員設計了一個討論方式，讓整個討論不至於按表操課到枯燥乏味，但是最後討論還是持續了三個半小時多。過程中，還有一些共同表達意見的部分，則又提供了一些貼心的小舉牌(如下圖)。 特別提出這個小舉牌其實是因為這種做法是相當值得稱許的。直觀來說，想法表達大致上就是「是」或「不」，這種極端答案，但實際上團隊討論時的確會存在實質願意配合而沒有特別想法的成員。這種時候逼迫他們非要選隊站，很容易提升作出選擇的困難或是導致討論變得極端。 回到 DevSecOps 人才職能的議題上，目前職能的項目和類型是以歐盟標準為核心，輔以美國的標準。 標準設計上，DevSecOps 工程師一職是被設計在安全交付此面向上，但安全「交付」的交付二字為這個職能帶來許多挑戰。面對不同類型的組織，其組織內的資安角色並不見得有如這類標準所列出的精美配置，所以這也使得該職能工程師的工作範圍可大可小。不過，可能會有人認為 DevSecOps 它是一種機制、文化或做事的方法，而非一個角色，這說法自然也沒什麼毛病，但就像 DevOps 本質上也是種軟體開發的做法、機制和文化，但最後市場還是多了很多 DevOps 工程師和部門，所以 DevSecOps 也很自然地往這方向發展。往好的方面看，這也代表這樣的機制、做法和文化被期待內建到組織中。或許文化這樣的概念會因為這些內建的演進漸漸地在組織中形成吧!? 所以簡單來說，從當前標準的職能定位來看，DevSecOps 這類角色有點像是昔日的安全工程師加上 DevOps 工程師的味道！ 有這麼簡單!!!?? 這幾年在現場協助企業落地實施 DevSecOps 時，我比較容易感覺到這類角色常常就是我們半驕傲半苦笑說的一條龍工程師 再加上需要了解「安全知識」並且「知道如何將安全左移到每個軟體生命周期階段」，以便確保軟體在「端到端“交付”是安全的」。講到這兒~我不禁為這職能捏把冷汗，心裡直嘆好厲害的一個角色。

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 正是提供此關鍵訊息的機制。

前言 前陣子在 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：