前言
敏捷開發(fā)是現(xiàn)在主流的開發(fā)模式偿枕，相對于傳統(tǒng)的瀑布式開放璧瞬，它通過快速的迭代來響應(yīng)和展示客戶的需求户辫，敏捷開發(fā)的優(yōu)點已經(jīng)是眾所周知了。但是敏捷開發(fā)已經(jīng)實施了很多年了嗤锉，項目安全問題還是和瀑布開發(fā)開放模式一樣沒有得到解決渔欢，都是到項目上線前一兩個禮拜才進行安全測試和滲透測試。
這種模式有非常大的弊端膘茎，第一桃纯，很多安全問題應(yīng)該在架構(gòu)設(shè)計和coding的時候就要考慮到的酷誓，在項目快結(jié)束的時候去解決已經(jīng)太晚了。第二态坦，從我的經(jīng)歷來看盐数，大多數(shù)項目由于各種原因都會有延遲的情況，這個時候上線壓力非常大伞梯。即使發(fā)現(xiàn)了很多安全漏洞玫氢，由于修復(fù)代價非常的高，項目經(jīng)理通常會采取折中的方案來保障上線谜诫。任何折中方案都會導(dǎo)致漏洞直接上線漾峡，暴露在黑客面前，給產(chǎn)品帶來非常大的風(fēng)險喻旷。
將安全問題留到最后解決是非常危險的生逸，但是在立項的時候就把安全問題全部放到項目開始階段也并不是非常可取的且预，軟件架構(gòu)包含很多跨功能的需求槽袄，比如性能、擴展性以及安全锋谐。這些需求通常應(yīng)該在代碼設(shè)計前設(shè)計和決定如何實施遍尺，因為這個時間點才會有足夠的信息來做正確的決定。太早的時候決定這些跨功能需求由于沒有足夠的信息會帶來安全風(fēng)險涮拗，等發(fā)現(xiàn)想修改架構(gòu)時因為代價太高乾戏，已經(jīng)太晚了。
將安全問題放在項目開始或者結(jié)束的時候來考慮都是極端的做法三热，那在敏捷開發(fā)的項目如何解決安全問題呢歧蕉？正確的做法是在項目開始時考慮好項目安全需要做哪方面的工作，需要什么樣的架構(gòu)設(shè)計康铭，在開發(fā)過程中始終考慮安全因素惯退，在項目結(jié)束時進行必要的安全測試。
從筆者的個人項目經(jīng)驗从藤，做到以下幾點也可以讓安全也可以敏捷起來催跪。
1. 貫徹安全編碼規(guī)范
如果每個開發(fā)人員都知道如何編寫安全的代碼那么很多應(yīng)用程序的安全漏洞都能夠避免锁蠕。比如：在處理用戶輸入時，應(yīng)該知道如何做輸入校驗懊蒸。在將用戶信息存入數(shù)據(jù)庫時荣倾，應(yīng)該知道講敏感信息進行加密或者混淆。在進行數(shù)據(jù)傳輸時要確保傳輸通道安全及對內(nèi)容加密骑丸。在返回錯誤信息和log時要對輸出進行消毒等等舌仍。精通OWASP Top 10應(yīng)用安全漏洞是每個應(yīng)用程序開發(fā)人員的必備技能。WebGoat是一個非常好的學(xué)習(xí)的網(wǎng)站通危，網(wǎng)絡(luò)上也有很多相關(guān)的支援铸豁。中國古話說得好“磨刀不誤砍柴工”，在項目開始對程序員舉行必要的安全等方面的培訓(xùn)是非常有必要的菊碟。
2. 每個項目組應(yīng)該有一名安全專家
坦率講讓每個程序?qū)Π踩猩畹睦斫馐遣滑F(xiàn)實的节芥，有很多安全問題是需要專家的眼睛才能發(fā)現(xiàn)。安全專家是剛需逆害，強烈推薦每個項目組有一個在應(yīng)用安全領(lǐng)域有比較深研究和理解的資深程序員头镊。需要安全專家的級別和能力可以根據(jù)項目對安全的要求來定，當(dāng)然有條件的情況魄幕，專家能力越強對項目的安全保障越好相艇。在沒有請安全專家能力的團隊可以由安全經(jīng)驗豐富的資深工程師來擔(dān)任也是可以的。安全專家的主要職責(zé)包括：
- 在開發(fā)安全敏感度非常高的用戶故事時和工程師們結(jié)對編程
- 對工程師的代碼進行安全評審纯陨，確保代碼在提交到代碼庫前沒有安全問題
- 在選擇使用哪些商業(yè)代碼坛芽，開源庫，公共API等第三方庫時進行安全分析和決定
- 幫助QA人員測試安全敏感度高的用戶故事队丝，確保程序安全靡馁。
除了這些以外，安全專家還應(yīng)該幫助程序員熟悉安全編碼机久，將安全知識分享給每個程序員臭墨，提高程序員的安全意識。
- 識別安全敏感度高的用戶故事
八二原則在安全也是適用的膘盖，80%的安全問題是由20%的用戶故事導(dǎo)致的胧弛，安全專家要識別出安全敏感度高的用戶故事欲鹏，將有限的資源有限放在這些故事里。安全專家可以在每個迭代開始前利用計劃會議將這些安全敏感度的故事識別出來并標(biāo)志出來锻煌。讓每個程序員對這些用戶故事在安全方面加以重視慨削。舉幾個應(yīng)該標(biāo)為安全敏感度高的用戶故事：
- 包含用戶輸入選項（比如輸入框，選擇框等等）
- 存儲數(shù)據(jù)到數(shù)據(jù)庫
- 數(shù)據(jù)傳輸?shù)酵獠肯到y(tǒng)
- 處理外部系統(tǒng)傳入的數(shù)據(jù)
- 輸出信息到外部系統(tǒng)和文件等诫欠。
- 處理驗證和認證流程
4. 每個安全敏感用戶故事都應(yīng)該有惡意測試
每個用戶故事都事先設(shè)計可接受條件潦刃，項目負責(zé)人可以在安全專家的幫助下從安全的角度設(shè)計可接受條件变隔，安全專家應(yīng)該寫一些惡意的或者破壞性的測試條件，類似于功能測試用例茵宪。就是從黑客的角度去思考問題最冰，如何攻破這些用戶故事。
5. 在用戶故事被接收前舉行嚴格的安全測試
傳統(tǒng)模式是在項目結(jié)束前才舉行安全測試稀火，在敏捷模式下暖哨，每個用戶故事在被接受前都應(yīng)該進行安全測試，QA人員可以在安全專家指導(dǎo)下和功能測試一起執(zhí)行惡意測試凰狞，也可以使用靜態(tài)和動態(tài)掃描工具對代碼舉行漏洞掃描篇裁，一旦發(fā)現(xiàn)安全問題，和功能bug一樣赡若，用戶故事將會退回給開發(fā)人員進行修復(fù)达布，修復(fù)完畢后再進行測試。這種循環(huán)可以進行多次直到?jīng)]有問題發(fā)現(xiàn)斩熊。用戶故事才能被接受往枣。
安全測試自動化還是手工呢伐庭？
自動化化測試是敏捷開發(fā)中非常重要的一個基礎(chǔ)粉渠，也可以說沒有自動化就沒有敏捷模式。安全測試也是同樣如此圾另。自動化不是萬能的霸株，很多測試是自動化沒有辦法完成的，片面最求完全自動化是不可取的集乔。對安全尤其如此去件，比較好的方式是，安全專家先通過手工的方式找到漏洞扰路，然后將這個找漏洞的過程自動化尤溜，避免新的代碼改動引起同樣的漏洞。
后語：
這幾種實踐實際上是和敏捷開發(fā)思想是一致的汗唱，就是將整個安全的需求拆分到每個迭代里宫莱，讓安全需求由抽象變?yōu)榫唧w，在確保每個用戶故事安全的前提下進而確保整個項目的安全哩罪。但是說起來容易做起來的確不簡單授霸，安全專家和有安全意識和能力的開發(fā)人員是稀缺資源，尤其在中國际插，大家重視項目安全也是最近一兩年的事情碘耳，安全人員的培養(yǎng)沒有跟上來。
在這種情況下完全按照這個實踐是不太現(xiàn)實的框弛，針對這種情況 Gartner 在2014年就提出了 RASP 的概念辛辨，就是將這些實踐抽象成一種通用化的產(chǎn)品，將安全編碼規(guī)范和漏洞發(fā)現(xiàn)融合成一種安全產(chǎn)品，開發(fā)人員可以講 RASP 產(chǎn)品結(jié)合掃描工具在運行時對產(chǎn)品漏洞檢測斗搞，很快就定位哪行代碼存在安全漏洞绞蹦。這種產(chǎn)品的理念和敏捷開發(fā)非常的匹配。大家有興趣可以嘗試一下榜旦。相關(guān)資料可以通過 Google 和百度可以找到幽七。
本文系 OneRASP 安全總監(jiān)劉再耀原創(chuàng)文章。如今溅呢，多樣化的攻擊手段層出不窮澡屡，傳統(tǒng)安全解決方案越來越難以應(yīng)對網(wǎng)絡(luò)安全攻擊。OneRASP 實時應(yīng)用自我保護技術(shù)咐旧，可以為軟件產(chǎn)品提供精準(zhǔn)的實時保護驶鹉，使其免受漏洞所累。想閱讀更多技術(shù)文章铣墨，請訪問 OneAPM 官方技術(shù)博客室埋。
本文轉(zhuǎn)自 OneAPM 官方博客
