我個人其實蠻高興 DevSecOps 開始被關注，越來越多開發者和企業重視資安。但 DevSecOps 中的這個「Sec」其實不好實踐，背後連結到非常多東西。
這也是我會想來寫 DevSecOps 的原因，雖然無法一篇文章就寫完，但就一起慢聊包含 DevSecOps 的廣大資安世界。
如果你說 DevOps 拆開來會是開發（Development）、維運（Operations）和品質保證（Quality Assurance），那 DevSecOps 就是在這三者都加上資安。從程式碼安全、基礎建設（Infrastructure）、雲端服務、部署環境都考慮到資安，當然包含「人」也是。
儘管看起來不容易，至少我們相信持續發展 DevSecOps 會讓企業帶來好處：「讓資安跟上開發速度、並且讓產品更安全」。
今天這篇是一篇概覽，來跟大家分享 DevSecOps 的做法和挑戰。
DevSecOps 的定義
單純表述的話其實就是「在你所認為的 DevOps 中導入 Security」。
我曾經嘗試去問人什麼是 DevOps，雖然每個人都給我不同的答案，但 DevOps 有幾個特點是大家一致認同的：「敏捷和自動化」，也有人會再提到這是一個「文化」。我覺得 DevSecOps，其實就是在這樣 DevOps 的敏捷、自動化、文化下，讓大家都有權力和責任來實踐資安。
而且資安是被內化的，而不再像傳統方式只是一個外掛模組後續加上這個資安功能。像是門匠已經不是先做好門板然後在外面加釘一個栓頭，而是把門和鎖一起考慮設計並且實作。
資安風險
有體驗過 DevOps 的人會知道，開發速度不一定會跟安全性成正比，可能還會成反比。而潛在資安風險就跟技術債一樣，慢慢累積最後一次爆發。
就以企業角度來說一定會有資安風險，只是你選擇忽略它、或是控制它。
例如對大公司來說，有價值的東西通常是那些「被洩漏出來的話」會很難善後的、或是主管會被釘在牆上的那些機密和 Know-How。對小公司或新創來說，客戶資料外洩（失去客戶信用）、MVP 核心價值和功能原始碼洩漏會是潛在資安風險。
為什麼會需要 DevSecOps
但敏捷開發下，生存都來不及了怎麼顧資安？
且就算新創想預防資安風險上的金錢損失，但資安要做的事情多得嚇人，傳統光是「做資安的成本」幾乎就大於「風險的損失」，有什麼辦法做？
DevSecOps 可以做：和 DevOps 一樣自動化來減少時間與人力成本，並且控管企業的資安風險損失。
因為 DevSecOps 也發現這樣的問題，所以就像 DevOps 文化推動一樣，「不再是大量的操作員耗費人力」來築高塔，而是所有人都有權責來做資安，並且快速、持續疊代成長，「不再是單方面推動資安」，而是讓資安基因植入在產品、基礎建設、流程、和每個人的行動上。
面臨的挑戰
但在 DevOps 環境下做資安，其實有三個大挑戰：速度、環境、和持續。
- 速度：我們需要弱點掃描、滲透測試等等資安測試，但開發太快了，資安測試無法跟上步調，需要另一種「專門為 DevSecOps 的資安測試」。以及在快速進行資安決策時，該如何精準量化風險和評估分配資源？
- 環境的威脅：DevSecOps 的環境、雲端、微服務架構都和傳統的不同，你真的知道駭客怎麼攻擊？ 如果不夠了解現在的 DevOps 常用工具和這些環境資安上的威脅，就無法找出真正的資安風險和針對駭客的攻擊方式做預防。
- 持續：不只在 DevSecOps，資安要怎麼在這麼快、微服務架構和雲端這麼龐大的情況下，持續追最新攻擊技術？並且開發的功能快速增加和減少的情況下，持續保持資安的使用性和效果？
面對這樣的問題，我們要從三個角度來看：
我們後面將會分成三章節：實踐 DevSecOps 的方法論（技術面），以及在開發階段（流程面）裡每個階段著重的資安項目，最後是不可或缺的文化和理念（人）。
方法論
在技術角度上，我們這邊會提出幾個方法論來試著解決這些上述問題，給大家參考。但畢竟方法會隨時間和需求改變，適時和快速調整做法也許也是 DevSecOps 中的一環。
為了讓資安能因應 DevSecOps 的特質，我們在設計資安時可以從三種方式來進行：
- 標準化（Standardization）：像前面問題提到的「量化風險」，其實可以有一些標準可以使用，像是嚴重性評估量化標準：CVSS（Common Vulnerability Scoring System）。或是分類資安測試項目，就可以使用 OWASP Testing Guide 這樣的列表幫助我們進行資安測試。至少有個公認標準，而不是自己憑感覺說。
- 模組化（Modularization）：像是架構即程式（IaC，Infrastructure-as-code），目的是為了讓我們更好重複使用通用的設定，並且也讓日後可以審計（Auditing）。資安也需要變成 Security-as-code，把資安盡可能也寫成程式和模組化，不管是測試或是資安架構、功能，它也可以讓我們持續疊代跟上開發的速度。
- 自動化（Automation）：這個相信大家都知道。但資安要怎麼自動化？至少在 CI/CD 流程中的資安測試可以，而在「測試結果的過濾（Filtering）也要自動化」（或是你想要很崩潰地看上千條問題）、日誌收集、監控、資安配置檢查、回報與反應等等。盡可能把自己要做的資安事項和流程自動化，不僅符合 DevOps 理念也減輕自己工作量。
舉個例子 － Security Linter
想在現有流程導入資安，第一個簡單的方式也許就是 Security Linter 了。或是更常見的名字：靜態應用程式安全測試（SAST，Static Application Security Testing）。
但如果你嘗試直接把 SAST 工具加進 CI/CD 裡，會發現它可能動不太起來。要麼是整個流程延長好幾倍時間、要麼是資安問題噴出一堆（做資安幾乎會遇過處理上千條的案例），但大部分都是偽陽性（False Positive）。
我們依然需要弱點掃描和滲透測試，但是用另一種方式呈現。我們依然需要 SAST，但我們需要另一種專門為 DevSecOps 的 SAST。像在 DevSecOps 裡的 SAST 通常會在 CI 階段裡實作，目的是確保基本資安門檻，所以需要「高精準度」和「快速」掃瞄來應付程式碼頻繁上版的問題。
確定要導入 SAST 時，也許先該衡量「要加入哪些測試項目？」SAST 測的規則其實不少，列出「我們需要的項目」並且是「嚴重性高」的優先（舉例像指令注入，Command Injection）；接著模組化 SAST 方便日後增加更多測試規則與疊代；最後把我們要的自動化加入流程中，持續優化讓每次結果可以在數分鐘甚至數秒掃完，並且自動化過濾降低偽陽性發生。
光是 SAST 這件事其實可以再談上好幾個小時，而真正落實它也不是幾天幾週的事情。大致來說，用標準列出事項和優先順序、建立模組重複使用和疊代、最後把整條流程自動化。
開發流程的五個階段
有了技術面的方法後，第二個面向是「流程」。為了落實 DevSecOps，我們可以運用技術的方法論套用在開發流程上。而在開發流程導入資安，大概可以拆成五個不同的階段，每個階段要執行的資安和目的也不同：
- 準備階段（Preparation Phase）：在所有實作開始前的規劃，不用像瀑布式開發一樣長時間規劃，可以用敏捷式快速規劃和修正。我們需要準備資產（Assets）清點、威脅模型（Threat Model）、風險評估（Risk Assessment）、量化等等。像是清點第三方函式庫、雲端服務，接著規劃攻擊者可能的攻擊，定義出潛在問題、並且量化和選擇防禦方法。
- 設計階段（Design Phase）：接著在設計系統架構時，預設有資安系統架構的考量，以及運行時自我保護（RASP，Runtime Application Self-Protection）的機制設計等等。也包含存取控制（Access Control）、機密資訊管理方法等等，都需要在開發前設計好資安。
- 建構階段（Build Phase）：通常這會是在大家俗稱的 CI 階段。其中也包含前述所說的靜態掃描（SAST）、並且也對程式碼資安檢查（Code Review）。靜態掃描要盡可能「快速且準確」地幫助開發者檢查一些基本資安問題，並且程式碼要合併整合前由人來確認資安邏輯等等。
- 部署階段（Deploy Phase）：可想而知這應該常見是在 CD 階段。我們可以做更多與環境互動的測試：第三方函式庫檢查（軟體組成分析，SCA，Software Composition Analysis）、動態測試（DAST，Dynamic Application Security Testing）。以及部署時的資安配置：主機環境與系統配置、機密資訊配置、權限、網路存取等等。
- 執行階段（Run Phase）：最後是真正上產品的執行階段，是否能抓住第一線事發狀況，「監控（Monitor）」尤其重要，並且運行時自我保護（RASP）的作用也會在這發揮出來。我們通常會需要對網路的監控、流量分析、日誌收集與分析等等。主要目標是威脅偵測（Threat Detection）與反應（Response），主動發現潛在威脅並且快速處理。
我們可以用前述的三個方法論：「標準化、模組化、自動化」來實踐每個階段需要的資安。而裡面每個階段涉及的東西其實比原本 DevOps 又再多了不少資安項目，目前先列出大致項目所在階段，之後我們再來好好聊聊實作細節和一些眉角。
DevSecOps 的文化理念
前面說了很多技術和流程的東西，但在 DevSecOps 的核心和推動其實關鍵都是在「人」，就和 DevOps 文化一樣。
資安文化需要由上而下
有趣的是，資安可能比 DevOps 還要更強烈需要由文化和人來推動。畢竟 DevOps 讓人更方便，但傳統資安像是「門神」的做法：這個不行那個也不能，會讓工程師覺得是在找麻煩。
要讓大家推動 DevSecOps 就要先贏得大家的心。我們要讓大家知道做資安不是來搞人，我們是一起來把事情做好。
但在推動資安的時候，由上而下就顯得重要，就算是推動一般的資安意識，從下面基本員工往上推動其實就也跟斜坡推大圓石一樣非常困難。
如果可以，當然是開發團隊和資安團隊的老大起身推動：主動加入資安、制定透明且可以達到的目標，並且讓工程師和資安人員合作，才會有上面提到的 DevSecOps 方法，和實踐每個階段的資安做法。
資安團隊
DevSecOps 一大部分是要讓開發團隊和資安團隊彼此合作。傳統上，資安人員通常不太了解開發，而開發人員也可能沒比資安人員精通資安。DevSecOps 也許是希望能打破這條線，將「做資安」這樣的權限與責任交給大家，讓開發團隊和資安團隊都需要「一起」來主動實踐資安、一起面對和處理漏洞、一起讓產品更安全。
資安團隊在 DevSecOps 也同時是顧問的角色，像是指路人，提供適合 DevSecOps 的資安工具、評估風險和「真正知道攻擊威脅」的人。雖然會依照公司不同規模和組織有所不同，但 DevSecOps 需要這樣的角色來實踐資安，這個角色可能是資安團隊、資安工程師抑或是白帽駭客。
內化，由內而外
就算已經有資安團隊負責資安事務，但就如同最一開始提到的門匠一樣，如果能把門和鎖思考在一起設計實作一定會比分開做還要好。
DevSecOps 的合作理念，也是希望資安不是由外部團隊額外掛上，是由內而外的延伸。
與其做一個資安功能，不如把功能做得更安全；比起資安團隊單方面推動資安，不如全體團隊一起將資安實踐；比起門神的方式預防，不如全體的資安意識並且持續精進防禦。並且由人開始，「主動」推動流程和技術，實踐我們的 DevSecOps。
DevSecOps 現在還是一個很新潮的名詞，說來也沒有完整的定義或誰說得算。這篇算是一直以來我們自己在敏捷開發和資安上的平衡和取捨，並且不斷優化後的一些想法。
提到的方法論和各個階段需要的資安，我覺得隨著時間演進這些還是會改變的。而且也會因為組織大小和需求會有不同的特化。或許 DevSecOps 也是希望我們能保持這樣的彈性，就算沒有人提過 DevSecOps，我們也會嘗試摸索在敏捷開發或現有流程中，與資安取得平衡點。目的也就是在現有的開發環境上導入資安，並且讓資安更主動地且更有價值地被顯現出來。
至於每個資安項目和方法，真的實在太多眉角和內容可以討論，我們今後也會慢慢寫成文章跟大家分享。如果你也和我一樣希望讓台灣的企業更好更安全，可以一起分享文章，或追蹤下方 FB 粉專，也歡迎寄信跟我一起聊天談資安。