4. 軟件詳細設計安全性分析——設計實現是否符合安全性要求
軟件詳細設計進一步細化高層的體系結構設計，將軟件結構中的主要部件劃分為能獨立編碼、編譯和測試的軟件單元，并進行軟件單元的設計。
在這一階段中，需要依據軟件需求、結構設計描述、軟件集成測試計劃和之前所獲得的軟件安全性分析的結果，對軟件的設計和實現階段是否符合軟件安全性需求進行驗證。
相關軟件單元應進一步細化設計以便于編碼。所以，我們應該分析：
a) 軟件詳細設計是否能追溯到軟件需求；
b) 軟件詳細設計是否已覆蓋了軟件安全性需求；
c) 軟件詳細設計是否與軟件結構設計保持了外部一致性；
d) 軟件詳細設計是否滿足模塊化、可驗性、易安全修改的要求。
軟件詳細設計是直接關系到編碼的關鍵一環，軟件詳細設計安全性分析更相關整個軟件的安全性。所幸的是，眾多前輩們總結了許多可以提高軟件安全性的手段和技術，這些經驗經過長期驗證，多數已經成為標準的參考：
設計邏輯分析：評價軟件設計的方程式、算法和邏輯，可以包括失效檢測/診斷、冗余管理、變量報警和禁止命名邏輯的檢測。
設計約束分析：給出一些約束，來評價軟件在這些約束下運行的能力。比如：物理時間約束和響應時間對軟件性能的檢查。
復雜性度量：高度復雜的數據結構難以徹底測試，可以采用McCabe或Halstead等這樣一些復雜性評估技術來標示出需要進一步改進的區域。等等。
5. 軟件編碼安全性分析——完成安全相關軟件的編碼活動
軟件編碼完成軟件詳細設計的實現。所以，代碼應該體現軟件詳細設計所提出的設計要求，實現設計過程中開發的安全性設計特征和方法，遵循設計過程中提出的各種約束以及編碼標準。
我們一般采用代碼走查或采用靜態檢查工具來檢查源代碼，依照軟件編碼安全性分析對代碼的要求，應該主要從以下幾個方面入手：
a) 分析軟件代碼是否能追溯到需求；
b) 分析軟件代碼是否符合支持工具和編程語言分析；
c) 分析軟件代碼是否滿足模塊化、可驗證、易安全修改的要求；
d) 分析軟件編碼中所使用技術的安全性和方法的合理性。
下面列出一些可用于提高代碼安全性的相關技術。
代碼邏輯分析：如有不可達代碼，或代碼結構過于復雜，維護性降低。通過實施邏輯重構、方程式重構和存儲器解碼來進行。
代碼數據分析：關注如何定義和組織數據項。變量忘記賦初值，或變量聲明了卻沒有使用，或出現了冗余代碼。
復雜性度量：復雜軟件不穩定，也經不起不可預測的行為。所以，我們努力使軟件的復雜度變小。如果有條件采用某種自動化工具，可以通過工具對軟件設計或/和代碼進行控制，用圖形化的方法反映出軟件結構中的控制流和數據流，通過連結數/調用數、節點數、嵌套深度等這樣一些結構關系的檢查，獲得復雜度的度量，將會獲得很好的效果。
6. 軟件測試安全性分析——保證軟件安全性
軟件測試作為驗證軟件功能性和安全性的重要手段，其采用的測試方法和測試技術也完全關系著測試結果的準確性，關系著后續軟件的變更和測試的有效性。
軟件測試安全性分析既包括事前分析，又包括對測試結果的評價，所以一般從不同角度進行按步驟的測試：
a) 分析測試集中的所有測試用例，測試是否通過測試準則。
b) 測試代碼是否按照要求分析，并達到相應的測試覆蓋率。測試覆蓋是指檢查代碼的每一個狀態和路徑。
c) 對測試結果進行分析，以驗證所有的安全性需求是否得到了滿足。
軟件測試已漸漸占據軟件開發40%以上的時間，由此可見軟件測試的重要性。合理的軟件測試手段的應用對于提高軟件安全性是有很大的促進作用的，關于如何運用軟件測試來驗證軟件安全性是否達到目標，我們將在下文詳細探討。
7. 軟件變更安全性分析——應對可能出現的軟件變更
在執行任何軟件變更之前，應建立軟件變更規程。如果必須進行軟件變更，則因該對已經受控的規格說明、需求、設計、編碼、計劃、規程、系統、環境、用戶文檔的任何變更都進行安全性分析。
軟件變更安全性分析一般根據變更的原因、變更影響、變更可能會導致的結果將這項任務安排為三個階段。
需要注意的是，我們的目的是確保軟件的質量在經過變更后達到了預定的目標，而不是有所倒退。
四、 運用軟件測試提高軟件安全性
據美國一家公司的統計表明，在查找出的軟件錯誤當中，屬于需求分析和軟件設計的錯誤約占64%，屬于程序編寫和其他原因的錯誤占36%，由于一部分錯誤很可能因為復審過程中沒有被發現而轉入下一個階段，導致在錯誤的基礎上產生了更多的錯誤，形成錯誤的“放大效應”。事實上，開發工作中的每一個環節都可能出現問題，那些沒發現或已“放大”的錯誤修復成本都是非常高的。所以，測試這種專門針對軟件錯誤的技術漸漸被人們重視，它已成為保證軟件安全性的一項重要手段�，F今，測試投入也在整個開發投入中占了很大比重。但仍有很多測試人員在面對不同的軟件測試對象、眾多軟件測試方法，對自己手中的項目應該采取什么樣的測試手段，才能達到效果明顯的目的不很明了�？偟膩碚f，測試經過有計劃的安排才有意義，開始于模塊層的功能驗證，并跟隨軟件的抽象和整體性最終到了系統驗證的階段。當然，就算對一個不算太大的項目而言，要想實現“完全測試”也是不太可能完成的，所以，對每一個層次的測試而言，要做的工作都是做好測試計劃，了解現階段的測試目標，努力提高我們的軟件安全性。
針對軟件安全性的測試方法就是采用各種方法來驗證或發現系統安全方面的問題。對于軟件需求說明書上既定的有關安全的功能需求，我們要一一進行驗證測試。對于沒有在軟件需求書上標明的可能影響系統運行安全的隱性需求我們也要努力的發現。除了被動發現系統已遭受破壞的隱患和原因，在主動發現方面，我們最基本和最主要的是要采取靜態分析技術和功能測試兩種方式攔截系統開發時存在的漏洞。
靜態分析技術：其基本特征是不執行被測試軟件，而對需求分析說明書、軟件設計說明書、源程序作結構檢查、流圖分析等找出軟件錯誤。
這里，需求和設計追溯和確認是驗證測試的前提，我們可以利用一些自動化工具畫出功能需求的相關關系圖，以及一些系統結構的UML圖，能夠使測試人員與開發人員保持一致的設計思路。
源程序的結構檢查和流圖分析一般是測試人員代碼審查時的重要工作，對于查出前期的軟件錯誤非常有效，現在很多開發單位都采用自動化測試，取代了冗長的代碼審查會議，提升了測試的效率和準確度。比較著名的工具有英國PRQA公司的產品，它對檢查一些代碼邏輯錯誤、無法執行到的代碼段和違反通用編程規范的行為非常有效。
功能測試：功能測試是動態測試的一種方式，驗證的是軟件的功能實現。比如在網絡信息系統進行自身安全建設時，我們會在軟件設計和開發過程中，增加一些必要的安全防護措施，如權限管理模塊、數據恢復功能等等，我們就會通過功能驗證來檢查我們是否達到了沒有安全疏漏的要求。
總之，軟件安全性測試是要將軟件測試人員放置在一個相對主動的位置上，能夠盡力避免被動發現系統漏洞。
五、 軟件安全性分析的前景
在前進的道路上，風險是不可避免的，多一條可供選擇的道路，就會多增加一份風險系數。在計算機技術飛速發展的今天，我們不可避免地會面臨降低風險還是躲避風險兩種選擇。將必要風險降低是提高系統安全性的最重要和最積極的方法，所以，必須從研發的開始階段到項目最終評估受審階段，始終以安全完整性為目標，使系統滿足必須實現的功能達到或維持安全狀態所必需的安全功能。
軟件安全性分析任務包含于軟件生存周期的若干活動中，是針對軟件的安全性質量，作為這些活動的補充。軟件安全性分析作為開發中軟件的質量的重要保證，關系到軟件的獲取、供應、開發、運行和維護，已得到專業人士的高度重視。并且現在，軟件安全性分析任務的各項細節執行都寫入了國軍標，被安全相關軟件的需方、供方、開發者、維護者以及獨立的評價者使用。規范化將推進軟件安全性分析的進程，使更多的開發和評測單位遵循標準化文件，督促開發團隊采取相應的技術手段，以軟件測試作為輔助。同樣，軟件安全性分析標準也會在推進的過程中，得到不斷地發展。相信，軟件的安全性會隨著標準化一起前進！
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
