創新速度是企業業務成長的動力。在創新中，包括Kubernetes和OpenShift在內的雲原生技術，雖能幫助企業加快創新並提高敏捷性，但批量自動化佈署也帶來了風險，如何針對批量自動化佈署過程中所產生的漏洞進行管理，正是其中的一個關鍵。
創新速度是企業業務成長的動力。在創新中，包括Kubernetes和OpenShift在內的雲原生技術，雖能幫助企業加快創新並提高敏捷性，但批量自動化部署也帶來了風險，如何針對批量自動化部署過程中所產生的漏洞進行管理，正是其中的一個關鍵。現今大部分的企業在靜態應用程式安全測試（SAST）方面採用成熟的作法，透過檢查原始碼來尋找漏洞，但此方法在一變動頻繁的新環境中顯然已不足夠，且目前的容器安全掃描工具也無法即時、全面應對新的安全威脅。
兩年前當Log4Shell漏洞被公開後，IT部門首要任務就是盤查受影響的服務並迅速進行修補，但企業的資訊系統錯綜複雜，零時差漏洞就是與時間賽跑，雖然大家快速地提出應變措施，但企業還是提心吊膽，因為誰都不能保證這是最後一次。
當團隊疲於盤點、解決程式中的問題時，或許也應思考如何保護應用程式不受漏洞的利用而被攻擊。如果沒有即時的保護機制，唯一可能採取的措施是在攻擊發生後進行舉證調查。最壞的情況下，企業必須向客戶通報安全漏洞和被竊盗的數據。除了事後的追蹤與舉證，當前的攻擊檢測也還存在一些缺陷，例如常被採用的WAF機制，WAF需要持續進行大量的配置工作，若設定過嚴謹則容易產生誤報，且無法應對未知的攻擊。
相較於入侵檢測系統（IDS/IPS），WAF主要著重於應用程式流量的監控、過濾或阻擋。但WAF在某些情況下存在明顯的弱點，如WAF是基於規則來運行，配置規則和潛在的排列組合需要大量的人力，導致團隊幾乎無法跟上新威脅和高度動態的應用程式環境。
而RASP解決方案適用於應用程式內部或周邊，分析應用程式的行為和流量。當檢測到問題時，可以識別並阻止單個請求。儘管RASP的概念很有吸引力，但現有的RASP方案亦存在一些待克服的問題，例如過於依賴Agent技術，在大規模、異質且高度動態的環境中提高了部署挑戰。
去年，Log4Shell的漏洞在公布最安全的版本前，和所有漏洞管理解決方案一樣，尚未有穩定版本釋出前都會有各種取捨，在與時間賽跑的情況下，第一步企業需要止血，接著才是進一步的診斷與治療，當新漏洞被公告時，企業應高度專注於營運環境中正在運行服務的「實際影響範圍」與「修補優先順序」，以免讓駭客有利用的機會。
如先前所述，RASP會是一個好的、即時的解決方案，且能進一步建議程式開發人員修改的優先順序，如此便能在與時間賽跑的狀況下協助企業因應。當然，也必須關注執行時所造成的系統資源耗用性，在資源耗用可控的同時偵測漏洞、快速確認影響範圍進而阻斷，這才是IT最高CP值的首選！
＜本文作者：何玉雲現為叡揚資訊系統直屬事業群總監＞