《新思科技(Synopsys):2021開源安全和風險分析報告(27頁).pdf》由會員分享,可在線閱讀,更多相關《新思科技(Synopsys):2021開源安全和風險分析報告(27頁).pdf(27頁珍藏版)》請在三個皮匠報告上搜索。
1、開源的可持續性在Black.Duck審計服務團隊2020年審計的1,500多個代碼庫中,居然有91%使用了在過去兩年中沒有發生任何開發活動的開源依賴項,這意味著91%的被審代碼庫中包含在過去兩年中沒有進行過功能升級、代碼優化和任何安全問題修復的依賴項。開源受歡迎的原因之一是志愿者社區不斷更新代碼并解決修復漏洞問題。軟件開發者兼寫作者Eric.Raymond將其稱為行之有效的“林納斯定律”:當許多人一起研究代碼時,所有的bug都將浮出水面。普渡大學的一項研究表明,林納斯定律對此確實行之有效4.通常來說,開源社區發布補丁的速度確實領先于專有軟件提供商。但是,沒有人能夠保證任何開源項目背后的志愿者社
2、區都會無限期地維護代碼,也不能保證該社區一直擁有熟悉相關項目代碼的成員。Black.Duck審計服務團隊2020年審計的代碼庫中,85%的代碼庫含有至少四年未曾更新的開源依賴項。也就是說,代碼庫使用的開源庫并非最新版本,甚至經常是很舊的版本。如前所述,開發團隊顯然難以維護開源依賴項的時新性?;氐健扒笆舐┒础币还澲刑岬降膌odash漏洞,盡管自2019年七月以來已經針對該漏洞的代碼庫進行了升級,但在2020和2019年的審計中,仍有29%的代碼庫包含CVE-2019-10744。是否開發人員認為漏洞風險很低,所以可以推遲更新?他們是否認為“只要功能都還正常,為何要修復它呢”?他們是否知道應用程
3、序調用的依賴項是哪個版本?他們可能認為將依賴項更新推遲半年到一年是合理的,但是,對于85%的被審代碼庫中包含至少四年未曾更新的開源庫,我們該怎么做呢?得帕克原則“能力越大、責任越大?!?出處不明,通常認為出自Stan.Lee作為參與變革的一員,感覺如何?正如2021年OSSRA報告所示,如今已經很難找到不依賴于開源強大功能的應用程序了。不僅開源代碼的使用越來越普遍,而且參與編寫開源代碼的開發者也越來越多。Linux基金會贊助的".2020年FOSS貢獻者報告”指出,近一半的受訪者對開源項目的參與是由其所在單位提供資助的。6.CyRC調查“2020年DevSecOps實踐與開源管理”.
4、(DevSecOps. Practices.and.Open.Source.Management.in.2020)顯示,從事軟件開發業務的大多數組織.(65%)都制定了允許開發人員為開源項目做貢獻的政策。如本報告所述,開源的普及也帶來了風險的增長,特別是開源安全性、代碼質量和可持續性方面的風險。部分原因是開源代碼使用增加導致管理動態、變化的風險格局變得更加困難。為應對這一挑戰,開發團隊需要可靠的、及時的漏洞信息,軟件所用開源代碼依賴項的完整清單,漏洞嚴重性和可利用性的準確指導,以及有關如何修補受影響開源代碼的明確指導。無心之失還是惡意為之誠然媒體喜歡報道惡意攻擊,但無心之失的編碼錯誤所引入的缺
5、陷同樣具有破壞性,并且更有可能影響到開源項目。據“2020年Octoverse狀態”.(2020.State.of.the. Octoverse)報告顯示,2019到2020年間,GitHub發出警報的漏洞中有83%源于編碼錯誤而非惡意為之。7如果大多數攻擊都是利用了代碼中無心之失引入的漏洞,那么,防范這些漏洞就變得尤為重要。對開發人員進行軟件安全培訓便是防范措施之一。例如,edX上免費提供OpenSSF課程,許多軟件安全公司如Synopsys提供應用安全在線課程。鼓勵開發者在代碼提交之前使用靜態分析等檢測工具,這是減少開源代碼錯誤的另外一種方法。靜態分析根據一組編碼規則檢查源代碼,從而發現常見的編碼錯誤。Synopsys為在注冊項目的開源開發者提供免費的靜態分析服務。Coverity.Scan與Synopsys的商用靜態分析工具Coverity使用相同引擎,幫助開發者識別代碼缺陷,從而快速輕便地進行修復。Linux基金會調查的受訪者“一致表示Coverity.Scan和clang.security.Checker”是其主要使用的靜態分析工具。8下一頁詳細介紹了有關Coverity.Scan如何幫助確保NGINX開源代碼質量和安全的案例研究。