再談“開源軟體供應鏈安全”
| 作者:莊表偉
緣起
之前寫過一篇文章《 我所理解的開源軟體供應鏈安全》,當時的情況,還沒有出現一些值得探討的,堪稱緊迫的熱點事件,所以我也僅僅是泛泛而談,到最後留了一句話:「我的提議是:不再提“開源供應鏈安全”,而是提“開源生態建設”。」
在最近一段時間,接連出現了Log4j2事件,與Marak Squires刪庫事件,一時間大家都議論紛紛,我也覺得自己有責任,來更加深入的探討一下,這個方面的問題。
一、時代已經發生了變化
在B站上,有一位著名的Up主: 半佛仙人,發了一篇文章,後來還專門錄了一期影片。因為是“外行”的緣故,所以會受到很多的批評與指責。其實我覺得他說得大致上都很有道理,作為一位熱心人士,積極找程式設計師朋友交流,儘量深入理解開源,然後再發表自己看法,已經非常不錯了。
至少 半佛的一個觀點,我特別贊同:時代已經發生了變化。我們只有意識並理解這些變化,然後才談得上“如何應對”。
比爾蓋茲的一封信
1976年2月3日,著名的微軟公司的創始人,釋出了《致電腦愛好者的一封公開信》。這封信在開源社群,估計無人不知、無人不曉。關鍵在於下面這段話:“誰會從事專業的軟體開發卻分文無獲。哪有業餘愛好者會花費3個人年的精力去編寫軟體,去修正軟體,編寫使用手冊卻免費發放給別人使用?”
在很長一段時間裡,開源社群的人都視微軟是開源的敵人,而且常常喜歡拿段話出來“打臉”。現在就是有那麼多人,那麼多技術水平高超,卻不求回報的人,願意花費極其驚人的時間,去寫軟體,修bug,寫文件。甚至還有社群運營、技術佈道等等諸多工作。
“你們這些資本家們無法理解的事情,正在這個世界上發生著,而且越來越多”。
早期的駭客是一群什麼人?
有一些事情,確實很難理解。尤其是像半佛這樣的人,無法理解那些早期駭客的動機。因為按照“理性經濟人”的假設,那些駭客完全是在做一些一味付出,不求回報的事情。
事實上,我們可以從兩個角度,來理解駭客的邏輯。
-
關於回報:如果我們擴充套件經濟人假設,將回報,不僅僅侷限於經濟上的,金錢的,直接的回報。而是按照功利主義的定義:“效用最大化”。所謂效用,包括幸福、快樂、滿足等等情感體驗。透過獲得經濟收入,當然是一種方式。但是:社會地位的提升,甚至僅僅是在社群範圍內的備受尊崇,也是一種方式。更有甚至,僅僅是創造一個從未存在過的事物,這種創造的喜悅,就足以回報那些駭客的全部投入。
-
關於未來:駭客、程式設計師,也許是最喜歡科幻小說的人群了吧。不僅僅是喜歡,而且他們甚至希望能夠促成某種未來的早日實現。如果自己寫的程式碼能夠幫助這樣的未來早日實現,如果與一群駭客一起努力,能夠推動這樣的世界早日降臨,幾乎每一個駭客都會願意傾盡全力。
所以,簡單的總結就是:早期駭客們,在努力推動未來早日實現的過程中,已經獲得了他們希望得到的回報。
供求雙方,從合一到分離
我們可以引用一段自由軟體的定義:“自由軟體”尊重使用者的自由,並且尊重整個社群。粗略來講,一個軟體如果是自由軟體,這意味著使用者可以自由地執行,複製,分發,學習,修改並改進該軟體。
後來在社群裡有一些不同的聲音,在質疑這樣的定義。為什麼只談使用者的自由,卻不談“作者”的自由?為了使用者可以自由的執行,複製,分發,學習,修改並改進,就可以不管作者的利益了嗎?作者為啥不能自由的定義自己的授權協議?想授予就授予?想收回就收回?
其實,根源還是在於時代不同了。在自由軟體,甚至開源軟體剛剛誕生的時候。軟體的供求雙方,是一個緊密的整體。社群裡的人,既是一些軟體的開發者,也是另一個軟體的使用者。所謂“尊重整個社群”就是這個意思。尊重整個社群的自由,就是為了整個社群的利益。
在早期:開源與網際網路幾乎就是一對雙生子,他們一起成長,互相扶持。風借火勢,火借風威。但是,漸漸的,開源社群與軟體產業、網際網路產業,以及由網際網路產業成長起來的雲端計算行業,不再是一體的了。在這個過程中,供應方發生了變化,需求方也發生了變化。要想再愉快的一起玩耍,就需要從新思考各自的定位了。
所以,下面我將從分離之後的供求雙方,來分析這個問題。
二、從“禮物文化”到“注意力兌換”
在Eric Raymond的《大教堂與集市》中,有一個最經典的比喻,就是禮物文化。我們引用其中的兩段:
在禮物文化下,其成員透過送出禮物而競爭社會地位。
禮物文化並不是對物質稀缺的適應,而是對物質充裕的適應。充裕性會使命令關係難以維持,會使交換關係變成無意義的遊戲。在禮物文化中,社會地位並不取決於你控制了什麼,而是你給予了什麼。
禮物的價值,是由禮物本身決定的?
我們來分析一下禮物這個比喻的內涵。一個人送出了一個禮物。人們根據這個禮物的貴重程度,而“賦予”這個送禮者,相應的社會地位。
這意味著三個並未明確講述的要素:
-
禮物的價值是客觀存在的嗎?是可以被客觀、準確、以公認的方式判定的嗎?
-
人們,注意這裡的人們,到底是一百個人,還是一萬個人?這些人的數量應該會有多少,他們如何達成共識?
-
所謂社會地位,到底是什麼?尊重,禮讓,還是某種“注目禮”?
開源軟體的價值,現在是由“價值+關注度”決定的
假設我們還是沿用“禮物”這個思路,來看現在的開源軟體,我們需要如何來衡量一個人做出了多大的貢獻?或者說“送出了多貴重的禮物?”
先區分兩種情況,一個人獨立開發出一款開源軟體,作為一個禮物。一個人參與一個開源專案,在其中貢獻了一部分“程式碼、文件、討論、佈道等等”
-
首先應該是軟體價值本身,一個加密軟體,應該比一個加法軟體,更有價值。
-
其次是這個軟體究竟對多少人有價值?一個只對一百個人有用的軟體,肯定不如對一百萬人有用的軟體,那麼有價值。
-
然後就是爭奪關注度的情況了,一款對一百萬人有用的軟體,現在只有一百個人知道,這個軟體的價值說到底也不大。
現在來計算禮物的價值:一個人,做了一個開源軟體,有多少人知道這個軟體,而且知道是他做的,而且認可他的工作。這個數量,大概可以用來推算他所貢獻的禮物的價值。
如何將注意力兌換成其他事物?
自從網際網路流行以後,尤其是網際網路上免費的商業模式流行起來以後,大家都會談一個詞,叫做“流量變現”。其實在開源軟體領域,簡單的“禮物文化”,也需要升級為“注意力兌換”。
以前的邏輯是:一個人貢獻禮物 –> 獲得社會地位
現在的邏輯是:一個人貢獻禮物 –> 吸引了多少注意力 –> 這些注意力能夠兌換多少社會地位
當然,我們也可以將兌換這個詞,用來描述更多的現象。
-
兌換內心滿足(有人用,我就很開心)
-
兌換社會地位(更高的社會評價)
-
兌換就業機會(跳槽到大廠)
-
兌換風險投資(有投資人看中這個開源軟體)
-
兌換維護合同(有企業級使用者使用,願意找你維護)
但是,所有的這些,還需要一個前提:注意力。如果沒有足夠高的關注度,你啥也兌換不了。
事實上,早期開源那種“愛用就用,別來煩我”的態度,當然沒有問題。但是:那樣不夠“友好”,也就會影響關注度的快速提升。無論是在社群快速響應,和藹可親的回答問題,快速修復bug,其實都是一種吸引更多注意力,留住更多關注度的辦法。
雖然這麼說有些殘忍,但是我還是想說:“Marak Squires的做法錯了,一款開源軟體有幾千萬次下載,並不能夠自動兌換成社會地位,個人收入或者其他東西”。
三、供應鏈、責任鏈與利益鏈
下面再來說說需求方的問題。現在我們常常說:軟體吞噬世界,開源吞噬軟體。但是,我們為啥還會接著說:雲端計算吞噬開源呢?
-
軟體吞噬世界:全世界都執行在軟體之上
-
開源吞噬軟體:幾乎所有的軟體,都有開源的成分,甚至完全就是開源
-
雲端計算吞噬開源:雲端計算靠開源賺到了錢,但是並沒有分給開源
當然,這裡面的每一句話,可能都有些問題。
由開源軟體的依賴關係,自然形成的供應鏈
在上一篇文章中,我寫了這麼一段話:“我們在做軟體開發時,通常會定義的一個依賴檔案。一款軟體,會依賴一組其他軟體(包),而這些軟體(包)又會進一步的依賴某些其他的軟體(包)。但是,隨著包依賴描述的不斷改進,我們會區分:開發期(Dev)依賴與執行期(Running)依賴。”
在那段話裡,我只是希望說明“依賴不等於風險”,由軟體依賴關係形成的整個網路,可以稱之為:“開源供應鏈”或者“開源生態”,卻不能簡單的等同於供應鏈風險。
但是,我並沒有進一步分析:開源軟體的供應鏈與一般的供應鏈,有何區別?以下一段文字,要特別感謝李大維老師,因為與他的交談,讓我認識到這一點。
傳統的供應鏈,是一級與一級之間,都簽了合同的。
但是在軟體,尤其是開源軟體的供應鏈,每一級之間,都有免責條款。
免責條款
事實上,有兩種免責條款。一種是大多數開源軟體的授權協議裡寫的。比如在GPL 2.0裡。
·由於本程式是免費提供的,所以在法律許可範圍內,本程式是沒有擔保的。除非有書面說明。本程式是“AS IS”的,沒有任何明示或暗示的保證,比如預設的適銷性、適用性這些保證都沒有,關於本程式的功能和效能導致的風險都由使用者自己承擔,(你單位用我作品出了事,你可別想拉我當墊背的,大公司都不背這鍋,你讓我一個不掙你錢的背?)如果我這作品真有缺陷,你自己想辦法搞定,你可以花錢買服務,這種公司又不是沒有。
摘錄自衛Sir的《 人話版GPL 2.0協議》
再比如在MIT裡:
本軟體是“按原樣“提供的,不附帶任何明示或暗示的保證,包括沒有任何有關適銷性、適用性、非侵權性保證以及其他保證。在任何情況下,作者或版權持有人,對任何權益追索、損害賠償以及其他追責,都不負任何責任。無論這些追責產生自合同、侵權,還是直接或間接來自於本軟體以及與本軟體使用或經營有關的情形。
摘錄自衛Sir的《 開源程式設計師絕望毀庫跑路的背後》
另一種是網際網路服務的免責條款、雲端計算服務的免責條款、商用軟體的免責條款。
這裡就不再摘錄了,因為那種法律文字,往往都很長很長,在你使用之前,你幾乎是不會去讀完的。但是:你肯定已經點過“確定”或者“接受”按鈕了。
利益斷裂
一方面是供應鏈的延續性,另一方面是責任的斷裂(免除)。於是,我們就會發現一個實際存在的現象:因為責任鏈條斷裂,所以利益鏈條也斷裂了。
因為事實上軟體出現問題之後,廠商可能損失的金額並不太高,所以在平時廠商也沒有任何動力,投入足夠的人力與預算,去確保他所用到的開源軟體的供應鏈安全。
前兩天聽到的一個課程,在介紹影響全球網際網路產業的美國《通訊規範法》230條款。網際網路公司被免除了涉及使用者生成內容的法律責任。一方面這些內容的存在不會損害網際網路廠商的利益,另一方面,網際網路廠商又可以出於“出於良善的信念”自行刪除或管理這些內容。
這當然大大降低了網際網路廠商的法律風險與投入成本。再加上他們所用到的開源軟體,又是無需支付費用的。這才帶來了網際網路產業的高速發展與如今的繁榮。
冰山現象
與此同時,我們還在開源社群裡,積極的宣傳禮物文化。“充裕性會使命令關係難以維持,會使交換關係變成無意義的遊戲。”
結果就變成了:開源世界的冰火兩重天
-
一座冰山是“開源專案”,海面之上看得到的開源專案,只是開源世界裡的極小部分
-
海面之下的開源專案,不僅重要,而且是海面上的開源專案,存在的基礎
-
但是,海面之下的開源專案,幾乎沒有商業價值,也沒有投資前景
-
另一種冰山是“開源貢獻者”,海面之上的開源開發者,只是開源社群裡的一小部分人
-
他們的確做出了極大的貢獻,也因此享受到了“禮物文化”
-
海面之下的開發者,他們的貢獻甚至被忽略了,社群的尊崇地位,幾乎與他們無關
四、生態責任
當我們來談開源軟體的供應鏈風險,或者開源生態的問題時,首先需要達成一個共識:現在的開源生態,的確存在問題,而且是一個亟待解決的,嚴重的問題。
基於這一共識,我們才能夠來討論,在這個生態之中,有哪些角色,各自有什麼責任?
開源開發者的責任
大家應該都能承認,開源是一種軟體開發的 協作方式。對於某些人來說,開源甚至是一種 娛樂方式。當然,如果有公司願意僱傭你寫開原始碼,開源也是一種很不錯的 工作方式。但是,如果你希望將開源作為自己的 生活方式,要麼你家裡有礦,要麼你非常擅長兌換注意力。否則,難免會傷心失望。
雖然我們都認為,開源是一種純個人的行為,但是單純的發洩不滿。最多引發同情,卻未必會得到支援,更是難以獲取自己真正想要的結果。
作為一個理性行動者,知道自己想要什麼,也知道自己將要付出什麼,才是一種負責人的做法。
開源使用者的責任
“只要足夠多的眼球關注,就可讓所有軟體缺陷浮現。”,或者說“只要有足夠的測試員及共同開發者,所有軟體缺陷都會在很短時間內被發現,而且能夠很容易被解決。”這句話被稱之為Linus定律。現在我想要告訴這些開源軟體的使用者,現在的開源軟體已經越來越多了,眼球已經根本不夠用了。
假設“開源軟體沒有質量問題,不會給你帶來安全風險,完全免費,拿來就可以用。”是一種完全不負責任的冒險。
開源軟體並不是“免費”的,任何使用開源軟體的企業,都需要為自己的使用負責,要留出預算,要麼找到合格的員工,要麼找到合格的服務商,來幫你應對這些風險。
開源基金會的責任
一款開源軟體,如果出現安全風險,這個開源軟體的社群,應該要快速解決。如果這款開源軟體被捐贈給某個開源基金會,那麼這個基金會也有義務,為這個開源軟體的質量負責。
為什麼?因為:你的品牌與聲望,為這款開源軟體背書,使得更多的廠商選擇了它。那麼:如果它內含風險,你的品牌與聲望,就放大了這些風險。
作為一個基金會,你收到的捐款,應該更多的投入到保障軟體質量的工作中去!
開源佈道師的責任
不要只是介紹“禮物文化”,不要反覆的強調“Just for Fun”。不要僅僅宣傳Linus眼球定律。在佈道的時候,還需要介紹更多的真實世界的情況。
政府的責任
2022年1月13日,白宮就Log4j漏洞與公私實體召開了開源軟體安全峰會。其中一名高階官員表示:“開源軟體雖然加速了創新並推動了巨大的社會和經濟效益,但其廣泛使用且由志願者維護的事實是重大的國家安全風險,正如我們正在經歷的 Log4j 漏洞事件。它並非新問題。本次峰會我們將討論如何解決這個問題,生效的解決方案是什麼以及我們還能採取哪些行動來保護我們都在依賴的開源軟體安全。”
引用自《 白宮和科技巨頭在開源軟體安全峰會上說了啥?》
在我看來,各個政府,應該都會有所行動才是。
五、結束語
這篇文章,已經太長了,引用一段我在《2021年中國開源年度報告》中的前言,作為結尾吧。
在開源還只是一個小眾群體的業餘愛好時,幾乎做任何事情,都是自由的。但是,在軟體吞噬世界、開源吞噬軟體的今天,開源技術,已經成為整個世界的基礎設施之一。能力越大,責任越大。應用越廣,風險越高。我們應該如何思考與保障開源供應鏈安全呢?應該如何建設更加健康的開源生態呢?在這樣一種生態中,各方的責任又該如何界定呢?
願與諸位共同探索。
來自 “ 開源社KAIYUANSHE ”, 原文作者:莊表偉;原文連結:https://mp.weixin.qq.com/s/NGDxaNWrYiyzP8XJddDW_A,如有侵權,請聯絡管理員刪除。
相關文章
- 軟體供應鏈安全
- 中國信通院首屆3SCON軟體供應鏈安全會議成功召開 聚焦軟體供應鏈全鏈路安全
- Kubernetes 時代的安全軟體供應鏈
- 解決軟體供應鏈安全問題
- CNCERT:2021年開源軟體供應鏈安全風險研究報告(附下載)
- 軟體供應鏈安全如何受到駭客的威脅
- NSA 和 CISA分享保護軟體供應鏈安全指南
- OpenSSF 和 Linux 基金會出席白宮峰會:開源軟體供應鏈安全議題成焦點Linux
- 網路安全行政命令:保護軟體供應鏈
- 影響軟體供應鏈安全的10大風險因素
- “開源軟體供應鏈”,可能是對開源生態的一次重要重構
- 阿里雲原生開源大家族加入中科院軟體所開源軟體供應鏈點亮計劃 - 暑期 2021阿里
- 軟體供應鏈中斷時代
- 聚合供應鏈電商系統開發軟體流程
- 數字生態系統安全演進:軟體供應鏈中的API安全API
- 解決軟體供應鏈安全問題需要關注哪些問題
- openEuler高琨:積極推動開源合規 助力供應鏈安全
- 簡析《美國白宮<利用安全的軟體開發實踐增強軟體供應鏈的安全性>備忘錄》
- 軟體供應鏈風險評估:實現安全 SDLC有哪些步驟
- RSA創新沙盒盤點 | Cycode——軟體供應鏈安全完整解決方案
- 2023年軟體供應鏈風險管理指南
- 倒數計時 | 2021 OWASP中國軟體開發與供應鏈安全技術論壇
- 2021 年軟體供應鏈狀況報告發布:開源需求增長73%,開源攻擊“暴漲” 650%
- 聚合供應鏈系統開發方案(供應商鏈)
- 京東為openKylin新增SBOM利器,保障軟體供應鏈安全和可追溯性!
- 安勢資訊加入Linux基金會OpenChain專案,助力軟體供應鏈安全LinuxAI
- 評估軟體供應鏈安全可關注這5個關鍵問題
- Sonatype:2020年軟體供應鏈狀況報告
- 談談如何構建有效的資料供應鏈
- 【供應鏈】供應鏈的底牌
- 醫療裝置製造商如何在軟體供應鏈中提高網路安全
- 火遍全球的小程式技術,軟體供應鏈安全也能幫得上忙?
- 貨源供應鏈管理系統案例
- Sonatype:2020年軟體供應鏈狀況 下一代開源網路攻擊增長430%
- 科技創新、驅動發展——2023軟體供應鏈安全創新發展論壇順利召開
- 華為雲CodeArts 12大安全防護機制,端到端全面保障軟體供應鏈安全!
- 火熱報名中|OSCS 軟體供應鏈安全技術論壇議程搶先看
- 速來領取!《軟體供應鏈安全治理與運營白皮書(2022)》正式釋出