前一陣子我談到有關Scan發表了一篇對於 OSS (開放源碼軟體)的安全性檢測報告，基本上整個方向大致上是正面的。不過這兩天另外一家應用系統與程式安全的公司 -Fortify- 發表了另一篇的報告，其內容對於OSS的安全性則有完全不一樣的見解。
這篇報告提出了三個觀察到的現象：
1. 沒有提供與資訊安全專家聯絡的方法及相關訊息 (Failure to Provide Access to Security Expertise)
2. 沒有採用考量安全性的開發流程 (Failure to Adopt a Secure Development Process)
3. 沒有善用技術找出軟體內存在的安全弱點 (Failure to Leverage Technology to Uncover Security Vulnerabilities)
另外，該篇報告也提出了兩個建議：
1. 政府與企業在導入開放源碼軟體時應該非常小心謹慎 (Government and commercial organizations that leverage open source should use open source applications with great caution)
2. 開發源碼軟體應該採用與商業軟體一樣有效的安全實務 (Open source projects should adopt robust security practices from their commercial counterparts)
雖然沒有明講，但是最後一點很明顯的指出了OSS的安全性是比不上非OSS的商業軟體。
關於OSS與非OSS之間哪一個比較安全，一直以來有各式各樣不同的論述，對此我也不打算在此討論。事實上，我認為這個問題永遠不會有解答，主要原因有下列幾點。第一個是全世界的軟體這麼多，要全部檢測是不可能的，所以採樣方法就是第一個爭論點。另外一個就是每個方法或工具檢測的項目不一樣，所以評斷的標準是第二個爭論點。另外，非OSS的商業軟體，因為沒有程式碼可以取得，所以根本就不可能做完整的程式碼檢測。最後，除了程式碼以外，有哪些也算是軟體安全的一部份？這部分同樣也是沒有標準。這麼多的不確定性，再加上兩陣營有各自的擁護者，要提出一個可讓眾人信服的結論，可說是比登天還難。
儘管如此，我們還是可以試著從中找出兩篇報告的不同之處。
1. Scan的計畫是以幫助OSS增進程式碼安全性為出發點，跟Fortify只是做檢測有很大的不同，所以參與Scan計畫的軟體大多在程式碼的安全上有很大的改善。而Fortify因為並沒有提供協助，甚至並未告知被檢測的軟體之開發團隊，自然不保證軟體在安全上的提升。
2. Scan計畫有270個(根據網站最新公布)OSS參與，而Fortify只找了11個軟體做檢測，而且都是以Java為程式語言所開發的軟體。對此，Fortify的說服力很明顯的欠缺了。
3. Scan不試著去比較OSS與非OSS之間的差異，因為這原本就不屬於該計畫的部分。而Fortify同樣也沒有提到該計畫有檢測任何非OSS的商業軟體，但是最後卻出現了一些比較的結論，同樣缺乏足夠的說服力。
4. Fortify觀察到的三點現象，雖然跟程式碼本身的安全應該有所關係，但是並沒有相關的證據顯示之間的相關性與其強度為何。所以以較嚴謹的角度來看，同樣不夠客觀。當然，沒有採用考量安全性的開發流程是一個不好的事情，但是這件事跟最後程式碼安全性的關聯並沒有辦法被證明(至少在這篇報告中是沒有辦法的)，所以不能因此推論出較不安全的結論。甚至更不能因為程式碼的安全性較差，就反推回去沒有使用考量安全性的開發流程。為什麼我說是反推回去，因為報告中並沒有看到他們與原軟體開發團隊有任何直接或間接的接觸。
事實上，這篇報告在iTWire也幾乎是一面倒的被質疑。雖然我本身也常使用OSS，但是我卻不認為OSS就一定比較安全，只不過這篇報告的說服力的確是很薄弱。不過，薄弱歸薄弱，"觀察"到的三個現象卻是我們開發或使用軟體應該注意並設法改善的地方，不管是OSS還是非OSS的商業軟體。
前一陣子有另外一篇文章同樣提到有關OSS的安全議題，不過他是談論如何避免導入OSS所可能遭遇的風險。既然OSS的使用已經是不可避免，我想這樣的忠告更具實用性，所以附上相關連結以供參考。
後記：根據各項最新的研究報告顯示，OSS相關的工作需求有明顯的成長。雖然並無法明確顯示出OSS與非OSS軟體的使用比例，但至少可以確定企業導入OSS的例子已經有大幅的增加。除了這些看得到的OSS，其實還有很多使用中的OSS是被忽視的。
原文出處:
2008年7月22日 星期二
2008年5月22日 星期四
Open Source 軟體安全再進化 - Scan開放源碼程式研究報告
Scan 這個網站於日前公布了一份為期兩年 (2006-2007) 的研究報告，這份報告是由美國國土安全局 (U.S. Department of Homeland Security) 贊助 Coverity 這家公司所進行的。這項主要針對Open Source程式碼安全性檢測的研究報告，總共有超過250個Open Source的軟體(超過5千5百萬行的程式碼)參與，並於期間不斷的重複檢測，所以總共做了14,238次檢測(超過一百億行的程式碼)，最後的檢測結果也顯示在這兩年的期間內共有8,500個錯誤已經被修正。
此份報告並不針對單一軟體的檢測結果做出報告，僅針對全面性的數據做出報告分析。因為每個軟體的程式碼行數有很大的差距，所以此研究報告的指標是採用每一千行程式的錯誤數 (static analysis defect density，以下簡稱錯誤率)作為主要憑據。此數據由兩年前的0.3降到0.25，減少了約16%。當然並不是每個軟體都有相同的改進，有些軟體甚至出現該數據上升的情形。
此研究不但希望知道Open Source軟體在安全性的表現，更希望知道這些軟體是否持續改進其安全性，也因此才會維持長時間的研究計畫，並重複對單一軟體進行檢測。為了因應評定軟體持續改進的結果，該研究把這些軟體分成不同的rungs，其中目前已經有十一個軟體達到rung 2的等級，而且這些軟體的檢測結果也被簡單的列在該網站的網頁上。這些軟體包含Amanda、NTP、OpenPAM、OpenVPN、Overdoes、Perl、PHP、Postfix、Python、Samba與TCL。
報告中並將所有檢測出的錯誤做出分類排行，發現錯誤類型的分佈極不平均。其中前兩名是Null Pointer Dereference與Resource Leak，而且比例就佔了所有檢測出的錯誤一半以上(53.68%)。
此外，此份報告的結果也顯示出Function的長度與軟體整體的錯誤率並沒有任何關聯，這與我們一般的認知並不相同。不過報告也特別提出，因為此份報告並沒有分析Function的長度與Function自身的錯誤率的關係，所以並無法完全肯定Function長度與錯誤率的真正關係。而且此研究使用之方法主要為靜態程式碼分析，還有其他錯誤需要用其他的方式才能檢測出來。另外就是較長的程式碼通常比較難加以維護，這部分也是此份報告沒有加以評估與分析的。
最後，對於大家常討論的Open Source與商業軟體程式碼安全性的比較，在這篇報告中也因為研究計劃定位與商業機密的問題，並不予以討論。
有興趣的人可以下載完整的報告進一步加以了解。
完整報告:
Coverity White Paper: Scan Open Source Report 2008
此份報告並不針對單一軟體的檢測結果做出報告，僅針對全面性的數據做出報告分析。因為每個軟體的程式碼行數有很大的差距，所以此研究報告的指標是採用每一千行程式的錯誤數 (static analysis defect density，以下簡稱錯誤率)作為主要憑據。此數據由兩年前的0.3降到0.25，減少了約16%。當然並不是每個軟體都有相同的改進，有些軟體甚至出現該數據上升的情形。
此研究不但希望知道Open Source軟體在安全性的表現，更希望知道這些軟體是否持續改進其安全性，也因此才會維持長時間的研究計畫，並重複對單一軟體進行檢測。為了因應評定軟體持續改進的結果，該研究把這些軟體分成不同的rungs，其中目前已經有十一個軟體達到rung 2的等級，而且這些軟體的檢測結果也被簡單的列在該網站的網頁上。這些軟體包含Amanda、NTP、OpenPAM、OpenVPN、Overdoes、Perl、PHP、Postfix、Python、Samba與TCL。
報告中並將所有檢測出的錯誤做出分類排行，發現錯誤類型的分佈極不平均。其中前兩名是Null Pointer Dereference與Resource Leak，而且比例就佔了所有檢測出的錯誤一半以上(53.68%)。
此外，此份報告的結果也顯示出Function的長度與軟體整體的錯誤率並沒有任何關聯，這與我們一般的認知並不相同。不過報告也特別提出，因為此份報告並沒有分析Function的長度與Function自身的錯誤率的關係，所以並無法完全肯定Function長度與錯誤率的真正關係。而且此研究使用之方法主要為靜態程式碼分析，還有其他錯誤需要用其他的方式才能檢測出來。另外就是較長的程式碼通常比較難加以維護，這部分也是此份報告沒有加以評估與分析的。
最後，對於大家常討論的Open Source與商業軟體程式碼安全性的比較，在這篇報告中也因為研究計劃定位與商業機密的問題，並不予以討論。
有興趣的人可以下載完整的報告進一步加以了解。
完整報告:
Coverity White Paper: Scan Open Source Report 2008
訂閱：
文章 (Atom)