許多開發人員如今已經認識到安全軟件開發的重要性，但更重要的是，我們必須明白，計劃進行安全軟件開發和實現它并不是同一回事。
實際上，一些軟件開發公司首先得將安全完全集成到他們的開發過程中來。時間和資金限制是公司面臨的常見阻礙，但開發人員的錯誤同樣能造成該集成過程的延遲或錯誤導向。
下面是開發人員容易犯下的三大錯誤：
錯誤 #1：項目最后才匆忙上馬安全
公司企業必須在開發過程之初就有一個安全計劃。這種前瞻性可以讓開發人員采用安全的架構和設計方法，也能更容易地保證代碼的整體安全。一個制定良好的安全計劃，對今天的軟件用戶而言尤其重要，他們期望開發人員給他們提供安全的產品。
當你推遲項目某個子系統的安全工作，稍后你將不得不對整個系統的很大一部分進行返工和重新測試。你當然可以延遲日志之類代碼庫才關心的事，但如果你因為復雜和昂貴而推諉系統訪問控制的實現，那你就錯過或低估了重要的項目需求。
錯誤 #2：沒能利用好安全軟件開發工具和專門技術
公司企業要能經受得住在軟件中采用自己的安全方法的引誘。尤其是在身份驗證模型、加密和其他復雜功能方面。沒必要重新發明輪子。開發人員只要利用好別人經過驗證的安全代碼和過程就好。時間已經證明了這些解決方案是切實有效的，換句話說就是，這些前人的經驗能夠幫助開發人員增加對自身項目安全的自信。
從靜態代碼分析到滲透測試，當今世界有那么多的資源可以利用，我們再沒有借口不在產品發布之前搞清它的安全狀況了。而且，還有很多諸如OWASP、SAFECode、BSIMM等公司可以幫你理解怎樣打造一個安全的程序。
錯誤 #3：使用帶缺陷的庫組件，繼承了其他開發者的安全漏洞
開發團隊需要確保清楚得知道所用的每個庫，以及從其他源引入的代碼的出處。還需要查明產品用到的任何第三方代碼中使用的安全驗證、威脅模型和其他安全保障措施。
從安全和缺陷暴露的角度出發，引入第三方庫和框架是一項十分危險的操作。開發外包并不能免除你盡職審查和測試所用代碼的職責。近期曝出的Java遠程方法調用（RMI）反序列化和Apache Commons Collections庫的CWE-502問題就是這方面一個很好的例子——在類路徑里包含了這個庫本身就暴露出了問題，無論這個庫是否被調用。
總結
“模糊不清的安全”要不得。有些開發人員要么將安全實現隱藏起來，要么認為非常復雜的實現能讓產品更安全。事實上，建立在已證方法基礎上的有效安全實現才更能通過同業審查，而同行審查是增加軟件交付前安全缺陷檢出率和解決率的良好安全的基石。
然而，不幸的是，很多軟件開發團隊依然試圖在開發末端才解決安全問題。這樣是不行的。
要想產生預期效果，安全必須融入整個開發過程，從項目計劃初期貫穿到產品部署使用。
任何在產品預定發布時間前夕經歷過數據泄露，或收到出人意料的滲透測試結果的人，都相當清楚在開發周期末尾添加安全的痛苦。今天，由于物聯網設備和無處不在的計算環境，開發人員理解問題和在實際環境中應用安全措施的壓力日漸增大。將安全貫徹始終似乎是一項巨大的投入，但第一時間就做對的花費，絕對比問題出現后再補救的代價要小得多。
京公網安備 11010502049343號