我個人其實蠻高興 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,資安要怎麼在這麼快、微服務架構和雲端這麼龐大的情況下,持續追最新攻擊技術?並且開發的功能快速增加和減少的情況下,持續保持資安的使用性和效果?

面對這樣的問題,我們要從三個角度來看:

tc

我們後面將會分成三章節:實踐 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,我們可以運用技術的方法論套用在開發流程上。而在開發流程導入資安,大概可以拆成五個不同的階段,每個階段要執行的資安和目的也不同:

  1. 準備階段(Preparation Phase):在所有實作開始前的規劃,不用像瀑布式開發一樣長時間規劃,可以用敏捷式快速規劃和修正。我們需要準備資產(Assets)清點、威脅模型(Threat Model)、風險評估(Risk Assessment)、量化等等。像是清點第三方函式庫、雲端服務,接著規劃攻擊者可能的攻擊,定義出潛在問題、並且量化和選擇防禦方法。
  2. 設計階段(Design Phase):接著在設計系統架構時,預設有資安系統架構的考量,以及運行時自我保護(RASP,Runtime Application Self-Protection)的機制設計等等。也包含存取控制(Access Control)、機密資訊管理方法等等,都需要在開發前設計好資安。
  3. 建構階段(Build Phase):通常這會是在大家俗稱的 CI 階段。其中也包含前述所說的靜態掃描(SAST)、並且也對程式碼資安檢查(Code Review)。靜態掃描要盡可能「快速且準確」地幫助開發者檢查一些基本資安問題,並且程式碼要合併整合前由人來確認資安邏輯等等。
  4. 部署階段(Deploy Phase):可想而知這應該常見是在 CD 階段。我們可以做更多與環境互動的測試:第三方函式庫檢查(軟體組成分析,SCA,Software Composition Analysis)、動態測試(DAST,Dynamic Application Security Testing)。以及部署時的資安配置:主機環境與系統配置、機密資訊配置、權限、網路存取等等。
  5. 執行階段(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 粉專,也歡迎寄信跟我一起聊天談資安。