不應該將軟件安全活動僅限于技術SDLC活動，尤其是滲透測試。你當然應該利用滲透測試的優(yōu)勢，但你需要了解它的局限性。主要的限制是經(jīng)濟方面：當你在內(nèi)部系統(tǒng)（或者即將出貨的系統(tǒng)）中發(fā)現(xiàn)一個安全問題，解決問題將變得非常昂貴。你要解決你所發(fā)現(xiàn)的問題，對嗎？這里需要注意的是，軟件安全不僅僅是充斥著各種漏洞以及攻擊者威脅的技術問題。當然你需要做大量適當?shù)募夹g操作，但永遠不要忘記將這些操作直接聯(lián)系到業(yè)務影響和風險管理。你正在修復開發(fā)器以確保開發(fā)人員在最開始制造更少的安全漏洞嗎？你正在構建安全的中間件解決方案以供開發(fā)人員和架構師使用嗎？你正在測量安全活動，并內(nèi)部公開相關結(jié)果嗎？你應該這樣做。這也是BSIMM涵蓋的范圍廣于架構師、開發(fā)人員和測試人員的工作范圍的原因。我們詢問了很多企業(yè)有關提出、創(chuàng)建和部署安全軟件的一切數(shù)據(jù)，我們記錄了這些數(shù)據(jù)，并產(chǎn)生了BSIMM。我們與跨多個垂直行業(yè)的各種規(guī)模的幾十家公司（包括軟件供應商）的持續(xù)接觸都表明，一個涵蓋政策、風險、合規(guī)、管理、衡量、運營、服務水平協(xié)議以及相關條目的軟件安全計劃除了設計、編碼和測試中所有重要關鍵的因素，他們認為是這些業(yè)務流程以及他們產(chǎn)生的文化和環(huán)境對生產(chǎn)和維護安全軟件至關重要。

為你的SSG發(fā)展和培養(yǎng)軟件安全專家（因為周圍沒有足夠的合格的專家）。最佳軟件安全組成員是軟件安全人員，但軟件安全人員往往找不到。如果你必須從頭開始創(chuàng)建軟件安全類型，從開發(fā)人員開始，教他們安全知識。不要試圖從網(wǎng)絡安全人員開始--教他們關于軟件、編譯器、SDLC、漏洞追蹤和軟件界的一切知識。再多的傳統(tǒng)安全知識也無法克服軟件的“木訥”。應該像種樹一樣，從播種開始，逐漸將其培育成參天大樹。當你開始這樣做時，你應該嘗試培養(yǎng)“瑞士軍刀”類型的專家，而不是重視每分鐘的專家。我一直期待找到可以審查代碼、做一些滲透測試，以及能夠解決安全問題的人。

關注來自業(yè)務、運營和事件響應人員的情報信息，并相應地調(diào)整SSI控制。安全是一個過程，而不是一個產(chǎn)品。軟件安全更是如此。你可以構建世界上最好的代碼，具有超級“防彈”架構，但在操作過程中仍然可能發(fā)生問題。使用你經(jīng)歷過（以及你的同行經(jīng)歷過）的安全攻擊來提高你的軟件安全方法，并根據(jù)業(yè)務重要性來進行調(diào)整。盡可能地了解你的敵人。

仔細追蹤你的數(shù)據(jù)，知道數(shù)據(jù)的位置，無論你的架構多么云計算化。云時代已經(jīng)來臨，你的數(shù)據(jù)將被轉(zhuǎn)移到云中。請了解清楚，你不能將軟件安全責任外包給你的云供應商。你的客戶還依賴你來保護他們的數(shù)據(jù)，在某些情況下，政府還會監(jiān)管這種責任。云計算的弊端在于應用在云端運行。現(xiàn)在正確地構建，能讓以后的日子更輕松。

不要單純地依靠安全特性與功能來構建安全軟件，因為安全是整個系統(tǒng)的新興資產(chǎn)，它依賴于正確地建立和整合所有部分。無論我們說多少次，開發(fā)人員、架構師和建造者仍然將安全作為一件事情。他們接受的多年的培訓都是將系統(tǒng)認為是特性和功能集，這是我們需要克服的。不要陷入“神奇加密神話”的陷阱。加密當然是有用的，一些系統(tǒng)仍將需要加密功能，但安全是一個系統(tǒng)級屬性。聰明的攻擊者很少會試圖攻破加密功能，他們往往會攻擊系統(tǒng)其它晦澀部分的漏洞。當你在選擇和部署安全功能時，請確保你花了盡可能多的實踐來試圖消除漏洞和問題。即使是具有良好加密、強大的身份驗證、細粒度授權、費解的CAPTCHA以及很多其他完美編碼的安全功能的軟件，都可能遭受攻擊。這些功能通常會阻止授權用戶做已知的不好的事情。但他們很少阻止未經(jīng)授權的用戶做未知的不好的事情。你需要一個軟件安全計劃來為整個產(chǎn)品組合有效且高效地構建安全軟件。

你應該修復已識別的軟件問題：漏洞和缺陷。這很討厭，但在實踐中，軟件安全就是這樣的。你聘請一些洗心革面的黑客來進行滲透測試，你知道他們已經(jīng)洗心革面了，因為他們是這樣告訴你的。在你讓他們從外部探測你的系統(tǒng)的一周內(nèi)，他們就找出六個安全漏洞，然而，他們可能只會告訴你其中的五個漏洞。你修復了兩個看似可修復的漏洞，然后宣布勝利。但其他四個漏洞呢？簡單地說，如果你將所有精力花費在通過架構風險分析、代碼審查和滲透測試來找出軟件中的問題，而不花時間修復你找出的漏洞，你的軟件將變得更加不安全。修復軟件吧！當然，修復漏洞是一個風險管理活動，沒有哪個公司有無限的資金投入其中。因此，企業(yè)應該根據(jù)影響、成本和其他重要業(yè)務因素，來優(yōu)先漏洞修復順序。然而，極少數(shù)企業(yè)會追蹤每個沒有被修復的漏洞。10個低嚴重漏洞會變成中級嚴重漏洞嗎？那100個？1000個漏洞呢？此外，極少數(shù)企業(yè)會關聯(lián)來自多個測試方法的研究結(jié)果，而是在每個測試后，獨立作出決定。分別來自架構評估、靜態(tài)分析、模糊技術以及滲透測試的低嚴重性漏洞相結(jié)合，會成為緊急漏洞嗎？我也不知道，但企業(yè)應該考慮這個問題。修復軟件可能更容易。

有關描述性模型的規(guī)范性建議

最終，你需要確定和采用你自己的規(guī)范性SSDL方法，然后使用描述性的測量系統(tǒng)來跟蹤進度。我們的建議是使用BSIMM來測量你的軟件安全計劃的當前狀態(tài)，確定你應該開始著手的其他軟件安全活動。如果你的企業(yè)確定需要投資的領域之一與SDL中的一個做法相匹配（舉例來說），你可以利用微軟對此的智慧來做。

鑒于多年來我們一直在觀察51家公司的真正的軟件安全計劃，我們可以自信地說，如果你的軟件安全計劃沒有每年進行改善，你將落后于其他公司。我們知道，每個軟件安全計劃都是獨一無二的，就像所有其他軟件安全計劃一樣，你的同樣也是獨特的。幸運的是，無論你為軟件安全采取哪種規(guī)范性方法，BSIMM都可以作為測量標桿、靈感源泉以及是否進步的客觀測量標準。