關於軟件安全的種類有很多種分類方法，這裏就不一一敘述了，這裏主要是根據自己的經驗把安全問題分一下類別，然後說說針對每種類別如何進行處理。
安全的問題，根據處理的團隊的不同，可以分爲：軟件運行時環境的問題 和 軟件自身的問題。
一 軟件運行時環境的問題
主要是指軟件運行的操作系統、運行的需要容器和服務，主要出現的問題種類包括：環境自身的漏洞和依賴的組件配置不安全。一般都是有系統維護團隊進行統一管理，對產品的環境進行維護與升級。
1）系統環境的漏洞
系統環境主要是指軟件運行時所需要的基礎組件，例如：操作系統有漏洞，或者Web服務器有漏洞等等，這種漏洞沒有什麼好方法處理，只有等維護的團隊出升級版本，然後及時升級。這就需要一個應急管理機制，保證嚴重漏洞出來時，可以及時有效地推動團隊去修復。
2）依賴的組件配置的問題
很多依賴的組件可能默認的配置並不安全，需要在產品線上部署之前，對所有的配置梳理一遍，以防有錯誤的配置導致安全問題發生。比較好的做法是一個公司統一出一個標準的版本，這個標準的版本默認的配置都經過安全團隊審計是安全的，以防有嚴重安全問題的配置遺留到系統裏，例如：默認的用戶名和密碼。配置系統時，需要注意最小權限原則，寧願複雜一點，多配製一些不同級別的用戶做不同的事情，也不要用一個超級用戶做所有事情。
每升級一個版本都需要對變動的配置項進行重新審查，重置新的版本的標準配置。對於有些公司每個部門單獨部署自己的產品環境，使用每個部門的標準，還是建議能夠統一一下標準。一是，可以減少重複工作量，二是、統一標準，很容易統一修改和統一升級，統一處理。
3) 開啓無用的服務或接口
產品運行的環境開啓了其他的服務或者無用的接口，而這些服務和接口也成爲了攻擊者攻擊的目標，但是在預防時也很容易被忽略，例如：開啓FTP服務或者Samba服務等。有時爲了維護方便也會開啓一些服務例如：SSH、SNMP等，需要配置好防火牆規則或者訪問的範圍，保證只有在允許的範圍內，才能允許使用此協議訪問。
二 軟件自身的問題
軟件自身的問題，顧名思義，是軟件自身的代碼導致了安全問題的產生。 因爲軟件的代碼基本上不可能全部都是自己寫出來也有可能引用一些第三方的庫，所以，根據代碼所屬的性質，將安全問題分爲兩類：第三方開源代碼的問題和軟件代碼的問題。
1）第三方開源代碼的問題
根據以下統計數據，開源軟件導致的安全問題也是逐年上升：
而且開源軟件影響的面比較大，而且結果很嚴重，例如Openssl的HeartBleed漏洞，影響面非常大，後果很嚴重。 但是， 不管是什麼代碼的問題，對於客戶而言，第三方的漏洞在你的軟件裏被利用了，就是你的軟件的漏洞，你也是要負責任的。
對於使用的是第三方的開源代碼，最重要的第一條就是，務必要遵守第三方開源代碼的license，因爲license會規定你如何使用這些開源代碼，例如：某些開源軟件可能會要求你的產品打上它的logo，如果此種需求不能接受，最好還是別使用。有些很嚴格的license，甚至會要求你如果修改它的代碼，必須也要開源所有相關代碼，有些license可以隨便使用和修改。
如果公司對於所使用的開源軟件從來沒有梳理過，建議還是使用一些專門的產品掃描一下，找到產品中所有使用的第三方軟件，這樣才能再某個開源軟件出現漏洞時，針對自己使用的開源軟件的版本和漏洞發生的版本比對，確定是否影響產品。如果沒有一個使用的開源軟件的庫，那麼即使知道某個開源軟件有漏洞，也無法確定哪些產品受到影響，也就無法進行下一步的修復工作。
下圖根據license的要求的嚴格排了一下順序，針對紅色和黃色的部分，最好分析好license的要求是否可以接受然後再決定是否使用，針對綠色的部分，可以放心使用。
根據license的不同，也就決定了這些開源軟件的漏洞問題該如何處理，一般最好的方式都是升級到開源軟件出新版本，這是最好的方法，不要存在僥倖心理。否則，爲了修改一個小問題，你可能需要研究整個開源代碼，得不償失。對於一些沒有人維護的開源代碼或者多年麼有更新的開源代碼，最好還是悠着點，能不用就不用。因爲一旦出現問題，你只能自己想辦法修復。曾經遇到一個開源代碼，有一個比較嚴重的問題必須修復，但是，開源代碼已經2年沒有人維護了，聯繫作者也沒有任何答覆，幸運的是，license允許修改代碼，於是，只能自己修復此漏洞；由於代碼邏輯不復雜，還好比較容易修復；如果代碼邏輯比較複雜，而且沒有人維護怎麼辦？ 這種情況，還是建議換一個新的有人維護的庫吧。否則，後患無窮。
2） 軟件代碼的問題
對於軟件自身代碼的問題，就需要開發團隊和安全團隊配合了。不過，還是儘早發現儘早修復代價比較小一些，這就是業界說的shift-left，將安全活動向左移，越早介入，發現問題並修復的成本就越低，如下圖：
可見，在產品發佈以後發現並修復漏洞是在初期發現的N倍。曾經參與的一個產品，由於前期沒有關注安全，導致一個嚴重的安全漏洞花了兩個團隊2個月才修復完畢。
軟件自身的安全問題，主要集中在：輸入相關的注入漏洞、輸出相關寫信息泄露，認證與授權，任何一個方面沒有做好，都可能被利用。由於軟件的功能變的越來越複雜，能夠從各個方面都做好預防也是一個挑戰。
業界有個Linus定律（Linus Law）：如果有足夠多的眼睛，所有的bug都將無所遁形。一般研發軟件都要顧及成本，不會提供足夠多的眼睛，那麼，就需要流程和工具協助相關人員來發現代碼中的漏洞。
如何才能在比較早的階段發現軟件代碼自身的漏洞呢？
1） 需要加強培訓
通過培訓提高每一個參與研發與測試人員的安全意識，在日常工作中，就可以時刻關注可能導致安全問題的地方，是一個比較有效的方法。但是，目前，很多研發公司這方面做得並不夠。
2） 安全規範
有了安全意識之後，還需要指導員工怎麼做，通過制定有針對性的安全規範可以很好地指導研發人員如何遵守。在有了安全規範之後，安全規範如何能夠執行到位，還是一個挑戰。每個團隊如何能夠寫出符合安全規範的代碼？如果能夠組織一些懂安全和開發的人員，根據公司的產品架構，提供統一的API，研發人員只要知道如何正確使用安全API就可以了，這樣研發人員的負擔就小了，也容易執行，更容易推行下去。
3） 靜態代碼掃描
有了規範和安全API之後，還需要有效的檢測工具，對於那些依然沒有遵守規範的代碼進行監督，保證規範被遵守，定製化的靜態檢測工具是個不錯的選擇。雖然靜態代碼掃描可以提供效率，但是，靜態代碼掃描工具有一個比較大的缺點就是誤報率。在衆多的掃描結果中篩選出有效的漏洞是一個比較大的挑戰，這就需要安全專業人員的協助。目前，業界比較好的工具也不少，但是，無論使用什麼工具，比解決誤報的問題，會讓研發人員非常頭大。可以想象當你從1000個漏洞裏，跳出三四百個有效漏洞，是多麼浪費時間和多麼沮喪。雖然有些工具提供定製規則的功能，但是，定製一個規則，需要了解一個漏洞的來龍去脈，同時，還要了解如何定製一個有效的規則，也是需要專業的安全人員協助才能完成。關於靜態掃描工具，可以參考https://owasp.org/www-community/controls/Static_Code_Analysis和https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis的介紹。
4） 滲透測試
滲透測試也有一些自動化工具，但是，自動化工具比較慢，而且有些安全問題工具是不能發現的。所以需要工具結合人工工具會更有效，例如：認證和授權相關漏洞，目前業界還沒有很有效的測試工具可以自動發現此類問題。由於滲透測試是黑盒測試，所以，測試的覆蓋率是一個很大的挑戰，既要熟悉業務，又要了解如何利用可能的業務邏輯發起攻擊，對人員的要求還是比較高的。如果能夠有自動化功能測試用例中加上一些攻擊測試向量再結合IAST可能效果更好。滲透測試的結果和測試人員的態度以及專業度有很大的關係，如果能夠有大於等於2人共同參與測試，效果會更好。當然不需要2個人同時執行測試，可以一個人寫測試用例，另外一個人負責審查，找出可能遺漏的用例。 自動化滲透測試工具目前比較知名的有AppScan和WebInspect。
5） 威脅建模
需要關注和測試那些範疇呢？ 威脅建模可以通過模型建模分析出整個框架中使用的架構、協議和存儲類型等，能夠指導設計人員瞭解哪些威脅，如何通過設計避免這些威脅；也可以作爲測試人員的指導文檔，使測試人員有目的的做針對性測試。不過做威脅建模需要了解的支持比較全面，需要工具和安全專業人員結合起來做纔可以。目前業界微軟出了威脅建模工具還有OWASP也出了威脅建模工具threat-dragon。不過這些工具使用起來，還不是很好用。如果自己能夠定製化，效果纔會好一些。
6） 安全開發流程
任何措施再有效，如果沒有一個很容易執行的流程來保證，效率可能會大打折扣。因此，制定一個符合當前組織架構的流程變的尤爲重要。這就需要安全流程制定人員根據組織的架構、開發流程的類型、研發的軟件類型等制定一個有效的流程來保證每一個階段每一個步驟制定的安全措施都能夠被嚴格執行。
沒有任何一個流程是永久適用的，需要根據組織的架構的變動和研發流程類型的改變適當調整，採用PDCA循環，不斷改進，才能更適應企業的發展。
業界比較有名的是微軟的CSDLhttps://www.microsoft.com/en-us/securityengineering/sdl/practices，不過，流程比較多，比較重，直接用起來，還是比較費力的。
7） 領導的支持
無論做什麼，怎麼做？都必須得到領導的大力支持，否則，沒人、沒資源、沒有工具、沒有相關部門的支持，什麼都做不成。
總之，安全要做好，必須融入到每個階段所做的事情當中，讓每個人都重視，並且有很好的人員、工具和流程支持，纔能有效地做好。
