實踐DevSecOps的關鍵心法

這篇文章內容原本是我受邀參加iThomem於2022/8/31所舉辦敏捷高峰會(Agile Summit 2022)的金融業敏捷對談(Panel Discussion)，針對主持人的指定題所準備的。會後iThome又邀請我以相同的主題於10/18舉辦的Kubernetes Summit做專題演講。由於這兩個會議的聽眾屬性稍微有些不同，所以我也增加了一些比較技術性的內容，例如本行近期運用AWS及OCP建置的混合雲線上申請系統、 DevSecOps工具(如CSA、IAST、RASP及Chaos Monkey)的介紹及NIST SP800-190容器安全參考指引等。以下為正式的演講內容文稿。

為何數位轉型導入新技術需要跨越規模化鴻溝

DevSecOps對大多數台灣的企業資訊主管是一個很新的議題，這點可以從今年iThome CIO大調查得到驗證。在這份調查所公布的企業新興技術雷達圖中可以看到，DevSecOps是列在崛起中的AP架構與開發技術，有實際導入經驗的企業必然還是少數。

DevSecOps對不同類型的導入企業主體其困難度其實是不同的。對網路原生的新創公司來說，若平常就很習慣運用公有雲的CI/CD自動化工具，要打造培養出具快速、穩定及安全能力的DevSecOps團隊是相對容易的。但是對傳統企業，特別是傳統銀行來說，這件事就像是要末代武士變成捍衛戰士，由人工加油變成空中加油一樣艱鉅，涉及到要改造人員心態、組織文化、工作流程及技術革新 (圖1)。同時這樣的變革最終必須要做到規模化，否則不上不下的狀態，只會讓銀行未蒙其利、先受其害。對傳統銀行來說，DevSecOps是龐大數位轉型進程中的一塊拼圖，要談傳統銀行導入DevSecOps的心法，就不能去脈絡化不談數位轉型。

不過我們先來探討為何導入DevSecOps與數位轉型的其他努力一樣，最終都必須要做到規模化，以及要規模化主要的瓶頸為何？

這張常態分佈的曲線圖(圖2)是Everett Rogers在1961年提出的創新擴散理論，是指一項新的觀念、事物、技術引入社會體系時的滲透過程。一項新技術在社會體系擴散是一個漸進的過程，開始通常是從對技術有狂熱的創新者及較有遠見的早期採用者開始萌芽。驅動這群人的因素通常不外是技術創新的本質，或是有遠見的人預見採用新技術有潛在的龐大效益，因此這群人願意在前景不明的情況下，承擔風險嘗試發展新的技術及其應用。

但在常態分佈下的社會體系，這類人約略只佔整個體系人口的16%，要真正產生變革，就得從這群早期採用者再向外擴散剩下的84%人口。但這群人多半比較務實、保守，甚至對新技術抱持懷疑態度，因此要說服他們就不能只從技術創新或未來潛在利益的角度出發，而必須向這84%的人證明，新技術遠比他們習慣的技術簡單易用，甚至是讓他們看到其他人採用新技術已有巨大成效的明確證據，讓他們理解採用這些技術已是社會潮流，而非高風險的跟風行為。

所以素有矽谷策略大師的傑弗瑞‧摩爾(Geoffrey A. Moore)在其所撰的「跨越鴻溝」一書中，特別指出，在這兩個分佔16%與84%人口的早期市場與主流市場間，存在這一個必須要跨越的鴻溝(Chasm)。這個鴻溝也是許多傳統企業在推動數位轉型時(或資訊部門要導入DevSecOps)會面臨的巨大關卡。因為要在企業內甚至從外部新聘，找到16%具願景與新技術有熱情的員工通常是相對容易的。一開始企業可以期待這群數位轉型的專責員工作出初期的成果，但終究這16%的員工必須做出成績，才有本錢跨越鴻溝去說服及影響其他84%員工開始改變。

如果這道鴻溝跨越不過去，企業也不可能讓16%的員工將企業內其他84%人力的工作都扛下來。長此以往，兩個截然不同價值主張與工作文化的團體就會開始產生摩擦，甚至有績效及公平性爭奪的問題產生。所以對已有一定規模且運營夠長時間的企業來說，當有較革命性的變革發生時，別無選擇一定要想方設法突破規模化的難關。

回到實踐DevSecOps心法，從剛剛的論述我們可以看出，要在企業內部進行帶有創新技術成分的重大變革時，真正困難的關鍵點通常並非技術，因為對84%的受眾來說，新技術是否優異並不是他們會改變的主因。真正困難的關鍵點是16%的先行者首先要能夠克服熟稔新技術本身複雜性及不確定性，先做出明確的成績，讓已經長時間習慣既有工作方法與技術的員工相信及認同用新方法與新技術對其個人及組織整體帶來的效益確實顯著提升，企業與員工不能再落人後，必須開始作出全面的規模化改變。

既然是規模化的巨大變革，就必須從企業層級的高度，有策略的逐步推動。以第一銀行(以下簡稱本行)的數位轉型為例，本行是先推動產品數位化的策略，以打造iLEO數位副品牌及提升數位行銷能量作為先行者。推動三年並有成效後，再帶動全行各部門動起來，建構5大數位核心能力(5D)推升全行數位化龐大需求，讓全體資訊部門感受到必須變革的壓力，著手打造能夠承載我們找到下一片綠洲(OASIS)的現代化資訊基礎建設，取代從Bank 2.0時代建置運行近40年的龐大銀行核心系統。最終我們希望全行能成功轉型為在雲端生態系(Ecosystem)中，具備精實敏捷(Lean Agile)與創新(Incubate Innovation)能力的科技金融(TechFin)企業，而在這個過程中，我們才能順水推舟推動DevSecOps成為精實敏捷能力的一環(圖3)。

這14項數位轉型策略方針不光是讓我們的員工知道為何而戰的手段，同時也是本行推行敏捷企業層級的待辦清單(Backlog)，因為這些方針不可能同時執行，而必需要如同敏捷開發一樣迭代進行。同時，我們希望在打造現代化資訊基礎建設的過程中，資訊部門將能夠自發性的體認到培養精實敏捷的DevSecOps是現代化資訊部門不可或缺的能力。

接下來我們更進一步詳細說明我們認為企業實踐DevSecOps的四項關鍵心法：

• 轉型改變的核心永遠是人
• 持續創造供需以趨動變革
• 由新與小實驗快速的資安
• 團隊自主成為學習型組織

轉型改變的核心永遠是人

首先，DevSecOps雖然涉及人員、流程及技術，但是最核心的還是人員。員工若沒有意願，不能自發性的認同，改掉企業傳統的穀倉式組織架構與漫長接力的瀑布式運作流程(圖4)，最終企業為了導入DevSecOps採購的工具與花費時間改造的流程，最後還是會因為員工的陽奉陰違浪費掉。

DevSecOps如同Scrum、看板等方法論，是要打破企業傳統的穀倉式組織架構與漫長接力的瀑布式運作流程，以5~9人的產品融合團隊敏捷的運作。團隊要如同海豹部隊一樣，雖然團隊成員各有專業，但也能因應需要隨時相互支援，並改變為以對成果(Outcome)負責，而非傳統資訊專案僅是對產出(Output)負責(圖5)。尤其DevSecOps是要將資安閘門打破向左移分散，在DevSecOps對速度與規模化的要求下，這些工作將無法由資安團隊集中執行，勢必要轉變為由開發人員在第一線執行，這些巨大轉變需要參與DevSecOps的員工都能夠認同與實踐。

但員工的認同與實踐不是高階主管一聲令下就能達到，必須要讓員工能夠知道為何而戰。同時也不能躁進，必須要階段性的推進，確保在每個階段都夠讓員工看到這麼做的好處。接著我們就以本行的經驗為例，說明我們如何在企業數位轉型的脈絡中找到開始推動DevSecOps的時機。

以本行的經驗為例，本行企業數位轉型的第一個迭代(數位轉型1.0)是從年輕客群的需求 Outside-in，驅動以小規模的產品敏捷團隊打造 iLEO數位品牌，這時資安的作法與過去並無太大不同。

歷經兩年多的努力，隨著客戶行為轉變與疫情的加速，讓全行體認到，必須要進行大規模的業務變革，搭配全面現代化的資訊架構才能夠真正滿足數位時代客戶。這時資安不單要左移嵌入在軟體開發流程，還需要更往左參與創新業務變革的資安架構設計。

我們希望經過數位轉型2.0後，本行可以真正成為軟體定義、AI決策及數據驅動科技金融公司，而此時資安本身也需要被數位轉型(圖6)。資安本身的數位轉型不是本次研討會探討的重點，所以我們還是把焦點放在數位轉型2.0帶出的敏捷資安議題。有興趣進一步了解的人，可以參考本人另一篇文章：數位轉型下的資訊安全。

在數位轉型1.0的階段，參與的部門及人員通常是屬於16%對新技術新事物有熱情，也願意承擔風險的一群人。但我們也必須確保轉型的工作能得到董事會與管理高層的支持。同時管理階層必須適時參與，協助解決轉型過程的跨部門協調與資源衝突，因此本行在組織架構上，特別設計了兩個核心機制，作為推動數位轉型的雙引擎(圖7)。

第一個機制是針對資訊現代化方針成立的資訊發展委員會。過去本行資訊相關的策略、專案投資等等都是併在經營決策委員會內討論，但過去常常因為議題範圍廣泛，無法單獨針對資訊議題進行深入的討論。因此我們經過董事會同意，成立了資訊發展委員會，每月由總經理親自主持，將資訊相關的投資、策略、資安的議題集中討論，並要求所有的業務副總及處長等高階主管均需出席。

第二個機制是針對產品數位化與市場創新化，每月召開的新興支付與數位發展會議。雖然這個會議未達委員會的層級，不是所有部門都參與，但是這個會議仍然是由總經理親自主持，與數位產品開發直接相關的部門主管都要共同參與，視議題也會邀請其他部門參加這個會議。

透過這兩個機制，我們確保了數位轉型方針衍生出來的跨部門議題都能夠在單一平台，從營運高層角度進行討論進而達成共識，有了共識往下才能拉的動業務部門的戰鬥部隊，才能真正產生數位戰鬥力。而真正要發展出創新的商業模式、開發出年輕客群接受的數位產品，就必須有真正投入戰鬥的戰術組織，也就是iLEO數位產品小組。數位產品小組是跨部門的數位產品開發團隊，每個產品小組通常在5~9人，成員包括產品單位的產品負責人(Product Owner)，搭配UX/UI設計師、軟體開發測試工程師及數據分析師來開發。

數位產品小組與過去資訊系統以專案開發的方式有很大的不同。過去銀行資訊系統一旦系統上線後，專案團隊就解散了(規劃/建置/運行)，但產品開發團隊則是產品若沒有下線，就會一直存在，以因應市場的變化與客戶的需求。此外數位產品小組必須學習掌握客戶的使用者旅程、所面臨的痛點，以客戶為中心的原則，透過設計思維來打造最佳的使用者體驗。產品上線後，產品小組必須持續關注客戶的反應，透過敏捷開發快速推出修正的產品版本，確實回應客戶的需求。

從2018年開始打造iLEO的數位產品團隊肩負兩個重要的任務： (1)打造第一銀行數位副品牌，年輕化百年老店形象吸引數位族群、(2)透過自行開發的過程來催化行內的數位轉型，並由產品團隊自發性的設計出許多創新功能，提升數位創新能力，例如(圖8)：

1. 「滑滑轉帳」是iLEO的招牌功能，本行當時以最夯的寶可夢直觀的操作方式，創造出金融業首創用滑的轉帳，平均15秒就能完成一筆轉帳交易。
2. 「夢想帳戶」則是為了解決現在年輕人存錢不容易的痛點，利用系統自動化幫忙累積財富。
3. 「多人收款」利用系統亂數的代碼，讓收款方可以自動對帳，也讓付款方可以跨行進行付款，創新技術領先同業的拆帳功能。
4. 另外，本行跟「湊伙投資」的金融新創夥伴，一起在監理沙盒中努力，成功推出小資族也能團購只有專業投資人才能購買的國外債。

本行自2018年組成的iLEO數位產品團隊，逐步建立了打造數位產品的敏捷能力。在2020年疫情發生後，這個團隊更能快速打造線上申辦系統，配合政府的時程要求提供勞工紓困貸款及振興五倍券。尤其去年的勞工紓困貸款，從6/15到6/18短短四天申請期間，本行所收到超過11萬件的紓困申請案中，95%的申請都是走線上(前年僅20%為線上申請)，只有5千多件是走分行線下。以本行188家分行來計算，一家分行一天平均受理不到8件(7.25件)。而且本行的線上勞工紓困系統從申請、對保、聯徵發查、送信保核保到最後撥貸，完全都在線上完成。

能做到全線上化的作業，主要得力於幾年前我們就已經看到傳統金融機構數位轉型的必要性，在疫情發生前本行就已經積極在推動數位轉型。不過在勞工紓困起跑的當天，由於突然大量湧入的線上申辦民眾，造成了網站當機的混沌狀況。

發生壅塞當機的當下，本行一時還無法釐清因果關係，因此當時馬上採取擴大頻寬及伺服器容量的止血行動。稍後釐清狀況，發現是資料庫伺服器容量不足，本行評估若要因為這類突然會有暴衝容量需求的業務，在平時就備妥龐大的資料庫虛擬伺服器是不合成本的，因此決定應該要改變資訊架構，在公有雲建立一個可以隨需擴充容量的雲端取號系統，而在地端以輕量的容器化架構實現各類線上申辦的服務(圖9)。

雲端與地端間可以達成流量控制，在地端有空餘的處理資源時，再通知已在雲端抽號的客戶進行申辦手續。這個過程資訊部門需要學習實驗在公有雲架設可隨需擴充的線上抽號系統，並經過測試後找出最佳的系統架構方式。同時也需要重新規劃開發地端的容器化申請平台，可以適用未來各類線上申請的服務。當然在這些過程中，會有公有雲、容器化的資安議題出現，需要資訊與資安部門攜手解決。但經過這個過程後，也讓本行的資訊部門體認到，在面對未來數位業務的發展需求，建立現代化可隨需擴容的雲端原生運算架構已是刻不容緩的工作。

持續創造供需以趨動變革

經過前述的過程，本行也去年底召開了數位轉型2.0的共識會議，其目的就是希望能夠跨越數位轉型鴻溝，帶動全行前中後臺所有部門都啟動數位轉型，進入數位轉型2.0的階段。在數位轉型2.0的階段，如果轉型的正確，業務端將會產生較以往更大規模的價值創造需求，同時業務端也希望可以加速價值的交付。此時包括資訊與資安就會開始面臨到變革的壓力與挑戰。

資訊與資安團隊必須與產品融合團隊合作，逐步揚棄傳統的瀑布式應用程式開發方式，採取結合了設計思維、Scrum/看板及自動化DevSecOps的敏捷開發與運維方式，才可能滿足價值交付的速度要求。(圖10)

而DevSecOps更需要結合Cloud Ready的容器化基礎架構，讓企業架構維運發揮如虎添翼的效果。亦即大規模的業務變革需求驅動了傳統銀行全新世代的巨大資訊變革，兩者結合才能產生Inside-out的規模化價值創造。全新世代的資訊架構(圖11)將由傳統大型主機主導的大核心小周邊，轉變為敏前台、大中台、穩後台、小核心，也就是以微服務及容器化為應用組成及運作單元的Cloud Ready架構，也是DevOps/DevSecOps可以朝向持續整合及持續部署的技術核心關鍵。

由新與小實驗快速的資安

當然傳統銀行要打造全新世代的Cloud Ready資訊架構絕對是一個浩大的工程，在施行時也必須要運用敏捷迭代的觀念逐步達成。本行的核心系統與資訊現代化目前規劃分成三個階段：短期架構先行、中期逐步瘦核及長期逐步轉核。在迭代的初期，也就是短期架構先行的階段，除了挑選外匯匯入來驗證Cloud Ready的架構與應用開發方式外，也同時開始實驗如何將資安左移融合到DevOps的流程中，驗證快速資安的概念如何落實。

在建立DevSecOps時，不能只聽廠商提供的解決方案，然後就一股腦的照做，企業還是要有參考的架構。例如Gartner的DevSecOps toolchain列出了DevSecOps流程中每個階段應該採行的資安工具與活動。此外資訊長或資安長在導入DevSecOps時必須要有一個認知：DevSecOps的核心是在做"快速"的資安(圖13)。

DevSecOps的工具鏈所整合的工具與傳統的資安工具，從功能來比較其實並沒有太大的差別，所以若透過DevSecOps流程開發出來的是軟體A，透過傳統瀑布式軟體開發流程所開發出來的是軟體B，我們未必能導出A的弱點要比B來的少這樣的結論。但是因為導入DevSecOps與CI/CD的自動化流水線，透過責任共享及工具的自動化，我們就能達成高效率、高可靠性軟體交付目標，在發現有軟體漏洞時，就能夠更快速甚至自動化的應變，縮小因為軟體弱點造成的資安空窗期。

不過目前在市場上，有幾個較創新的資安產品，預期對於DevSecOps的發展將有正面的影響，例如SCA、IAST、RASP及Chaos Monkey。

在DevOps中，大部分的程式是重用自開放源或第三方的程式庫、框架及元件。在確認(Verify)階段，通常會以工具掃描版本庫中元件的已知弱點及錯誤組態，而具備治理能力的軟體組合分析(SCA)可以在元件被下載時，就落實企業的開源軟體政策，讓IT部門主動確認程式碼，並創建一個“已知良好”的軟體元件庫，進一步供開發者利用，且這個確認過程可以被自動化，大幅降低軟體元件管理成本及第三方程式風險。

要掃描自行開發的程式，可以利用相當於傳統弱點掃瞄的白箱與黑箱工具的靜態應用安全工具(SAST)及動態應用安全工具(DAST)，還可以考慮運用互動應用安全測試(IAST)工具。IAST與偵測(Detect)階段可以使用的RASP均利用了runtime instrumentation的技術，概念上可以用汽車電腦檢測儀來類比，透過檢測儀，汽車維修技師可以快速得知故障點，馬上進行著手維修。而當我們用IAST來檢測程式時，當我們對應用程式輸入一個含有SQL Injection的字串，IAST可以監測發現這個字串在應用程式內部經過的路徑，並找出這個路徑中何處會造成SQL Injection可以攻擊成功的弱點處，快速進行程式修改。RASP則進一步在程式上線執行時，發現有SQL Injection時，可以介入啟動runtime的保護。

Chaos Monkey是混沌工程的一種工具。由於現今雲端與網路化的系統規模越來越大，各種模組間透過API動態連結，這樣的複雜度遠超出工程師與架構師所能夠完全掌握的。Chaos Monkey是刻意向系統注入故障(比如延遲、CPU故障或隨機結束某個執行緒)，進而找出系統潛在的弱點，並增強IT團隊應對故障的能力。

團隊自主成為學習型組織

導入K8s容器化技術及DevSecOps是需要時間讓團隊逐步提高成熟度的。團隊必須要掌握導入的容器技術可能存在的資安風險，及早建立控制措施，並要有評量指標知道自己目前的能力成熟度水準。

NIST SP800-190是美國國家標準和技術研究院發表的容器化安全議題參考指引，其內容詳細列出了運用容器技術的整個生命週期中的五大關鍵部位，包括映像(image)、註冊管理(registry)、編排器(orchestrator)、容器(container)及主機作業系統(Host OS)等，可能存在的風險，並針對這些風險提出可以採行的控制對策。此外團隊還可以搭配CIS Kubernetes Benchmark，讓系統管理員、安全和審計人員建立K8s安全的配置基準線(圖14)。

在成熟度方面，Google的DORA Metrics評估的是DevOps的四項關鍵指標：部署頻率、改版交付時間、服務平均恢復時間(MTTR)及改版失敗率。部署頻率和改版交付時間是用來衡量開發團隊的開發速度。服務平均恢復時間和改版失敗率是用來衡量交付軟體的品質和穩定性。這四個指標都可以透過挖掘開發團隊使用的DevOps工具得出。

DSOMM是OWASP正在進行的專案，它是一套可以由GitHub下載的DevSecOps成熟度自評工具。透過DSOMM，團隊可以知道DevSecOps中各種活動的相依性，以及導入實施的難易度及價值，讓團隊可以依自身狀況排定實施優先序並逐步提高成熟度。

最後強調一點，產品導向的DevOps融合團隊是對Outcome負責，而非傳統的資訊系統專案是對Output負責，所以融合團隊除了以能力成熟度技術性指標來指引前進的方向，還要佐以文化變革、生態系平台及數位營收及成果等KPI來衡量團隊的發展(圖16)。