應用程序安全性是質量問題：有益于質量和安全性的6條測試技巧

---

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

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

當然，這種安全測試是必要的，但僅僅是不夠的。雖然破壞軟件確實很有用，但是依靠它作為提高安全性的方法會導致在太晚的時候發現錯誤，并最終將其抑制。尤其是，諸如日程安排之類的根源問題，如不適當的框架和算法，已被掃地出門，因為日程安排贏得了重寫代碼和發布版本之間的沖突。

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

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

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

– Jim Bird“構建真實軟件”

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

• ＃3 CWE 120 –未經檢查輸入大小的緩沖區復制（“經典緩沖區溢出”）–可能導致執行未授權的代碼或命令，可能的未授權數據訪問，可能的拒絕服務（DoS）

• ＃20 CWE 131 –緩沖區大小的錯誤計算（導致緩沖區溢出）–可能的DoS，執行未授權的代碼或命令，可能的未授權讀取/修改內存

• ＃25 CWE 190 –整數溢出或環繞（導致未定義的行為并因此崩潰）–可能的DoS，可能的內存修改，可能的未授權代碼或命令執行，可能的任意代碼執行

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

建立

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

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

該怎么辦？

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

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

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

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

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

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

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

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

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