【臺灣資安大會直擊】沒弄清楚DevSecOps流程反模式，靠AI也解不了四大根本問題

針對這波企業想用AI來強化資安的浪潮，靖本行策執行長盧建成認為，AI只是讓問題變快，不代表責任或決策變得更清楚。

早在AI資安爆紅之前，過去幾年，企業最夯的話題是DevSecOps，因為DevOps在臺發展十年，逐漸成了企業開發的主流方法論，但是速度變化了，安全的壓力也隨之而來，企業開始積極在開發流程的不同階段，採用各種DevSecOps資安工具或機制。

但是，有些企業推動資安左移時，雖然將資安責任左移，也提供資安培訓，但是，人員的能力不見得足以因應不斷變化的資安問題，像是新型態風險的判斷、最新漏洞的修補等，開發團隊接手了資安責任，卻沒有足夠的能力採取行動。

也有企業積極導入各式各樣的工具，從SAST、SCA、IaC Scan、容器映像檔Scan到SBOM監測工具，串接到不同的開發流程中，蒐集了大量Log，企業IT人員卻無法進行有效的分析，最後只是將資料儲存起來，沒有真正發揮作用。

測試到部署中間的資安把關，也是DevSecOps重要的卡關點，但常見有些IT團隊只同意小幅變更，而將重大變更交給主管的特簽，或視為特例來放行，而不是從風險角度來拒絕。這類例外、特簽不只讓資安責任邊界更加模糊，也讓資安控管決策在日後難以追蹤。

企業上雲後，IaC基礎架構程式化的做法，雖然可以透過自動化來簡化維運，但是，遇到開發團隊、維運團隊和資安團隊三者負責範圍交會的安全問題，不同團隊從不同立場各自解釋，往往沒有人對整體安全性負責。

上述這些都是臺灣企業推動DevSecOps時的反模式，長年擔任企業IT顧問的盧建成認為，DevSecOps在台灣沒有一條像DevOps那樣清楚的成長曲線，而是隨著DevOps成熟、雲端複雜度上升與安全風險壓力的增加，被動地演化出來的一種補救性整合。

「補救性整合的做法，帶來影響是補得越多、越麻，開發系統也越遲重。」他強調。

生成式AI技術和工具更加成熟之後，不少企業開始想用AI解決DevSecOps成效不彰的困境。但是，威力強大的AI工具，雖然可以彌補IT人員的能力不足，像是用AI來解釋資安告警、幫忙分析根因、提供修補建議，但不代表AI可以承接責任。或有企業用AI來強化龐大資安資料的整理，彙整SBOM、SAST報告，製作摘要報告，協助找出系統和漏洞的關聯，但不等於AI能夠理解了企業所面對的風險。

生成式AI助手可以加速IT工作的執行，像是自動產生PR或IaC的修正，提供自動化修補的建議，但是無法建立一套治理實踐。或是用AI來整理風險資訊，要求AI列出風險處理優先順序，提供建議方案，但是AI只能提出建議，而無法負責最後的決策，還得由企業IT自己做出決定。

盧建成歸納，責任定義、風險接受標準、例外與特簽機制、治理與追蹤，這四件事，AI解決不了。

他上述提到的DevSecOps反模式的共通點是，責任被往前推，能力沒有一起建立，規則也無法支撐決策，資源更不足以消化風險。「誰能承接風險的責任，如何判斷風險、資安決策有何基準？決策執行或放行後如何追蹤等。」這四大問題，不會因為AI而獲得解決。

像是誰要承擔後果、對企業來說可以接受什麼後果？什麼情況可以例外，誰可以批准例外、決策是否被執行、例外是否遭到濫用等，這些問題都用AI解答，得由企業自己面對才能找到自己的答案。

盧建成建議，人員要能承接責任，而不是被指派，風險也能被理解而不是一昧分類，資安控管也不是分辨紅綠燈來篩選，而要將控管視決策的過程，並讓這些決策的結果可以追蹤，而非一次性的處理。

「DevSecOps不是將各種安全機制放進流程，而要讓安全成為日常運作的一環。」盧建成建議。