“讓開發者愛上安全測試”系列之“原始碼安全測試”——開發者之傷
原始碼安全測試不再是新鮮話題，在很多的企業已經開展了相關工作，對於已經開展此專案工作的企業來說，我想問的問題則是“在你的原始碼安全測試工作中所面臨的最大阻力是什麼?” 這個問題不同的企業可能有不同的答案，且各有各的道理。
其實，據我總結來看，很多的阻力表象最終都可以歸結為“開發人員不配合”的問題。那為什麼開發人員不配合原始碼安全的相關工作呢?換句話說：如何讓開發者愛上安全測試呢?
“原始碼安全測試”——想說愛你不容易
對於開發者而言，原始碼安全測試不是我們不想做，也不是我們不願意配合工作，而是總有這樣那樣的問題，讓我們實在愛不起來。原因歸納總結如下：
1. 測試的範圍不清楚
對於安全，我們都知道一個道理，沒有絕對的安全只有相對的安全。在很多企業中，原始碼安全測試的範圍和標準都是由安全部門一手“包辦”的。確定哪些漏洞需要修復，哪些漏洞建議修復，哪些漏洞可以暫緩修復等範圍和標準都是由安全部門人員說了算。這樣一來，安全部門人員由於職責所在，同時加上現在的安全漏洞層出不窮，花樣頗多的“壓力”，安全範圍和標準大都定的高一些，甚至一個專案一個標準，能改儘量要求改。而且由於“語言上的不通”(安全人員不懂開發，無法用程式設計的語言與開發者溝通)，這些範圍和要求也很少與開發人員進行溝通。這樣就導致開發人員總是感覺“安全人員老是挑刺，總是雞蛋裡挑骨頭! 他們能查到什麼就讓我們改什麼!”等等這樣的感受。好像怎樣做都無法滿足安全上的要求。進而產生不願意配合漏洞的測試和修復工作，甚至是 “對抗”的情緒。久而久之，原始碼安全測試工作就很難再推動下去。
2. 測試的結果不準確
無論是安全性測試還是其他型別的測試，我想所有的測試人員都希望測試出來的問題即全面又準確。這也是我們所有從事測試工具研究人員的理想，而現實卻總是有些“骨感”。面對目前市面上的所有原始碼安全測試產品，沒有任何一家可以說自己的產品即沒有誤報也沒有漏報。由於在安全測試的概念中，漏報的後果比誤報嚴重，所以大多數產品廠商會選擇“寧可錯報，不可漏報”的設計原則。這些原本作為輔助工具的測試產品在進入使用者企業中後，卻被不科學地當成了“裁判”，並且將其測試出來的原始結果在沒有經過任何專業安全審計的情況下直接遞交到開發人員手中。
即使有專人專崗的安全審計人員，他們在安全漏洞審計過程中由於缺乏有效的溝通方式，很少與開發人員進行技術溝通，審計出來的結果也會被當著“一面之詞”。(這裡我們且不討論純人工進行的原始碼安全審計，因為到目前為止我也沒有看到一家使用者這麼幹，自己寫點兒小工具或者指令碼輔助人工審計的到是有一些，只是那些自己寫的小工具或者指令碼誤漏報更是一堆。)開發人員在面對這些“漏洞資訊”時，加之本身都不願意相信自己的“作品”有問題的心理，便會對安全測試結果從相信到懷疑，再到完全的不信任，最後就會抱怨“全是誤報!”，便再也沒有配合修復漏洞的想法了。
3. 測試的時間不及時
做過軟體開發的人都知道，即便是自己寫的程式碼，如果隔上一兩個月的時間，想再看明白為什麼這麼編寫都比較困難。如果隔上一年半載，加之別人寫的程式碼，那維護起來就難上加難了。這也是程式猿們所提倡的“敏捷開發”和“快速迭代”理念的原由。在原始碼安全測試中，我們也應該提出“敏捷安全測試”的理念，要儘量在開發人員每一個小的迭代時，就要完成一個安全測試，修復起來也更加容易。
但現實中的原始碼安全測試是什麼樣子呢?絕大多數的企業把原始碼安全測試和安全滲透測試基本都放到了“驗收測試”階段中。專案只有在上線、釋出或者交付之前才做一次安全測試。而這些開發週期少則半年多則幾年的專案，到了驗收階段時，這些開發人員再對修改幾個月幾年前的程式碼，那是多麼鬱悶呀!另外，由於平時沒有測試，漏洞量和程式碼一樣會積少成多，這個階段檢測出來的漏洞往往會很多，很複雜。這怎麼能讓開發人員欣然接受、積極配合呢?恐怕只剩下“能推就推，能不承認就不承認”了吧!
4. 測試的成本太高昂
這個原因，我們可以接上一個原因往下講。當聰明的開發人員發現專案最終總是會被動地被“安全驗收測試”，那時再修復起來會手忙腳亂，不如功在平時，在開發過程中主動地、自主地先對原始碼安全測試一下，將漏洞化整為零，及時測試，及時修復。這樣的想法是非常好的，可以在實施的時候就會發現有這樣那樣的問題，要麼由於安全測試工具License的限制，只能由專門的安全人員或者測試人員才能使用，而他們本身忙於對企業內眾多專案的“安全驗收”測試，沒有時間和精力來為您“開小灶”。要麼安全測試工具使用起來較麻煩，沒有受過專業的產品使用培訓還真不太能玩得轉，且要準備這樣那樣的測試環境等等。要麼就是安全測試工具很消耗系統的資源，不能實現較大的吞吐量，無法滿足每一個專案在開發過程的多輪次的原始碼安全測試。這就使得開發人員自主主動地原始碼安全測試變得很難，甚至是不可能進行下去。
5. 修復的方法不明確
在生活中我們通常都明的一個道理：“己所不欲，忽施於人”，自己做不到的事情，也不能要求別人要做到。在原始碼安全測試或者說安全程式設計這件事上，恰恰違背了這一點。在大多數的情況下，安全漏洞從發現到確認都是由安全人員來完成的，開發人員都是在為修復安全漏洞而努力。目前，開發人員缺乏安全漏洞的修復經驗和相關的安全程式設計知識，這是普遍存在的現狀，即使有十幾年開發經驗的“老司機”在一些安全漏洞面前，也都還是“小學生”。所以，開發人員勢必要詢問安全人員如何對這些漏洞進行修復，如何避免這些安全上的“坑”。
但是，這些安全人員雖可以對這些漏洞如數家珍，安全滲透玩得有模有樣，可在程式碼開發和安全編碼方面著實是個“門外漢”。站在有著十幾年開發經驗的老手面前，若只是根據測試工具給出的那些“標準答案”，可能也不好交差。最後會讓開發人員感覺到很無奈，想配合進行安全修復都沒有一個具體明確的方法，還要一點點地自行研究和嘗試。還有一點，即便是開發人員經過一段時間的積累和總結，有了一些安全開發和修復的經驗，也都因為沒有一個經驗共享和傳承的平臺，這些寶貴的經驗只能散落在各個專案中，個別開發人員手上，沒有形成統一的修復方法，是非常可惜的事情。最終因專案的不斷交替，人員的頻繁流動。新的開發人員不斷地抱怨著，且不斷地重複地走在研究各個漏洞修復方法的路上。
(注意: 以上原因皆為筆者自己在工作中歸納總結出來的，請勿對號入座!)
如何讓開發者愛上“原始碼安全測試”?
既然我們已經瞭解了開發人員不是很配合原始碼安全測試這件事的原因，我們要想順利地開展此專案工作就應該儘量避免這些問題。以我這些年為使用者服務的經驗，我總結了一些基本方法，或許可以幫助大家將這些問題一一克服，讓開發人員能夠接受原始碼安全測試，甚至是愛上安全測試。基本方法如下：
1. 建立明確的安全測試範圍和標準。明確地讓開發人員知道要檢測的內容和標準，當然這個安全測試標準，一定是要安全部門和開發部門一起進行討論和協商而來的，讓大家都能夠明白這些漏洞的危害，造成的影響等。
2. 建立安全審計團隊，總結安全漏洞審計指南。安全測試本身可以儘量地自動化實現，但測試工具測試出來的漏洞，仍然需要大量的人員安全審計才行。因此要培養相關人員，建立有效的安全審計團隊，確保測試結果的相對準確性，來減少開發人的員的不必要的修復工作。同時，可以在工作中總結一些安全審計的方法，編寫出審計指南，方便分享和傳遞。
3. 建立企業安全測試私雲，形成敏捷原始碼安全測試模式。企業在選擇測試工具時，一定要儘可能地考慮一些有企業級測試私有云的測試解決方案，這樣可以在企業內部建立一個統一的私有測試雲平臺，擴大使用範圍，最好讓開發人員在開發過程中實現迭代測試，當然，這還有一個前提就是把原始碼安全測試做得一定要方便，簡單，易操作，成本小。
4. 建立企業安全知識交流和分享平臺，形成企業自有的安全編碼庫。這一個方面是開發人員最為關心，做好了也是最為喜歡的部分，就是可以在企業內部建立一個安全知識交流，學習，分享的平臺。大家可以共同研究和學習漏洞知識以及修復方案。最終可以形式企業自有的安全編碼沒庫。這是最理想的。
5. 定期組織軟體安全知識培訓和講座，提高整體人員安全水平。我常常聽到開發人員給安全測試人員說:”我們不怕測出安全漏洞多，只要告訴我們準確的修復方法，我們來改就行;你們最好給我們一個安全的程式設計方法，以後我們能就儘量避免漏洞”。”修復方法”、”安全程式設計”。就是軟體安全開發知識中的基本內容了。所以，企業應該定期或者不定期地給相關技術人員，特別是開發人員進行安全知識培訓，針對安全漏洞進行集中式安全程式設計培訓，這樣就可以從開發意識和開發習慣上杜絕安全漏洞。另一方面，技術人員能夠在工作中不斷地學習和成長，也是企業應盡的義務。
結語
“讓開發者愛上安全測試”，這是一個統籌的理念，它包括諸多的意義。尤如前文所說的，在通常的安全測試過程中，問題表象好像是“開發人員的不配合和不支援”，但實質則是整體軟體安全體系建設的不全面和不完整所導致的。只能通過疏通每一個環節上的問題，建立一個整體的軟體安全開發管理體系才能讓各個部門，各個角色的人員都能積極配合起來，才能“讓大家愛上安全測試”。
【編輯推薦】