上述三類安全漏洞，無一例外是在代碼功能正常的前提下進行的，可見功能可用不代表安全可靠。而為解決這些問題，更多的是需要在研發過程中各環節介入安全能力，實現對上述各類漏洞的上線前檢出以及修復，降低項目上線安全隱患。
軟件測試階段：交互式安全測試 (IAST)，IAST 通過代理、*** 或者服務端 Agent 方式無感知獲取功能測試人員測試交互流量，基于模糊測試 (fuzz) 思想對流量進行攻擊代碼隨機插入和攻擊流量構建，并自動化對被測程序進行安全測試，同時可準確確定漏洞所在的代碼文件、行數、函數及參數。
上線迭代階段：常態化安全運營，對項目上線后所在的服務器資產、中間件以及項目本身進行 7*24 小時周期性安全檢查，相當于有一個安全團隊或滲透測試工程師全天候管理線上資產、站點以及中間依賴的安全問題，有效確保安全健壯性。
限制管理網絡的管理接口訪問；如果無法做到這一點，則要在上游設備（交換機和路由器）使用ACL,限制發起管理會話的來源。
在研發人員眼中，編碼開發的目的是實現相關功能邏輯可用，無明顯功能 bug。而實際上，在安全人員眼中，很多這樣看似沒有功能問題的代碼，卻可以利用來進行安全漏洞攻擊。雖然這在很多研發人員眼中是看似天方夜譚，但很不幸，通過以往的無數重大安全事件的驗證，這個事實客觀存在。
企業應該將賦能服務貫穿需求分析、架構設計、研發、測試回歸以及發布迭代全流程，通過賦能將專業安全能力賦予研發各環節人員，并在各環節提供不同工具(STAC、SAST、IAST、常態化安全運營)使賦能知識真實應用落地，*終以統一平臺展示、分析、回歸、閉環安全問題，并向***提供 SIEM，根據各流程頻現的漏洞類型、研發人員知識盲區等再次提供針對性培訓，*終針對性制定規章制度，實現制度精準逆推落地。
需求和架構階段：基于業務場景的威脅建模 (STAC)，以威脅建模賦能方式教會需求分析和架構審計人員對項目內場景潛在場景風險進行識別和剝離，通過威脅建模針對性提出安全方案，用于后續研發等環節的解決或規避。
由于攻擊也在進化，所以要定期檢查滲透測試。要保持OpenVAS和Metasploit等工具的更新，而且它們可以使用的攻擊庫也在穩步增長。
軟件編碼階段：靜態應用安全測試 (SAST)，通過與 git、svn 等代碼倉庫聯動，自動化拉取全量或增量代碼進行代碼安全檢查，以波谷時間檢測方式在上班時間前根據提交歷史以郵件形式同時相關責任人，降低對相關人員工作方式更改。
-/gbadeeb/-
http://www.664151.com
