對于云原生環境來說，企業只在運行時采用安全措施已經不夠。
在當今的云原生世界中，隨著基礎設施的飛速發展，大規模構建云計算環境需要可再現性和彈性，因此需要從一開始就優先考慮快速更改和擴展基礎設施的能力。令人感興趣的是，對于許多人來說，云計算安全性只與在運行時發生的錯誤配置和違規行為有關。
如果在構建時不關注流程和代碼，就無法確定基礎設施問題，這與企業設計和構建現代云計算基礎設施的方式不符。如果構建不可變的基礎設施，則需要開始考慮如何保護不可變的基礎設施，而只是孤立地提高運行時的安全性是不夠的。另一方面，如果只在構建時解決云計算安全風險，但缺乏生產基礎設施的完整環境的話，也可能在云計算環境中留下漏洞。
以下將重點關注通過在構建時和運行云計算基礎設施時掃描來檢測安全問題，概述它們的價值和缺陷，以說明同時利用這方面的重要性。
為了應對云計算環境變得越來越復雜的局面，云計算提供商圍繞云計算資源的管理提供了豐富的元數據和遙測技術。建立可持續的云安全計劃需要對這些數據進行一致且可擴展的收集和分析。
技術社區主導的項目(如AWS公司的Prowler和谷歌云的Forseti)應運而生。這兩個項目都率先使用了公開的API來收集配置數據并檢查配置錯誤，實現了對部署后配置錯誤的檢測。
現在，大多數云計算提供商都在其控制平臺管理服務中包含了此類功能。使用AWS配置、Azure策略和Google資產清單等原生工具，獲得云計算的基本可見性比以往任何時候都容易。
運行時的云安全性當然是最佳實踐，但它也有其自身的優點和缺陷：
(1)變更追蹤
運行時掃描遵循配置的實際狀態。當以多種方法管理配置時，運行時掃描仍然是識別和評估隨時間變化的配置的主要技術。
(2)符合法規要求
大多數受監管的行業現在需要持續的變更控制審計和跟蹤。為了滿足這些需求，大多數掃描程序都將它們的發現映射到行業基準。一旦控制被映射到基準部分，企業就可以使用掃描報告作為基準證據來滿足大多數行業特定的需求和審核。
(3)接近實時結果
根據掃描頻率，運行時掃描可以快速識別和分類正在進行的問題。將掃描程序連接到票證或監視工具可以幫助確保更快的響應和緩解。
(4)低信噪比
大多數掃描程序仍然嚴重依賴缺乏場景的確定性檢測邏輯，從而導致一堆無關緊要的發現，尤其是對于資源壽命較短的動態環境。例如，在使用自動縮放的環境中，運行時掃描將在兩次掃描之間返回不一致的結果，免備案服務器，并產生不代表最新資源狀態的輸出。此外，掃描多方面的身份識別與訪問管理(IAM)權限或完整的網絡拓撲可能會錯誤地警告配置更改。
(5)不切實際的發現
標記錯誤配置后，最直接的問題通常是“我們該怎么做才能解決?”，如果修復單個云配置錯誤需要更多的人工步驟，或者無法還原配置，那么其升級最終浪費了開發人員寶貴的時間。
(6)重復的錯誤配置
對于利用基礎設施代碼框架來協調云計算資源的團隊而言，只是在運行時修復錯誤配置會帶來重復發生的風險。為了確保不會發生云計算配置錯誤，必須在源頭進行補救。
構建時云安全狀態管理
在構建時云計算基礎設施掃描配置并不是什么新鮮事。識別編碼錯誤已經有一段時間了，尤其是在應用程序安全中。然而，隨著基礎設施作為大規模提供云計算資源的代碼的興起，這種方法的應用在過去幾年中得到了極大的擴展。
以代碼方式管理的掃描配置使用與運行時掃描程序相同的高級策略，并搜索相同的資源及其配置狀態。通過使用基礎設施即程序代碼(IaC)掃描程序(例如開放源代碼工具Checkov)，配置文件被視為獨立的清單，用于描述如何配置資源和設置屬性。
通過應用在運行時解決云計算安全性方面獲得的許多經驗教訓，可以使用構建時掃描來發現其他有價值的方面和缺點：
(1)可行的調查結果
通過在代碼中列出并管理配置，可以更容易地找到導致配置錯誤的確切屬性和參數。
(2)合作解決
通過所有代碼的檢測和響應，每個開發人員都可以幫助解決持續存在的問題。通過在同一工具中統一檢測和補救，可以更輕松地從一開始就將云計算安全性構建到日常工作流程中。
(3)自動響應
