在開發安全軟體的時候,程式碼分析工具可以發揮重要作用。它們(指程式碼分析工具)可以幫助發現一般的程式安全撰寫錯誤，例如記憶體溢位使用錯誤、跨網站程式碼攻擊、嵌入式SQL字串攻擊及各種資源競用弱點攻擊。它們還提供更進一步的客製化功能，可以依據自定義的程式撰寫標準，對程式碼進行全面的稽核檢查比對。
但企業組織往往會發現，要導入一種新的工具到軟體的開發過程中，經常是說起來容易做起來難。新工具的導入要成功，必須平順地與現有的開發流程整合，它一定會對目前的開發過程造成某些差異，但不至於會造成分裂混亂，它們應該是解決棘手問題的方案，而不是讓工作更繁忙的來源。
為了採用工具而建立一個良好的導入策略是沒有問題的。
如果你正在閱讀一本有關安全的雜誌，我們將不會浪費時間來試圖說服你安全有多麼重要或程式碼中的缺陷會對你的軟體造成什麼樣的威脅。（為了建構安全系統，如果你還需要有說服力的資料，我們推薦Security Engineering 這一本書，為了深入研究軟體具體的安全問題，我們推薦Building Secure Software 這一本書）。
當你正在尋找各種方法來改善你的組織開發的程式碼安全性，並且你有責任心要減少交付不安全程式碼所帶來的風險及其他相關環境的風險，這正是採用程式碼分析工具的最好時機。
為了要在軟體出現安全問題前，找到程式碼安全錯誤所在的程式碼，這樣的需求使的程式碼分析方法，最近變成一個受歡迎的解決方案選項。許多關於程式碼分析的文章集中在討論了靜態分析工具是如何運作的——也就是工具如何從程式碼中發現錯誤程式碼的演算法和推斷方式。但在這篇文章中，我們感興趣是另一個問題：如何將程式碼分析工具成功整合到一個大而混雜的軟體發展組織中。（目前，我們所見過的所有大型軟體發展組織多少都會有些混雜。）
從最初的觀察來看，這似乎不大可能像一個難題。取得工具，運用工具，解決問題，你是做對了，還是做錯了？
改變習慣是很難的，很多軟體開發者習慣在沒有考慮會有安全弱點的問題下撰寫程式碼。僅因為使用了一個新工具就希望能夠改變軟體開發者關於撰寫安全程式碼的態度是不切實際的。接受一個工具的使用並不像在門口離開哭啼中的嬰兒那麼容易。
當然，要獲得軟體安全牽涉到很多層面，可不僅僅是工具。為了要建構好的風險管理方法，軟體開發流程的工作項目增加軟體安全的教育和培訓必是不可少的。
根據我們的經驗，在採用一種工具前必須回答3個重要的問題。無論一個組織的規模如何、其軟體開發過程的模式和成熟度如何，在回答這三個問題上都會顯得非常吃力。 並沒有一個適用於所有問題的答案，因此，讓我們一起來考慮每個答案可能的範圍。
在一個組織中，通常有兩種不同典型的人員來掌控此工具。
集中式的安全團隊：你需要確保你的安全團隊有正確的技能——簡而言之，你需要讓安全團隊具備有軟體開發的本事。即使你打算讓開發者作為該工具所產生資訊的主要使用者，安全團隊的參與也是一項巨大的資源。他們會帶來風險管理的經驗並且常常勾畫出主要的安全關注點。最後一點，請記住該安全團隊一開始不會撰寫程式碼也不會像開發團隊那樣熟悉程式碼，因此，讓安全團隊加入項目是很困難的。在工具導入的過程中，安全團隊若能夠給予開發團隊適當的程式碼的問題說明與回饋，對於工具的導入是有非常大的幫助。
開發者：開發者擁有最佳的開發應用程式細節方面的知識，這對後續程式碼修復的資源與效率是非常重要的。將開發者此方面能力與程式碼分析工具提供的程式碼弱點說明的詳細資料結合起來，在工具的運用上，你將可以擁有一個可靠的實務導入案例。另一方面，開發者始終承受必須在最後期限前完成產品的壓力。另一方面，他們也不可能擁有與安全團隊成員一樣的安全知識和專業知識。因此，一個關鍵問題是開發者需要多長時間才會開始使用程式碼分析工具，包括前期使用和經常性使用。為達到這一目的，培訓你的開發人員的安全意識也是很重要的，同時還要建立他們與使用工具的責任心。
如果你已經確認了由誰來運用程式碼分析工具，那麼下一步就是確定運用的時機。
程式碼撰寫階段：大量的研究表明，修復錯誤程式碼的成本隨著時間的推移而增加，因此，及時檢查新的程式碼更有意義。完成這一任務的第一種方式是將程式碼分析工具整合到開發者的開發環境中，這樣開發者就可以隨時按需要運用工具進行程式碼分析及來獲得工具提供的專業意見。當整合到開發環境中是不可行時，另一種方法是將掃描功能整合到程式碼的檢查過程中，這樣就可以集中控制程式碼分析的運行。但它會使的開發者無法按自己的需要隨時來分析程式碼。
編譯階段：對大多數組織而言，會預先定義好一個軟體編譯的程序，一個軟體專案可以有一個明確的編譯過程。它提供程式碼審查的一個可信的報告以用於直接的修正程式碼，並作為更進一步的人工程式碼審查的基線。同時將編譯階段作為程式碼分析的時程表，提供一個確認的時間標準，為整個軟體專案建立一個可重複的，一致的衡量方法，確保專案沿正確的方向進行。
重要的里程碑階段：組織依賴的重要過程是在專案的里程碑階段設立檢查點，通常是在開發週期接近尾聲的時候或在一些大的間隔區間。這些檢查點，有時甚至包括與安全有關的任務，如設計審查或滲透性測試。在這個概念進行延伸，那麼檢查點就是使用程式碼分析工具的最佳點。警告：雖然此種方法可以使已經存在的實踐更有效率，但並不完整，因為此種檢核方法的只是呈現一個時間點上的安全。
你已經知道了誰會使用工具以及什麼時候使用工具，那麼接下來該怎麼做？
確定一個版本發佈的門檻：我們假設，你將程式碼安全分析過程和人工確認工具輸出資料的優先順序，作為專案里程碑檢查點的一部分。開發團隊在獲得有優先順序的結果後再決定哪些問題需要修復，哪些將進入“可接受的風險“類別。對滲透性測試的結果也常常採用這樣的方法，並且它可能被用來產生這樣的結果：阻止應用程式在備受矚目的, 勉勉強強的情況下發佈。因為這種類型的審查可以阻止一個項目達到其里程碑，因此，最重要的因素是要確保專案不是簡單的接受所有已確定的問題，以免除修復所花費的時間以便更快地達到他們的里程碑。如果版本發佈門檻有效，這種方法可以產生很好的效果。如果開發者能夠簡單地忽略掉該結果，那麼他們就沒有改變他們程式碼撰寫方式的動機了。
核心權力機構少量發佈個別結果：程式碼分析工具可以掃描許多不同種類的問題並且能夠直接檢查程式碼中的特殊部分。因此，使用工具的核心團隊能夠看到一個或多個專案所報告的問題，然後選擇高優先順序的條目給那些對問題程式碼負有責任的人員。在這種情況下，程式碼分析工具要配置成最大限度的冗長，其目的是要發現所有問題。一個關注的焦點是較少的誤報，這是因為在形成最終報告前，由一個訓練有素的分析師對結果進行了處理。通過這個稽核模型，分析師的核心團隊在一個短期內能夠熟練使用工具，從而提升整體稽核能力。
核心權力機構設置精確的焦點：由於一個組織中可能存在大量的專案，因此，對結果進行管理的中心分配方法可能很快變得不實用。此外，很多嚴重的安全問題可能緊密地圍繞在一類或兩類典型問題周圍。利用這種方法，負責該專案的團隊將限制工具到一小部分具體的問題類型，根據該組織的每種風險類型，它可能隨著時間的推移而增長。最終與集中管理的策略、標準、或一組指導方針一樣，這一套在範圍內的問題將得到良好運作。它將與你的團隊接受並解決範圍內的所有問題一樣快的改變。就整體而言，隨著時間的推移，通過親身體驗該工具，這種方法給人一個逐步成為專家的機會。
開發軟體安全系統要花很多的努力，尤其是那些過去不太重視程式碼安全撰寫的組織。程式碼分析工具可以幫助你將最佳實務系統化，發現常見的錯誤並提高安全規定的有效性和一致性。但要獲得這些好處，一個組織必須為工具的使用制定一個明確的計畫，包括安排誰負責運行工具、什麼時間運行以及對結果如何處理。當為工具的使用及優先順序作出艱難決定的時候，需要謹記的一個最重要的觀點是：“真正的問題是‘現在還是稍後’而不是‘要和不要’。
開始一個導入程序規劃，在短期內開始導入，並隨著時間的推移逐步完善該過程。如果你有了經驗，並且你希望將你使用工具的成功與失敗與人分享。