對許多工作來說，一開始就把事情做對，往往能大幅節省掉後續許多無謂的修正和確認的工夫，對於應用程式的品質和安全性的確保也是一樣，如果在軟體開發期間就能及早發現程式臭蟲和安全性弱點，並且加以調整，之後，也就不需要浪費那麼多人力和時間去更新系統，甚至必須整個重新部署。
就原則上，我們都知道一勞永逸是有可能達到的理想，然而，在軟體開發流程要落實這些工作，卻困難重重，所幸現在我們對這樣的觀念有更深刻的體認，在程式碼編寫方式上比較願意去調整和配合。
而且，市面上也有不少輔助工具提供或整合了許多便利功能，減輕開發人員作業上的負擔。
例如，有許多整合式開發工具都內建了更聰明的偵錯機制，當開發人員在撰寫或編譯程式碼時，都能夠接收到相關的提醒，提高警覺。
有些開發平臺也內建了自動化的程式碼審查機制（Code Review），在程式碼提交到版本控制系統時，須根據管理者制定的政策來執行審查的程序，通過後，程式碼才能進到由系統集中管理的檔案庫，例如微軟Visual Studio搭配的Team Foundation Server。
若需要專門針對安全性漏洞的偵測機制，你也可以利用第三方的程式碼安全檢測分析產品，像是HP Fortify系列產品、IBM Security AppScan、Checkmarx。
不過，工具並非萬能，而且程式碼是人寫出來的、程式設計需求是人定義與理解的，為了滿足需求所實作的程式邏輯也可能變化多端，並非只是制式條列的死板文字，因此若要充分驗證軟體的品質和安全性，仍需要透過相關的使用測試來驗證，例如壓力測試（Stress test）、系統整合測試（SIT）、功能驗證測試（FVT）、使用者接受度測試（UAT），以及特別用在驗證資安防護程度的滲透測試（PT）。
照理說，工具的運用與這些測試，對大型的IT或網路公司來說，應該是更有機會去落實在本身的開發流程中，不過類似蘋果iOS的SSL漏洞，後來被發現是因為少了括號，所以才出包，難道上述方法他們都沒有落實？還是這些作法對於發現這樣的漏洞沒有效果？是不是有些問題被忽略了？
Bug為何永遠抓不盡、修不完？
進入21世紀的現代，我們對於軟體的依賴度越來越高，不只是針對套裝軟體，現在連伺服器、儲存與網路等基礎架構都會應用到程式碼，而且，這幾年來，像是軟體定義式資料中心（SDDC）、軟體定義式網路（SDN）、軟體定義式儲存（SDS）這樣的應用方興未艾，未來透過軟體控制各種系統與服務的程度會更深。
不過，隨著IT技術的發展腳步加快，除了新建置或升級既有應用系統之外，其實，我們在日常維運工作中，往往也花不少時間在處理系統的安全性漏洞，然後時間已經來到了2014年，IT人員仍然在不斷因應這些問題，有許多原因，其中一個因素，是跟軟體開發專案的人力配置與素質有關。
通常比較有開發經驗的人所寫出來的程式，Bug少，錯誤率低。但實務上，很多開發專案經常處於趕工狀態，而因此會需要更多人手來協助，然而，有時為了節省成本等考量，會找新手來幫忙，而這些程式人很可能對資訊安全、系統平臺運作的相關經驗不足，所以寫出來的程式碼品質良莠不齊，所產生的程式碼問題，也和有經驗的開發者大不相同。
另一個因素是軟體推出的時程緊迫，為了搶產品上市、系統上線的時機，公司高階主管會不斷催促軟體要趕快推出、上線，很多產品經理、專案經理在時程有限的壓力下，被迫趕鴨子上架，但同時又面臨到上述人力成本的限制，所以就算額外增加人手，可能也無法找到開發經驗夠豐富的人員來協助開發，或者因為沒有足夠時間去訓練這些新手，於是同樣又因此產生一些熟手不會犯的錯誤。
不過，即使團隊中沒有新手，主要負責開發的都是資深人員，靠少數幾位足以吃下相關的工作負擔，但因為專案時間抓得很緊、工作過勞的關係，他就算知道程式中仍有臭蟲未解，只好暫時忽略，先把功能面的部份做完，行有餘力，再去處理資安的問題。
本身有16年軟體開發經驗，目前在HP軟體事業群資訊安全處擔任Fortify技術經理的林榮秋，他觀察到目前軟體開發人員經常面臨到這樣的狀況，而且即使是有能力購買、導入Fortify程式碼安全檢測工具的用戶，他們雖然透過這套系統掃描到程式碼有不少安全性問題、弱點，但因為老闆要求上線的時間在即，所以明知有問題，還是冒險讓程式上線了，之後再設法在沒出事前，趕緊修改，只是心中有個賭注式的期待，希望這段期間駭客不要來攻打他們的程式。
然而，開發時程緊迫已經是大勢所趨，因為現在大家都希望做到快速發行、程式釋出新版的間隔變得更短，林榮秋說，現在的開發時間又更為壓縮，尤其像手機App，開發時間更少，可能每半個月就要發出一個修正版，若允許長一點的開發時程，也可能頂多只有一個月。
對於層出不窮的程式臭蟲，有17年軟體開發經驗的達友科技副總經理暨技術總監林皇興，因為需針對所代理的產品，例如Websense的網頁安全與資料外洩防護系統，為用戶提供客製功能服務，因此對軟體有漏洞的狀況也有一些體認。
他說，這也是軟體的藝術，只要是藝術，就不會有100%的狀況──沒有絕對的對或錯，隨著時間演進，總會有新的發現。但程式不是滿講究邏輯的嗎？為什麼還是有個別差異？
因為，每個人所寫的程式都有自己的風格。比如說我們列了5個功能要求，要5個人去寫程式，每個人一定寫得不一樣──就算都是同一間大學、科技畢業，但每個人寫出來的程式碼風格可能不一樣，這是沒有辦法的事。所以他們以前在面試程式員、開發人員時，通常請對方提供寫過的程式碼片段，看看風格是否適合公司要求。
搭配軟體開發輔助工具，可以做到自動化偵測
想要提升軟體品質與安全性的機制，有些廠商提供的開發平臺直接就內建相關的功能，如果是第三方的程式碼安全檢測工具，有許多產品也提供了與這些主流開發平臺整合機制。
以微軟Visual Studio來說，企業若把相關的開發環境建立起來，不論人員是在內部開發，或者是把開發工作外包到給其他公司，都可以透過Team Foundation Server（TFS）內建的程式碼簽入原則（Check-in Policy），來管控開發人員所提交的程式碼，若程式碼無法符合這些資安或效能的政策，就不能簽入。
當開發者要將程式碼簽入TFS時，系統會自動執行程式碼審核的工作，比如說系統設了20條規則，只要其中有一條出問題，就沒辦法簽入，所以任何有問題的程式碼，都進不了這裡。微軟開發工具暨平台推廣處資深產品行銷經理吳典璋認為，問題在於如何在流程裡面去落實，這更重要，因為是從根本，也就是流程的層面去解決。
不過，這麼做，一開始會讓許多開發人員很不適應，因為他們會發現程式碼都沒辦法簽入到系統上，因為沒有符合規範，吳典璋說，久而久之，開發人員就會習慣這樣的政策，而將對應的作法落實在日常的開發流程中，而不是到了最後關卡才做驗證的動作。
吳典璋強調，傳統的品質確保作業（Quality Assurance，QA）只是工作流程中的一環，並不等於軟體品質，這項工作應該是在每個開發階段都要進行的。傳統的QA就是所謂的抓Bug、做測試，但是其實到了開發的末段才做驗證，已經太遲。而且，以臺灣多數的中小企業規模而言，想要擁有一個有規模的QA團隊來協助開發，並不容易。若你沒有能力去養一個QA團隊，你還是可以在開發階段做到，用上述方式幫程式碼品質把關。
如果是要運用程式碼安全檢測工具，有辦法整合在開發流程中嗎？以HP Fortify的產品來說，用戶會固定每天把他們寫好的程式碼，提交到版本控制伺服器，然後Fortify會在晚上定期去掃描程式碼（以指令的方式將程式碼簽出，再做掃描）。
林榮秋說，如果對象是手機App，因為程式本身不會很大，程式碼安全檢測系統在一個鐘頭之內就可以掃完。專案經理隔天就可以看到掃描結果的統計報表，然後，他再根據所呈現的問題狀況派工，看要誰去修改這段程式碼，
事在人為，決定修改程式碼的關鍵仍在於人
透過工具來幫忙固然是一種可行的選項，不過，實務上，還是有賴開發人員來妥善運用，才會奏效。
這些產品能夠判斷程式碼的語法錯誤，主要是檢查出問題、發出警告，幫你判斷邏輯上的錯誤，在眾至資訊任職已10年的技術總監黃俊魁提醒，就算開發工具會顯示警告，很多人不見得會逐一檢視其中的問題。
例如，當開發人員剛開始寫程式碼時，工具軟體出現警告，他們可能還會去看，等到判斷沒關係之後，就會略過這些訊息，繼續工作；當程式碼發展到很大規模的地步，此時，開發工具軟體所出現的警告可能是二十幾、三十幾個，因為訊息過多，所以很多人的反應是全部跳過不看。
遇到這樣的狀況，黃俊魁說，只能要求程式人員看到警告時，要一個個去檢查，判斷是否可以忽略，或是把這些警告的來源修正掉。
另一點是，若用第三方軟體來檢測程式碼，黃俊魁認為能否信任它們檢查的結果，會是一個問題點，因為現在開發者所用的軟體平臺，還是以官方的系統為主，如果你所用的是封閉的軟體開發平臺與程式語言，若有第三方的產品比對出來，發現程式碼是有問題時，卻跟官方軟體所檢查的結果不一樣，我們該相信哪一方？
此外，不論是軟體開發平臺或是第三方的程式碼安全檢測工具，即便都具有安全性的測試功能，但是所能偵測的項目和範圍上，可能有局限，林皇興說，有些產品所針對的安全性弱點檢查，可能會偏重在OWASP（Open Web Application Security Project）組織所列出的10大主要威脅。
有些比較嚴謹的使用單位，會要求做白箱檢測，也會要求做黑箱檢測，做完之後，還會要求以人工方式進行滲透測試，最後才能上線。不過，他也觀察到，真正能夠把這些步驟做到的企業或單位並不多，以目前現實環境而言，能夠做到其中一樣就不錯了。
若要仰賴開發流程期間的種種測試，例如模組測試、單元測試，在多數的情況下，進行測試的人本身就是開發程式的人，林皇興表示，他們所用的測試方法是否完善，其實並不容易受到監督。
對於這種狀況，黃俊魁也有同感，讓寫這段程式碼的人去做測試，往往都不會有問題，因為他知道程式邏輯怎麼寫，所以測試時，就會被這框架給限制住了。所以，他們會找一般使用者、不懂程式的人來執行這項工作，因為對方不知道寫程式碼的方式和框架預設的邏輯，而無法直覺地認定程式的功能，於是他操作的方式可能就跳脫開發人員的框架，這時候就有機會發現原來開發人員所沒有考慮到的問題。
除了透過測試，若能夠有足夠的人力來審核寫好的程式碼，為軟體品質把關，有時也是必要的。黃俊魁說，他們公司目前有一位研發的主管專門負責這項工作，但他主要是針對重點的程式碼部分去做檢核，而不是逐行審閱，一些比較細小的、偏重使用者介面的部分，可能就會略過。
程式碼安全檢測工具可偵測goto fail的問題
透過程式碼安全檢測工具Checkmarx的分析，可以找到蘋果作業系統sslKeyExchange.c中不當使用 goto的段落。但這樣的情況對Checkmarx而言，通常視為品質問題，而非資安問題，所以列在 Info區。圖片提供∕叡揚資訊
整合在微軟Visual Studio的程式碼安全檢測工具
有些程式碼安全檢測工具可以嵌在整合式開發工具上，讓開發人員在單一介面上完成安全檢測。圖中是嵌在微軟Visual Studio（VS）的Fortify Static Code Analyzer（SCA），目前最新的4.1版支援VS2010、VS2012、VS2013，此外它還可以整合在Eclipse，以及IBM Rational Application Developer和Rational Software Architect。圖片提供∕HP Fortify
換個角度理解iOS SSL/TLS程式臭蟲的成因
以這段範例程式碼來看，基本上， result 的數值應該回應 3。因為，我們定義變數 updateResultLableTextWithState :3，所以，到下面判斷執行時，應該顯示 state == 3 的結果。兩者的差別在於，左圖中的程式碼是簡寫，右圖則是加上了括號，所以執行結果大不相同。圖片提供∕眾至資訊
在不同開發階段，皆可落實軟體品質管控
要落實軟體品質的改善，並不是在程式碼完成後的測試作業時才進行，而是在每個開發階段上都應該導入的工作。資料來源：微軟，2014年7月
熱門新聞
2024-04-17
2024-04-17
2024-04-15
2024-04-18
2024-04-15
2024-04-15