源代碼安全測試不再是新鮮話題，在很多的企業已經開展了相關工作，對于已經開展此項目工作的企業來說，我想問的問題則是“在你的源代碼安全測試工作中所面臨的最大阻力是什么?” 這個問題不同的企業可能有不同的答案，且各有各的道理。

[[177614]]

其實，據我總結來看，很多的阻力表象最終都可以歸結為“開發人員不配合”的問題。那為什么開發人員不配合源代碼安全的相關工作呢?換句話說：如何讓開發者愛上安全測試呢?

“源代碼安全測試”——想說愛你不容易

對于開發者而言，源代碼安全測試不是我們不想做，也不是我們不愿意配合工作，而是總有這樣那樣的問題，讓我們實在愛不起來。原因歸納總結如下：

1. 測試的范圍不清楚

對于安全，我們都知道一個道理，沒有絕對的安全只有相對的安全。在很多企業中，源代碼安全測試的范圍和標準都是由安全部門一手“包辦”的。確定哪些漏洞需要修復，哪些漏洞建議修復，哪些漏洞可以暫緩修復等范圍和標準都是由安全部門人員說了算。這樣一來，安全部門人員由于職責所在，同時加上現在的安全漏洞層出不窮，花樣頗多的“壓力”，安全范圍和標準大都定的高一些，甚至一個項目一個標準，能改盡量要求改。而且由于“語言上的不通”(安全人員不懂開發，無法用編程的語言與開發者溝通)，這些范圍和要求也很少與開發人員進行溝通。這樣就導致開發人員總是感覺“安全人員老是挑刺，總是雞蛋里挑骨頭! 他們能查到什么就讓我們改什么!”等等這樣的感受。好像怎樣做都無法滿足安全上的要求。進而產生不愿意配合漏洞的測試和修復工作，甚至是 “對抗”的情緒。久而久之，源代碼安全測試工作就很難再推動下去。

2. 測試的結果不準確

無論是安全性測試還是其他類型的測試，我想所有的測試人員都希望測試出來的問題即全面又準確。這也是我們所有從事測試工具研究人員的理想，而現實卻總是有些“骨感”。面對目前市面上的所有源代碼安全測試產品，沒有任何一家可以說自己的產品即沒有誤報也沒有漏報。由于在安全測試的概念中，漏報的后果比誤報嚴重，所以大多數產品廠商會選擇“寧可錯報，不可漏報”的設計原則。這些原本作為輔助工具的測試產品在進入用戶企業中后，卻被不科學地當成了“裁判”，并且將其測試出來的原始結果在沒有經過任何專業安全審計的情況下直接遞交到開發人員手中。

即使有專人專崗的安全審計人員，他們在安全漏洞審計過程中由于缺乏有效的溝通方式，很少與開發人員進行技術溝通，審計出來的結果也會被當著“一面之詞”。(這里我們且不討論純人工進行的源代碼安全審計，因為到目前為止我也沒有看到一家用戶這么干，自己寫點兒小工具或者腳本輔助人工審計的到是有一些，只是那些自己寫的小工具或者腳本誤漏報更是一堆。)開發人員在面對這些“漏洞信息”時，加之本身都不愿意相信自己的“作品”有問題的心理，便會對安全測試結果從相信到懷疑，再到完全的不信任，最后就會抱怨“全是誤報!”，便再也沒有配合修復漏洞的想法了。

3. 測試的時間不及時

做過軟件開發的人都知道，即便是自己寫的代碼，如果隔上一兩個月的時間，想再看明白為什么這么編寫都比較困難。如果隔上一年半載，加之別人寫的代碼，那維護起來就難上加難了。這也是程序猿們所提倡的“敏捷開發”和“快速迭代”理念的原由。在源代碼安全測試中，我們也應該提出“敏捷安全測試”的理念，要盡量在開發人員每一個小的迭代時，就要完成一個安全測試，修復起來也更加容易。

但現實中的源代碼安全測試是什么樣子呢?絕大多數的企業把源代碼安全測試和安全滲透測試基本都放到了“驗收測試”階段中。項目只有在上線、發布或者交付之前才做一次安全測試。而這些開發周期少則半年多則幾年的項目，到了驗收階段時，這些開發人員再對修改幾個月幾年前的代碼，那是多么郁悶呀!另外，由于平時沒有測試，漏洞量和代碼一樣會積少成多，這個階段檢測出來的漏洞往往會很多，很復雜。這怎么能讓開發人員欣然接受、積極配合呢?恐怕只剩下“能推就推，能不承認就不承認”了吧!

4. 測試的成本太高昂

這個原因，我們可以接上一個原因往下講。當聰明的開發人員發現項目最終總是會被動地被“安全驗收測試”，那時再修復起來會手忙腳亂，不如功在平時，在開發過程中主動地、自主地先對源代碼安全測試一下，將漏洞化整為零，及時測試，及時修復。這樣的想法是非常好的，可以在實施的時候就會發現有這樣那樣的問題，要么由于安全測試工具License的限制，只能由專門的安全人員或者測試人員才能使用，而他們本身忙于對企業內眾多項目的“安全驗收”測試，沒有時間和精力來為您“開小灶”。要么安全測試工具使用起來較麻煩，沒有受過專業的產品使用培訓還真不太能玩得轉，且要準備這樣那樣的測試環境等等。要么就是安全測試工具很消耗系統的資源，不能實現較大的吞吐量，無法滿足每一個項目在開發過程的多輪次的源代碼安全測試。這就使得開發人員自主主動地源代碼安全測試變得很難，甚至是不可能進行下去。

5. 修復的方法不明確

在生活中我們通常都明的一個道理：“己所不欲，忽施于人”，自己做不到的事情，也不能要求別人要做到。在源代碼安全測試或者說安全編程這件事上，恰恰違背了這一點。在大多數的情況下，安全漏洞從發現到確認都是由安全人員來完成的，開發人員都是在為修復安全漏洞而努力。目前，開發人員缺乏安全漏洞的修復經驗和相關的安全編程知識，這是普遍存在的現狀，即使有十幾年開發經驗的“老司機”在一些安全漏洞面前，也都還是“小學生”。所以，開發人員勢必要詢問安全人員如何對這些漏洞進行修復，如何避免這些安全上的“坑”。

但是，這些安全人員雖可以對這些漏洞如數家珍，安全滲透玩得有模有樣，可在代碼開發和安全編碼方面著實是個“門外漢”。站在有著十幾年開發經驗的老手面前，若只是根據測試工具給出的那些“標準答案”，可能也不好交差。最后會讓開發人員感覺到很無奈，想配合進行安全修復都沒有一個具體明確的方法，還要一點點地自行研究和嘗試。還有一點，即便是開發人員經過一段時間的積累和總結，有了一些安全開發和修復的經驗，也都因為沒有一個經驗共享和傳承的平臺，這些寶貴的經驗只能散落在各個項目中，個別開發人員手上，沒有形成統一的修復方法，是非常可惜的事情。最終因項目的不斷交替，人員的頻繁流動。新的開發人員不斷地抱怨著，且不斷地重復地走在研究各個漏洞修復方法的路上。

(注意: 以上原因皆為筆者自己在工作中歸納總結出來的，請勿對號入座!)

如何讓開發者愛上“源代碼安全測試”?

[[177615]]

既然我們已經了解了開發人員不是很配合源代碼安全測試這件事的原因，我們要想順利地開展此項目工作就應該盡量避免這些問題。以我這些年為用戶服務的經驗，我總結了一些基本方法，或許可以幫助大家將這些問題一一克服，讓開發人員能夠接受源代碼安全測試，甚至是愛上安全測試。基本方法如下：

1. 建立明確的安全測試范圍和標準。明確地讓開發人員知道要檢測的內容和標準，當然這個安全測試標準，一定是要安全部門和開發部門一起進行討論和協商而來的，讓大家都能夠明白這些漏洞的危害，造成的影響等。

2. 建立安全審計團隊，總結安全漏洞審計指南。安全測試本身可以盡量地自動化實現，但測試工具測試出來的漏洞，仍然需要大量的人員安全審計才行。因此要培養相關人員，建立有效的安全審計團隊，確保測試結果的相對準確性，來減少開發人的員的不必要的修復工作。同時，可以在工作中總結一些安全審計的方法，編寫出審計指南，方便分享和傳遞。

3. 建立企業安全測試私云，形成敏捷源代碼安全測試模式。企業在選擇測試工具時，一定要盡可能地考慮一些有企業級測試私有云的測試解決方案，這樣可以在企業內部建立一個統一的私有測試云平臺，擴大使用范圍，最好讓開發人員在開發過程中實現迭代測試，當然，這還有一個前提就是把源代碼安全測試做得一定要方便，簡單，易操作，成本小。

4. 建立企業安全知識交流和分享平臺，形成企業自有的安全編碼庫。這一個方面是開發人員最為關心，做好了也是最為喜歡的部分，就是可以在企業內部建立一個安全知識交流，學習，分享的平臺。大家可以共同研究和學習漏洞知識以及修復方案。最終可以形式企業自有的安全編碼沒庫。這是最理想的。

5. 定期組織軟件安全知識培訓和講座，提高整體人員安全水平。我常常聽到開發人員給安全測試人員說:”我們不怕測出安全漏洞多，只要告訴我們準確的修復方法，我們來改就行;你們最好給我們一個安全的編程方法，以后我們能就盡量避免漏洞”。”修復方法”、”安全編程”。就是軟件安全開發知識中的基本內容了。所以，企業應該定期或者不定期地給相關技術人員，特別是開發人員進行安全知識培訓，針對安全漏洞進行集中式安全編程培訓，這樣就可以從開發意識和開發習慣上杜絕安全漏洞。另一方面，技術人員能夠在工作中不斷地學習和成長，也是企業應盡的義務。

結語

“讓開發者愛上安全測試”，這是一個統籌的理念，它包括諸多的意義。尤如前文所說的，在通常的安全測試過程中，問題表象好像是“開發人員的不配合和不支持”，但實質則是整體軟件安全體系建設的不全面和不完整所導致的。只能通過疏通每一個環節上的問題，建立一個整體的軟件安全開發管理體系才能讓各個部門，各個角色的人員都能積極配合起來，才能“讓大家愛上安全測試”。