聊一聊應用安全那點事
從我最開始學習安全接觸的就是 web 安全相關，當時的自己完全不明白學習的意義是什么，只知道學習了 web 安全可以去網絡上尋找存在漏洞的應用，拿到 webshell、然后提升權限到系統最高權限，這一個流程下來基本就達到了頂峰，在突破的時候是最有成就感的，我相信有非常多的同行是在這樣的情況下入行的。web 安全就是應用安全中的一部分。
說到應用，什么是應用?百度百科上說的一句 適應需要，以供使用 ，在現在的互聯網時代，所有的軟件都可以叫應用，他們的產生是為了滿足我們的日常需求，方便我們的衣食住行，多年前是 PC 互聯網的時代，近幾年進入了移動互聯網時代，未來會是物聯網時代、人工智能的時代 等等，隨著科技的進步，安全的需求也在不斷發生著變化，近幾年做滲透的朋友越來越感覺到難做，web 的安全漏洞越來越少，這可以說是時代的進步、安全意識的提升、代碼安全性增加、應用主戰場的變化 等等一系列因素的結果，這對于安全行業來說是好事，整體安全性在不斷提升，側面說明我們安全從業人員的價值體現。
對于應用產生的整個生命周期來講，考慮安全越早越好，早期的應用主要是為了實現功能、快速上線，互聯網行業迭代更新非常快，時間就是競爭力，只有在業務因為安全問題而出現重大損失的時候才專門去招人或者購買安全服務進行及時止損，在上線之前沒有考慮安全，帶洞上線，從而導致大量的用戶隱私泄漏，最終的受害者還是使用應用的用戶，經過多年安全人員的努力，企業對于安全也慢慢重視起來，那么如何做好應用安全呢?
SDLC 大家都聽過，翻譯過來就是軟件開發生命周期，是為了規范開發的流程、提升開發效率、增強代碼質量，做到閉環，SDLC 包含五個階段：需求分析、設計、編碼、測試、發布，如圖：
但這里并沒有把安全考慮進去，我們是否可以將安全貫穿到整個軟件開發的生命周期呢?如何做?請看下圖：
- 在需求階段做風險評估，提前將風險識別出來，作為安全的需求提交給研發，不只是功能上的，還包括一些架構不合理的地方，這對安全人員對能力要求是非常高的;
- 在設計階段做威脅建模、安全參與進行設計 review，指出設計存在的安全威脅，共同完成安全的設計方案;
- 在開發階段，要進行代碼 review，提前做代碼審計通過人工或者自動化的方式，這里對安全專業人才的需求也很高;
- 在測試階段進行安全評估，也就是安全測試或者滲透測試，通過黑盒的方式找出安全 bug，在上線之前解決掉，可以用功能測試的小伙伴進行合作或者其他的方式;
- 在發布階段要對主機進行安全檢查，升級最新補丁、關閉無用端口等，將攻擊面降到最低;
- 上線之后，通過開始 SRC 平臺接收來自白帽子的漏洞提交，補充安全測試不足，做到閉環;
經過上面的一系列操作之后，可以將大部分的安全問題扼殺在上線之前，從而大大降低應用的安全風險，但是完全這么做是需要大量的人力和時間的，對于大部分企業來說是不可能完全做到的，因為可能因為流程的復雜度或者人員的能力問題，造成項目的延期、錯事商機，具體做不做以及怎么做，需要上層領導的支持，不同公司的情況不同，需要制定的流程也不一樣，落地情況也不同。
理想的情況下是完全按照上面的流程做每一個項目，這是多少安全負責人的理想，可是往往投入產出比不那么好看，得不到領導的支持，參與流程的同事也很抵觸這么做，畢竟增加工作量多事，不是所有人都愿意做的，所以作為安全人員并不能強迫大家都按照你的要求來做，就需要平衡我們與開發人員之間的關系，在不增加別人工作量的同時，提升軟件安全性，在規范流程的同時，提升自動化能力，將研發當作我們的用戶，我們是為業務服務的，而不是監管機構。
今天就聊到這里吧，想要落地這個并沒有那么容易，也不是每一家公司都能做到，在自身人力不足的情況下還是不要做這個，做好滲透測試，在惡意攻擊之前發現安全問題，推動開發盡快修復安全問題，如果業務系統比較多，自身無法覆蓋全面的滲透測試，可以開設 SRC 集白帽子之力來幫助企業發現安全問題，然后自研掃描器，將歷史安全問題集成到掃描器中，保證歷史安全問題不再出現，我們的價值也就能夠很好的體現了，安全無止境，共勉!
