VISA的另一位安全主管表示：“安全團隊需要保護如此多的新環境，包括多云、無服務器和內部部署，這將極大地增加漏洞、補丁和更新量。有了這么多數據和噪音，很難像現在這樣高效，所以你有同樣的投資，但你沒有那么有效。
就Kubernetes而言，團隊必須從“偏離設計標準”的Kubernetes環境中從頭開始學習安全性，并且他們還不能“預測攻擊者可能的所有行為方式”。
噪音已成為整個云原生安全的普遍問題
作為一家風投支持的初創公司的CEO，我一直在密切關注人才和風投資金的去向。今年反復出現的一個主題是，在解決方案中投入早期種子資金，以減少云原生安全方面的噪音，提高安全團隊的整體效率。
“向左轉移安全”本應將部分負擔從安全從業者轉移到開發上，但這也降低了安全在不同環境中的可見性。
Kubernetes具有自我修復特性，可以在中斷或用戶定義的健康檢查失敗時自動啟動或重新啟動容器。但在Kubernetes的案例中，與安全相關的專業知識已經轉移到了工程領域，創造了一個罕見的、既不可能找到也不可能聘用到的、對Kubernetes內外都很了解的安全人員。
攻擊者現在使用的是與藍隊相同的快速移動、彈性強的基礎設施工具，而機器人的速度正在超過自動防御。
‘熱詞炒作’已經成為一個團隊必須應對的問題，導致安全團隊浪費時間在不同的方向上奔波。
總之，云原生應用程序開發(使用容器、微服務、Kubernetes和遷移到云)給安全團隊造成了名副其實的困境。
CNAPP示例
云本地應用保護平臺(CNAPP)是當今云原生安全領域最時髦的術語。CNAPP的吸引力在于工具整合：使用一個平臺來整合新應用程序開發生命周期中的圖像掃描、CSPM、運行時和所有安全功能。大多數供應商都聲稱自己是CNAPP，Gartner已經發表了幾篇論文，對這個主題提出了初步假設。
聽起來很棒，對吧?是的，如果真的能節省一些時間和提高效率的話。最近的Scarleteel攻擊表明，攻擊者從Kubernetes中一個易受攻擊的Web應用程序轉移到云中Kubernetes托管的環境，再到云本身，最終試圖竊取AWS密鑰并危害云賬戶。
CNAPP用戶將在單獨的屏幕和區域中顯示攻擊步驟，不會將它們相互關聯，也不會顯示任何接近攻擊者顯示的跨多個環境的流動性。
這只是安全團隊可能會說“我們的工具不會變化到外部環境中”的一個例子。
今天，云原生安全是對安全團隊效率和生產力的削弱。但是，作為一項頂級的工程計劃，向K8的遷移不會很快停止。那么，云原生安全如何才能不再成為將安全團隊的工作效率推向錯誤方向的因素呢?
從業者為供應商提供了一些建議：
1.給我一個真實的信號，而不是噪音
我需要從變形到環境中的工具中獲得有意義的見解——可以在一個屏幕上效仿上面的Scarleteel例子。
我的SIEM就像你在云方面的洞察力一樣好。
2.和我一起設計你的產品：如果我覺得我的投入正在轉化為價值，我會給你時間
你如何推銷你的解決方案和你賣什么一樣重要，停止推動你的議程，傾聽并填補你解決方案中的空白。
3.請允許我把它關掉
“我最近買了一個運行時解決方案，他們一直在向我顯示警報，但他們沒有考慮到的是，我知道這些警報是什么，我對它們沒有意見。我從事的是風險管理業務，而不是‘包治百病’。
4.幫助我在整個企業中創建影響力和伙伴關系的新模式
如果我的主要利益相關者是工程學，那么你的工具需要展示工程學關心的東西。
結論
盡管困難重重，但最具前瞻性的安全團隊發現，保護新環境帶來的挑戰是一項令人興奮和有益的努力。團隊正在整個企業中創建新的影響力和合作模式來應對，但只有時間才能證明云原生安全是否會跟隨他們的腳步，與這些安全團隊建立真正的合作關系。
