對許多工作來說,一開始就把事情做對,往往能大幅節省掉後續許多無謂的修正和確認的工夫,對於應用程式的品質和安全性的確保也是一樣,如果在軟體開發期間就能及早發現程式臭蟲和安全性弱點,並且加以調整,之後,也就不需要浪費那麼多人力和時間去更新系統,甚至必須整個重新部署。

就原則上,我們都知道一勞永逸是有可能達到的理想,然而,在軟體開發流程要落實這些工作,卻困難重重,所幸現在我們對這樣的觀念有更深刻的體認,在程式碼編寫方式上比較願意去調整和配合。

而且,市面上也有不少輔助工具提供或整合了許多便利功能,減輕開發人員作業上的負擔。

例如,有許多整合式開發工具都內建了更聰明的偵錯機制,當開發人員在撰寫或編譯程式碼時,都能夠接收到相關的提醒,提高警覺。

有些開發平臺也內建了自動化的程式碼審查機制(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月

 

相關報導請參考「軟體品質控管亮紅燈 小疏忽可能釀成大災難」


熱門新聞

Advertisement