今年剛好有機會受國家資通安全研究院的邀請去參加 DevSecOps 人才培養的討論，與會者有的來自學界而有的來自產業界。整個討論以核心、次核心、外圍的任務、知識和技能的超大表來進行，項目總計應該有近百項，所幸研究員設計了一個討論方式，讓整個討論不至於按表操課到枯燥乏味，但是最後討論還是持續了三個半小時多。過程中，還有一些共同表達意見的部分，則又提供了一些貼心的小舉牌(如下圖)。
特別提出這個小舉牌其實是因為這種做法是相當值得稱許的。直觀來說，想法表達大致上就是「是」或「不」，這種極端答案，但實際上團隊討論時的確會存在實質願意配合而沒有特別想法的成員。這種時候逼迫他們非要選隊站，很容易提升作出選擇的困難或是導致討論變得極端。
回到 DevSecOps 人才職能的議題上，目前職能的項目和類型是以歐盟標準為核心，輔以美國的標準。
標準設計上，DevSecOps 工程師一職是被設計在安全交付此面向上，但安全「交付」的交付二字為這個職能帶來許多挑戰。面對不同類型的組織，其組織內的資安角色並不見得有如這類標準所列出的精美配置，所以這也使得該職能工程師的工作範圍可大可小。不過，可能會有人認為 DevSecOps 它是一種機制、文化或做事的方法，而非一個角色，這說法自然也沒什麼毛病，但就像 DevOps 本質上也是種軟體開發的做法、機制和文化，但最後市場還是多了很多 DevOps 工程師和部門，所以 DevSecOps 也很自然地往這方向發展。往好的方面看，這也代表這樣的機制、做法和文化被期待內建到組織中。或許文化這樣的概念會因為這些內建的演進漸漸地在組織中形成吧!?
所以簡單來說，從當前標準的職能定位來看，DevSecOps 這類角色有點像是昔日的安全工程師加上 DevOps 工程師的味道！
有這麼簡單!!!??
這幾年在現場協助企業落地實施 DevSecOps 時，我比較容易感覺到這類角色常常就是我們半驕傲半苦笑說的一條龍工程師 再加上需要了解「安全知識」並且「知道如何將安全左移到每個軟體生命周期階段」，以便確保軟體在「端到端“交付”是安全的」。講到這兒~我不禁為這職能捏把冷汗，心裡直嘆好厲害的一個角色。
討論的過程中，有人提到應該為這些技能或知識設計成熟度，畢竟這安全龍工程師是要懂很多，但有些主題它可能只是需要懂如何與其他職能協作即可。這概念挺好的，筆者也進一步建議了可以參考歐盟的 eCF，並且會後也提供了些資料和工具，以便讓這類成熟度在設計上有更好的機制！期待後續的設計和成果，畢竟有了第一版才有後續的改善基礎 ：）
討論內容是有拍了一些，但也不知道該分享還是不分享，不如就提供個官方研究報告連結（https://www.nics.nat.gov.tw/cybersecurity_resources/publications/Research_Reports/），大家有興趣可以看看！
文末補一下企業在這類人才角色上應該考量哪些事，而這也是筆者在企業輔導時會協助企業探討並且確認的一些議題。
- 安全之於目前企業的商業影響為何？
- 這類商業影響的代價是什麼？
- 願意為這些代價提早做多少準備(花多少錢)？
- 願意為承擔多少風險？
- 在願意的投資範圍和可允許風險條件下，需要做些什麼？這些任務需要那些技能？
- 找匹配技能的人才
其實概念不難，最重要的就是正視風險然後找願意付出部分的對應人才即可。不過值得注意的是，上述問題每年或一定週期就要好好重新再確認一次，畢竟科技世界變化很快，至於變化後的職能落差，通常就是提供培訓和成長方式來協助既有人才提升或擴充人手等。如果是採用培訓的做法，那最好就是培訓和當前實際需求一致是最好的做法，通常提前太多或太晚都會使得培訓價值減損。
題外話！在會後也被諮詢了關於 #隱私設計 議題，這大概是筆者最開心的一個主題，畢竟四年前就開始熱衷於這個議題，也去企業做過培訓，但這議題真的又更加不容易。畢竟不由分說“I agree”，好像市場上供需雙方都感覺還行…llOrz，但不管如何啦！能夠看到 #個資保護 的意識逐漸成長，還是覺得很開心，期待之後的討論和推動囉~