最近，我在LinkedIn上閱讀了一篇帖子，其中有人問了幾個靜態(tài)分析安全廠商之間的區(qū)別。一個人，毫無疑問是供應(yīng)商，回答說他們的解決方案更好，因為盡管其他公司專注于質(zhì)量和安全性，但他們嚴(yán)格執(zhí)行安全性。

當(dāng)然，這是一個荒謬的說法。也許這種想法表明了當(dāng)前行業(yè)中應(yīng)用程序安全的猖ramp問題。例如，嘗試運行其安全組的組織與SDLC的其余部分完全分開（包括開發(fā)和測試工作）。在此模型中，安全團隊運行自己的測試，主要是嘗試破壞軟件，然后將安全錯誤反饋給開發(fā)團隊。換句話說，嘗試在其代碼中測試安全性。我可以向您保證，這僅比測試代碼質(zhì)量有效。

當(dāng)然，這種安全測試是必要的，但僅僅是不夠的。雖然破壞軟件確實很有用，但是依靠它作為提高安全性的方法會導(dǎo)致在太晚的時候發(fā)現(xiàn)錯誤，并最終將其抑制。尤其是，諸如日程安排之類的根源問題，如不適當(dāng)?shù)目蚣芎退惴?，已被?地出門，因為日程安排贏得了重寫代碼和發(fā)布版本之間的沖突。

在上面我提到的Linkedin評論中，供應(yīng)商聲稱自己的軟件更好，但卻沒有說出任何關(guān)于如何更好的理由，這實際上是在誤導(dǎo)一個毫無戒心的潛在客戶。我并不是要選擇任何特定的工具供應(yīng)商，尤其是因為我為一個供應(yīng)商工作。但是，我對這種稻草人的論點感到沮喪，這些論點給人以賣蛇油的感覺。在這種情況下，供應(yīng)商的產(chǎn)品確實可能具有有趣的獨特功能，但給我們留下的印象是安全性與質(zhì)量在某種程度上有著神奇的區(qū)別，這降低了我們對應(yīng)用程序安全性的理解，使我們所有人的安全性降低了一點。

必須將安全性視為質(zhì)量，并且質(zhì)量必須基于成熟的工程實踐，因為事實是，如果您遇到質(zhì)量問題，那么您就會遇到安全問題。研究表明，安全缺陷的50-70％都是質(zhì)量缺陷。換句話說，良好的老式質(zhì)量漏洞正在變成入侵者/黑客/不良行為者用來滲透您的應(yīng)用程序的漏洞（我們稱為“零日”）。

“研究人員一致認(rèn)為，至少有一半（也許多達70％）的常見軟件漏洞是基本的代碼質(zhì)量問題，可以通過編寫更好的軟件來避免。馬虎的編碼?！?/span>

– Jim Bird“構(gòu)建真實軟件”

如果您仍然不確定質(zhì)量和安全性如何重疊，請查看CWE Top 25中的幾個示例。以下可能的安全結(jié)果來自CWE技術(shù)影響工作：

• ＃3 CWE 120 –未經(jīng)檢查輸入大小的緩沖區(qū)復(fù)制（“經(jīng)典緩沖區(qū)溢出”）–可能導(dǎo)致執(zhí)行未授權(quán)的代碼或命令，可能的未授權(quán)數(shù)據(jù)訪問，可能的拒絕服務(wù)（DoS）

• ＃20 CWE 131 –緩沖區(qū)大小的錯誤計算（導(dǎo)致緩沖區(qū)溢出）–可能的DoS，執(zhí)行未授權(quán)的代碼或命令，可能的未授權(quán)讀取/修改內(nèi)存

• ＃25 CWE 190 –整數(shù)溢出或環(huán)繞（導(dǎo)致未定義的行為并因此崩潰）–可能的DoS，可能的內(nèi)存修改，可能的未授權(quán)代碼或命令執(zhí)行，可能的任意代碼執(zhí)行

如果您進一步進入完整的CWE列表（超過800個項目），則會發(fā)現(xiàn)許多其他問題，即各種形式的上溢/下溢，初始化，不受控制的遞歸等。這些都是常見的安全攻擊以及明顯的質(zhì)量問題。

建立

軟件系統(tǒng)的復(fù)雜性增長非常迅速。試圖快速測試每種可能的變化幾乎變得不可能。正如理查德·本德（Richard Bender）所說，“潛在測試的數(shù)量超過了宇宙中分子的數(shù)量”，這只是一種有趣的說法，說您將永遠無法完成它?；蛘?從吉姆·伯德（Jim Bird）那里，“對于一個大型系統(tǒng)，您需要在無數(shù)個鍵盤上使用無數(shù)個筆測試器，并且它們需要工作數(shù)小時才能找到所有的錯誤?！?/span>

因此，必須同時設(shè)計和設(shè)計安全性和可靠性。您無法對其進行測試。只要安全性是“額外”的東西，它就會遭受損失。

該怎么辦？

您可以采取以下幾項措施來開始同時提高軟件質(zhì)量和安全性。

1. 培訓(xùn)開發(fā)人員進行安全開發(fā)。對您的開發(fā)人員進行安全的開發(fā)實踐培訓(xùn)，意味著他們可以預(yù)防（或至少找到并解決）安全問題。

2. 在設(shè)計和構(gòu)建系統(tǒng)時要特別關(guān)注質(zhì)量和安全性。避免使用“有效”的代碼，因為它存在潛在的安全問題，因此并不是一個很好的選擇。 （或者安全問題。）靜態(tài)分析將通過檢查代碼中的錯誤，以及是否符合已知的最佳做法來幫助您完成此任務(wù)。

3. 不再依賴邊緣工具。識別您的實際暴露和攻擊面。防火墻和防病毒軟件無法彌補不安全的代碼-您必須加固您的應(yīng)用程序。

4. 收集/測量缺陷數(shù)據(jù)，并將其用于評估和改進您的開發(fā)實踐。哪些代碼或組件產(chǎn)生最多的問題？什么代碼是最好的？他們是如何測試的？重復(fù)好主意，然后沖洗壞主意。

5. 使用嚴(yán)格的靜態(tài)分析。不要僅僅接受某人對已報告的缺陷不是重要問題或誤報的評估。獲得包括檢測和預(yù)防在內(nèi)的一系列良好規(guī)則，并遵守這些規(guī)則。最好的方法是采用圍繞最佳實踐的工程方法（諸如CWE，CERT和OWASP等編碼標(biāo)準(zhǔn)的作用）。靜態(tài)分析是確保遵循最佳實踐的方法。

6. 使用運行時分析。它會發(fā)現(xiàn)實際的問題（尤其是令人討厭的內(nèi)存問題），并且可以準(zhǔn)確地向您顯示出錯誤的出處，沒有任何誤報。

因此，我們需要開始在代碼中構(gòu)建安全性。這是真正加固它的最佳方法，而不僅僅是修補已知的孔。將來自編碼，構(gòu)建和測試的所有軟件開發(fā)結(jié)果集成到中央存儲庫中，即可提供控制，度量和可跟蹤性。這是未來改進的基礎(chǔ)。

請記住，可靠防護的成本低于處理不良或不安全軟件的成本。因此，實際上沒有任何借口再不重視測試了。