安全在傳統上總是被當成軟件開發過程中“事后再想”的部分。但人人聞之色變Heartbleed漏洞及其相關的補丁困難使安全性被推到了最前線。而一個使用安全運維管理，或SecOps的安全軟件開發周期方式將可以加強AWS應用的安全性。

SecOps方法就有如DevOps原則一樣，促進了開發者和運營之間更好的溝通，只是對應的是安全方面，Todd Vernon，一家DevOps工具供應商VictorOps的CEO說道。DevOps允許IT團隊能夠在部署云應用至生產前快速做出改動。但這也產生了顯著的安全問題。

“過去，你可能三不五時會進行一次安全審計。但現在這能有什么用？”Vernon問道。安全運營管理即是不斷的開發，測試和監測系統中威脅的過程。它也提供了對于DevOps的相互制衡。

將安全融于設計之中

“將安全性從一開頭就放在設計里很關鍵，”David Eads，安全咨詢公司Mobile Strategy Partners的CEO說道。“如果安全只是事后再想的問題，那真正的安全是沒希望了。”對于基于云的環境來說更是放大了這種情形，他補充道。

在云里，新的漏洞可以很快補上。云配置腳本可以確保修復會快速的散播到所有其他受影響的環境，這樣漏洞不會再度發生。云也使得尋找類似問題，修復相關腳本，和可能與此相關但是不同問題的安全環境變成可能。

“IT人員在傳統環境下不可能做到這樣的事，”Eads說道。如果某個組織有著反應式的軟件開發文化，那它多半會先遭受近乎災難的結果，然后才能嚴肅的考慮安全性的問題，而這些有時候已經太遲了。

“Code Spaces就是個很好的例子，”Sirish Raghuram，私有云基礎架構供應商Platform9的CEO說道。“他們在他們的Amazon（Web服務）帳號中漏掉某些非?；镜陌踩婪洞胧麄冊僖矝]得到過第二次機會。你需要在組織里有某個有影響力的人，這人必須毫不遲疑的堅持改革，而不是等到一切都太遲了。”

未雨綢繆

那些在他們的開發過程中細密的羅織安全編程習慣的組織，多半對于安全性有著比較正確的觀點，Zulfikar Ramzan，基于云SecOps供應商Elastica的CTO說道。雖然事后的安全測試是有價值的，但它永遠無法揭露出底層真正的問題。

比如說，Heartbleed bug的嚴重性非常驚人。但是，多年來大家卻對它視而不見。這個挑戰部分存在于各種開發過程是依靠一個相當復雜的拼湊起來的東西來互相連接的。其中一個如果改動，就算這個改動看似無害，卻可以在下游過程中造成大災難。此外，顧客會要求云服務提供安全編程習慣的證明，Ramzan說道。那些企業們將處理他們數據的大任托付給廠商，自然必須加大保證的力度來確保該廠商正在以合理，安全和理智的方式來達成這件事。2014年的網絡供應鏈管理和透明度法案強制要求所有的云服務供應商，例如AWS，將已知的漏洞對政府客戶公布。

改善安全工程

一開始就將設計中的漏洞處理好是不可或缺的。在這些安全問題還在代碼階段的時候就處理掉對于預防跨站式腳本攻擊、SQL注入和其他已知漏洞是更有效的，Mark Patton，一家反惡意軟件供應商Malwarebytes的工程副總裁說道。而了解對于基于云系統對比本地系統的最佳實踐常常是個挑戰。

那些采用設計后安全編程實踐的組織應該遵循以下的建議來更好保證你們的環境不會產生漏洞：

• 考慮API表面的安全性就跟保護網頁一樣重要
• 查看云平臺安全性、AWS虛擬私有云布局和使用AWS安全組
• 討論認證的技術（用戶名和密碼、令牌、雙重認證等等）
• 不要將密碼憑證嵌入代碼，這會將它們泄漏給用戶
• 使用基于角色的“需要知道”或“需要訪問”來架構云資源的訪問

一個成功且安全的組織會為團隊提供圍繞安全性，以及功能和進度的激勵。企業應該將安全性包括在成功的定義中作為第一要素，并且從第一天起就被當作每個人的任務。

認清戰術上的障礙 確保安全開發

過渡到安全的開發生命周期絕不簡單。根據以安全為基礎的安全供應商Veracode的說法，公司要創建一個具有安全意識的企業文化，必須克服一些戰術上的障礙。

創建擴展的測試方法。隨著組織向敏捷化的遷移和持續部署，他們需要自動化的可以和已有流程整合的測試方法。

提供對開發人員有用的結果。一個手動測試（和某些自動化測試的結果）的缺點是很難給出有用的信息可以讓開發人員解決問題。代碼行數的報告比起不包括到底哪里出錯的診斷信息的漏洞類型報告更有用。

雇傭足夠的人才。要將安全貫徹到軟件開發中并且在過程中帶動開發人員一起需要專業的技能。對大多數組織來說，市場上沒有足夠的擁有正確技能的人來讓一個程序規模化的運行。