選單
GSS 技術部落格
在這個園地裡我們將從技術、專案管理、客戶對談面和大家分享我們多年的經驗,希望大家不管是喜歡或是有意見,都可以回饋給我們,讓我們有機會和大家對話並一起成長!
若有任何問題請來信:gss_crm@gss.com.tw
3 分鐘閱讀時間 (590 個字)

開發人員安全程式學習指南!!!

開發人員安全程式學習指南!!!

Foreword前言




        根據美國國土安全局發布的論文(註1)指出,軟體安全基本上是軟體功能的問題之一,必需在軟體開發生命周期中有系統的管理及學習。




       人們普遍認為安全來自於軟體工程師,但依據Node.js®和Sqreen的研究(註2),六成的工程師對於自己開發應用系統的安全強度沒有信心。這與SANS於2016年的應用程式安全報告(註3)的結果相符,該報告指出最核心的挑戰在於缺乏應用程式安全(AppSec)的技能、工具與方法。




      而為什麼會缺少AppSec的技能?從cloudpassage(註4)的研究可以發現在美國computer science學程中只有一間要求安全概念課程才能畢業。依據StackOverflow(註5)的統計69.1%的工程師其實是自學而來的。這告訴我們若企業希望自己的工程師交付安全的程式碼,需要提供他們一流的安全程式撰寫教育訓練(secure coding education, SCE)。進一步來說,若企業也認同,依據SANS(註3)的報告企業認為開發人員的訓練中比起弱點的掃描/檢測,更加需要加強的是應用程式安全(AppSec)的技能。不過現實生活中即使企業安排了各式的安全教育訓練與方法,技能的落差仍有漫長的一段路需要努力。




      本指南希望能降低企業所需之安全程式與開發人員技能間的落差。將引導您了解需要知道的所有事項,以確保軟體工程師獲得最有效的SCE並符合實際需求。








Understanding the Developer’s Perspective 了解開發人員的想法




       現今快速的開發環境中,需要快速交付並持續整合、持續交付(CI/CD),開發人員最寶貴的資源就是時間。撰寫安全的程式碼會降低開發人員的速度,這所帶來的問題可能會導致忽視安全的議題。正因如何企業必須考量與DevOps環境可以匹配的源碼檢測Source Code Analysis (SCA)方案。       在解決開發人員的安全技能落差時要注意的另一個重要因素在於開發人員的主要工作為撰寫「程式碼」;很少在應徵工作時條件為「安全程式撰寫/交付」。安全程式撰寫就慢慢演變為「如果有時間再處理(Nice to have)」,但往住時間都是不夠的;而軟體工程師在評估績效時通常是透過速度與解決的Bug數,而不是解決安全漏洞的數量。 







        綜合上述所言雖然對開發人員充滿同情,但仍需要求開發人員提交安全的程式代碼。為了實現這點,需要改變的第一件事即是開發團隊的領導者需要在開發的過程中處理/修正安全弱點。而開發人員也需了解目標為交付無Bug且預先考量妥善防範的程式碼。此時就需要落實安全程式撰寫教育訓練以達到這個目標。 




Deciphering Developer Secure Coding Education 分析開發人員安全程式撰寫教育訓練




       教育訓練常見的方式為影片、定期課程與線上課程。這些活動多半被列為待辦清單或例行公事,並非將其認定為安全程式開發的工具。因此多數此類活動在進行時,開發人員的思緒都在於其他工作的執行。也因如此參與的學員也會以較不重視的態度參與。有鑑於此,如何讓安全程式撰寫教育訓練更容易推行?可能要從課程的模式改變,或許改採用遊戲化、角色伴演的方式進行,將會是更能夠引發興趣及提升學習效率的一種方式。







Gamification  遊戲化




        遊戲化並非指的是玩遊戲,而是仿造遊戲的設計原則與元素。雖然遊戲化在教育訓練中並非是新的議題,但多數的安全程式撰寫教育訓練並未落實。當學員處在享受的環境中學習,其成效會更好。開發人員長時間都在撰寫程式碼,依據參加過課程的數千位工程師的回饋,透過程式碼的閱讀、修改會讓開發人員更能接受這樣的課程。若需在企業中落實安全程式撰寫教育訓練,請注意以下四點,以確保學員都能有效的參與學習課程。







1. Make it Interactive  一定要互動式的




       Chief Learning Officer提到:「點擊的頻率並不能代表學習內容有吸引力,有可能只是學員想快點完成」。這種情況在組織強制性的課程中非常常見,學員並不理解課程的內容,只是想提早完成,儘早回去完成繁重的工作,而不是接受重要的內容。這將導致無效的課程與測驗。為什麼需要互動式學習,課程中包含的故事與實例是吸引學員參與的重要部份。







       故事中創造了一種情境,讓學員切身參與,可提高課程吸收力與印象。此外,若課程僅需單純的點擊式互動,不易增加課程的互動性。為了提高互動性,學員需更加關注內容,提供實務學習的機會;實際執行操作相較聆聽或閱讀的效果更好。







2. Tell a Story 勾勒情境




       故事背景介紹、角色扮演可以刺激學員的反應,當現實生活中若面臨相同情況,將需如何應對?安全程式撰寫教育訓練若以條列式的問題、答案易讓學員產生例行公式的厭煩感。而情況、人物、所面臨的問題可避免這個問題。依據故事情節(攻防實例、需解決的漏洞),有助於記住所學的內容。而故事也是許多遊戲的精髓,往往是一種有趣的催化劑,與遊戲化是切不可分的。




3. Keep it Short  精簡




       近年來因3C產品的發展,人們的能夠專注在一件事上的時間越來越短(註6)。提供的資訊保持精簡是最好的方式。如同演講中的使用的PowerPoint一樣,提供簡短重要的內容,以減少過多不必要的資訊。而這正是我們課程的原則,以最有限的時間、資源,提供最重要的安全資訊與防範作法。







4. Ensure They Win  確保參與者贏




       依據Dr. Ian Robertson著明的研究「The Winner Effect」(註7)。最容易被低評的是大腦潛力。當滿足學員參與的信心,大腦會釋放些剌激因子增加腦中的多巴胺活性,讓學員可以擁有信心,積極主動的學習。







In conclusion...  總結




       我們得到的結論是,以短期、互動、有故事性對於教育訓練來說是重要的元素。不要忽視「贏」對於課程的重要性,用勝利作為課程的結束,如成功解決弱點。確認開發人員的培訓是有效的;同時也因讓人員感覺良好,會自願的去找尋解決方案,以探索新的弱點挑戰。




Contextual Learning 情境體驗




       準備精彩、遊戲化的教學對於開發人員實際使用與學習是最重要的。而課程的學習與投入工作的時間往往是衝突的,盡量以最短的時間提供開發人員對於弱點修改的印象,當實務上發生時即可想起對應的方法。我們發現,開發人員在編寫代碼時可以持續訪問我們的培訓課程,鼓勵他們在遇到安全漏洞時回來查詢弱點的資訊。最後需持續更新程式語言版本。安全程式撰寫在各語言間有些許差異,但持續更新是所有語言都需注意的。







Summing Up




       希望您在採購安全程式撰寫教育訓練前,清楚的了解課程的行式以及對於開發人員的幫助,本課程是藉由Checkmarx 研究團隊豐富的經驗,並以遊戲的方式進行讓課程不再是枯燥的例行公事。若想了解更新請嘗試CodeBashing的線上課程,學習對於開發人員的撰寫實務。經歷課程後仍對處理方式有印象且實作它們。










相關解決方案:




Checkmarx 源碼安全檢測工具




相關文章分享:




GSS資安電子報0157期【5個常見開發工程師使用Open Source會犯的錯誤】




GSS資安電子報0149期【最新網頁常見10大風險- OWASP TOP 10 2017】

PCI SSC 安全標準介紹及案例
5個常見開發工程師使用Open Source會犯的錯誤

相關文章