這裏存在一個普遍的謬論，認爲安全控制引入所造成的開銷會使應用程序變得太慢而不被客戶所接受。因此當程序開發人員在對比安全性和性能的時候，性能往往會顯得更加重要。這最終導致了這個應用程序會漏洞百出。
諮詢公司Denim Group的CTO說：“我們應該往後退一步並且重新評估安全控制會影響性能這一斷言，如果你剛剛開始就已性能的優化爲主這將是一個非常錯誤的結論，一個明智的做法是先構建應用的安全控制，接下去如果你發現了性能問題再開始進行性能優化。”如果一個應用程序以性能爲主而忽略了安全控制的話，那麼最終它會因爲本身的安全漏洞問題而屈服，會使軟件的性能變成一個爭議的話題。另外一方面，如果在程序中加入了過多的安全控制，將會影響程序的可用性。由於不可能存在兩個完全相同的應用，因此也不可能創建一個適用任何程序的具體的安全控制清單。David
Lindsay 說：“安全控制需要完全依賴於有問題的程序或者系統。” David Lindsay是諮詢公司Cigital的安全顧問。
爲了在安全性和可用性之間達到平衡，安全控制應該從風險管理的角度來看待。Lindsay說：“應該從軟件的架構開始注入安全性的概念，並且在軟件開發的過程中繼續保持這種理念。應該在軟件架構的層次就做出安全控制的決定，一旦你在架構的過程中注入了安全控制的理念，那麼就應該在代碼的各個部分都有安全控制的理念，並且這應該是一個程序員的職責。確保正確架構的組件植入代碼中。”
這裏有三個在應用中構建安全控制的實踐例子。
危險建模在架構的過程中就進行了。從架構的角度來觀察一個應用該如何構建，數據在應用中該如何傳遞並且如何存儲數據。Lindsay說：“從應用的業務風險角度來理解安全性這也是一個方法。”從數據流在一個應用中的傳遞，你可以發現應用的漏洞。
進行頭腦風暴
頭腦風暴也是在軟件的架構過程中進行的。然而危險建模是一個非常抽象結構性的過程，頭腦風暴更易懂。它包括考慮用戶使用場景和軟件可能被錯誤使用的方式。舉例說明，考慮一個在線銀行軟件。Cornell問：“在什麼情況下，這會被濫用”，“我們不會希望一個非系統用戶可以將錢轉入到一個外部賬戶中，我們也不希望系統內部用戶可以將別人的錢轉入到他們自己的賬戶中。”一旦這些濫用的情況被發現，程序就可以設置一些檢查點來阻止這些錯誤在系統中發生。Cornell說：“如果這些在先期都做到了，那麼這並不會耗費很大的成本。這樣可以更加主動的發現設計中那些可能導致巨大成本去修復的缺陷。”
輸入驗證
Cornell認爲，從編程的角度來看，輸入驗證是一個能夠實現的最好的安全方式。然而這又讓我們回到了安全控制和性能哪個重要的爭論中。“有一個傳統的說法，如果你做了輸入控制，那麼你就抹殺了系統的性能。事實上，從數據分析上來看，這是一個非常武斷的結論。” Cornell說：“只有執行不力的安全控制纔會影響系統的性能。”
Cornell說：“輸入驗證本質上是阻止了漏洞被利用的可能性.