不要責怪開源技術 它是無辜的
| 2013-03-20 18:14
Sonatype的首席安全官Ryan Berg在Gigaom上撰文稱,我們不應該把安全性問題歸咎於開源本身,事實上,專用軟體也會出現這樣的問題。應對安全問題真正的做法應該是注重產品生命週期內的每個環節,採取措施提高軟體開發中每個方面的安全性。
以下為文章全文:
上個月,由於受到駭客攻擊, OnRamp免費廣告服務被迫關閉,對數百萬的網站造成嚴重影響。OnRamp的母公司 OpenX在其在論壇上釋出了一份官方宣告,質疑了開源技術的安全性。
但是業內更加傾向於認為:這不是一個開源的問題,並且我們不應該把責任推給開源使用者和生產廠商。開源的經濟和生產效率使得它幾乎是任何現代軟體應用 程式的強制元件。我們在開源上都獲得了巨大的好處——發展快速,重複利用經過驗證的元件,讓使用者能在專有領域的軟體特色上集中更多的時間。
這不僅僅證明了開源的好處,更表明它是必要的。這也是為什麼超過7萬個企業在去年於Central Repository上為開源元件處理了接近80億請求,覆蓋了所有主要類別的應用程式,包括網路、雲、移動和關鍵基礎設施。
不爭的事實是今天一個典型的軟體應用程式中有超過80%的組裝是用現有的元件進行組裝的,並且其中的絕大多數都是開源的,來自數十個,或數百個單獨專案。所有的垂直行業,無論是監管和非監管,都在內部和麵向使用者的應用程式中使用大量的開源元件。
開源是必要的
你可以把今天的軟體開發組織想象成汽車製造商,開發人員使用現有的部件或零件“組裝”應用程式,而不是從頭編寫應用程式。但與製造業不同,軟體行業缺少必要的工具對一個複雜的分散式軟體供應鏈的複雜性和風險性進行管理。
基於元件的開發需要管理,當監督不完整時,安全問題就會出現。簡單地說,一個有缺陷的軟體供應鏈意味著有缺陷的應用程式。我們的研究表明,至少71%的應用程式包含元件有已知的被列為嚴重或關鍵的安全漏洞。
Digital Forensics Association 釋出的《 The Leaking Vault 2011》稱,在短短的時間裡,有超過1560億美元的直接損失可以歸因於資料洩露。由Forrester和Veracode對 應用風險管理進行的一項的商業調查發現,62%的受訪機構表示,由於他們關鍵應用中的缺陷,他們曾在過去一年裡發現漏洞。
減少不可避免的風險
現在,問題就變成了如何在降低風險與部件消耗的同時,實現開源的好處。當然,對開源軟體來說,有不斷的和複雜的威脅,專有軟體同樣存在這樣的威脅。 我們知道其中的危險來自於使用已發現漏洞的過時元件,來自於沒有一個可強制執行的開源政策,並且開源軟體沒有與管理元件執照或許可證的依賴關係。
重要的是要明白,這是一個供應鏈的問題:你需要在軟體開發生命週期(消費、發展、整合和生產的過程)內的每個階段管理元件。
降低安全風險
要降低安全風險,我們要在元件層上加強整個對軟體開發生命週期的保護措施,提高整個軟體供應鏈的完整性。想象一下,如果一個流行的開源元件中存在漏洞風險,並且由於元件被許多應用程式所使用,那麼這個元件就會成為駭客眼中的一個香饃饃。
下面是減少風險的一些關鍵:
- 研究一個開源的政策,如果你的組織還沒有的話。如果你有,則經常檢查它。確保它對開發團隊來說是明確的,並對安全管理的過程負責,讓它得到每個人的支援。
- 確保你的政策為元件安全、許可和質量屬性提供關鍵指南。除此之外,開源的策略需包羅永珍,概述組織的標準和價值觀,建立更多的指導方針來驅動使用決策。
- 確保你的政策是可強制執行的。如果沒有執行能力,那麼還有什麼意義?紙上談兵的政策將被忽略,所以要尋找方法將執行整合到軟體開發過程本身。
- 為開發人員提供所需要的資訊,以便他們做出正確的選擇。你的開發人員處於第一線,所以要給他們戰鬥能力。讓他們能夠在初期檢測到缺陷或不符合規定的地方,儘早節省時間和資金。
- 理清生產、庫存元件和它們之間的依賴關係。在進行故障排查的過程中瞭解你的應用程式的構成是成功的一半。
- 密切關注新發現的缺陷。新的漏洞可能會在任何時間出現,當一個新的漏洞出現時,你要第一時間發現,並知道哪個元件正在使用。
- 要有一個補救措施。不管發生在生命週期裡的哪個環節,都要知道如何進行解決。修復缺陷並不總是容易的,所以我們需要擁有一個計劃。
無論是使用開源軟體或專有軟體,免費軟體或付費軟體,都請記住這一點:如果我們能透過建立良好的元件方法來維護元件層,那麼對產品的整個生命週期都是有好處的。 (王旭東/編譯 仲浩/審校)
原文:http://gigaom.com/2013/03/17/dont-blame-security-breaches-on-open-source-technology-the-problem-is-lack-of-oversight/
譯文:http://www.csdn.net/article/2013-03-18/2814532-dont-blame-security-breaches-on-open-source-technology-the-problem-is-lack-of-oversight
相關文章
- 請不要再責怪你的程式設計師“太慢”程式設計師
- 不要在無盡的技術中沉淪
- 不要跟我講技術
- 學技術的同學不要盲目
- 做技術,不要太浮躁
- 無線安全及破解技術資源
- 不要成為技術的奴隸(一)
- 不要成為技術的奴隸(二)
- 專訪競技世界首席資料科學家巴川:不要辜負這個時代資料科學
- 技術卡片 - 不要使用 else
- 開源搜尋技術的核心引擎 —— Lucene
- 福布斯:iPhone落後怪蘋果對新技術保守iPhone蘋果
- OSDL建立開源基金 推動開源技術的深入發展(轉)
- IT人不要一直做技術
- 不要一輩子靠技術生存
- 與技術無關,但卻值得碼農們好好讀一讀的怪書:禪與摩托車維修藝術
- 監控,開源,cache的一些技術
- 背後支援著 Instagram 的開源技術
- 不要盲目使用新技術,說的就是你,JWT!JWT
- 產品不要被技術綁架的10件事
- 開源書和開源技術-PDF中蛋疼的中文字型
- 開源大資料技術線上Meetup大資料
- 當金融行業遇上開源技術行業
- 如糖APP——招技術負責人APP
- 不要過分迷信開源ERP
- 中小團隊的技術負責人如何做好技術團隊建設
- 別責怪框架:我使用 AngularJS 和 ReactJS 的經驗框架AngularJSReact
- 7 個有助於 AI 技術的最佳開源工具AI開源工具
- 不要讓你的開源專案「裸奔」,一文了解開源證書
- 騰訊圍棋AI技術PhoenixGo正式開源AIGo
- 開源資料庫大會技術分享資料庫
- PHP有償開源技術林-流程引擎PHP
- IOS技術分享| anyLive 開源專案iOS
- 技術團隊為什麼要開源?
- 全球75%網站採用開源技術網站
- Ruby on Rails:開源技術將深入企業AI
- J2EE開發常用開源框架技術框架
- 不懂技術的人不要對懂技術的人說這很容易實現