CRA專題介紹

“如果萬物互聯，則萬物皆可被攻擊。”2022年9月15日，歐盟委員會的《網絡韌性法案（CRA）》提案應運而生。CRA提案引發了全球開源圈的熱議，特別是今年7月份歐盟議會對Recital 第10條“開源豁免條款”的修正意見，更是激起了多家開源基金會及社區的擔憂甚至是譴責。但直至11月30日，歐盟理事會與歐盟議會就CRA提案達成臨時議定，也未就開源界的建議予以積極反饋。在此，我們開設CRA專題，旨在從不同維度出發共同探討在全球視野下，開源軟件在現行/擬議的網絡安全立法中是否受到調整、如何界定調整邊界以及將造成何種影響等議題。

本文轉載自【衛sir說｜ID：man-mind】作者：衛劍釩 本文主要考慮兩個法律，我國的《網絡安全法》¹（以下簡稱網安法）和歐盟的《網絡韌性法案》（以下簡稱CRA，歐盟議會修正案版本²），另外，還會涉及我國的《網絡產品安全漏洞管理規定》³（以下簡稱漏洞管理規定）。 本文主要就以下幾個問題做討論： 【問題1】 在開源產生之日起就有“開源開發者免責” 還能否、或在何種程度上行得通？ 【問題2】開源項目是否要適用網絡安全相關法律？特別是發現安全漏洞是否要履行上報義務？ 【問題3】有涉歐業務的非歐盟企業發現漏洞先上報歐盟還是本國，本國不允許對外披露漏洞怎么辦？ 【問題4】開源基金會應當承擔什么樣的責任？ 此外，我在文末給出兩個具體例子，請大家思考研判。

一、開源到底要不要負責任？

了解過開源許可證的人都知道，幾乎所有的開源許可證，都明明白白說了“不負責任”。 比如最常見的MIT協議⁴，是這么說的：

本軟件系“按原樣”提供，不包含任何形式的明示或默示保證，包括但不限于適銷性、特定目的適用性及不侵權的保證。在任何情況下，無論是在合同、侵權或其他案件中，作者或版權持有人均不對因本軟件、或因本軟件的使用或其他利用而引起的、引發的或與之相關的任何權利主張、損害賠償或其他責任承擔責任。

開源項目作者是不是認為這樣，就不會有任何外部麻煩了呢？ 未必。 因為所有許可證，都得遵從法律，并不能突破法律的約束。如果有不一致的地方，以法律為準。 通常而言，開源項目的產出是軟硬件，我們看看法律對軟硬件規定了哪些安全要求。

二、法律怎么要求的？

在網安法中，最相關的是第二十二條：

第二十二條網絡產品、服務應當符合相關國家標準的強制性要求。網絡產品、服務的提供者不得設置惡意程序；發現其網絡產品、服務存在安全缺陷、漏洞等風險時，應當立即采取補救措施，按照規定及時告知用戶并向有關主管部門報告。網絡產品、服務的提供者應當為其產品、服務持續提供安全維護；在規定或者當事人約定的期限內，不得終止提供安全維護。網絡產品、服務具有收集用戶信息功能的，其提供者應當向用戶明示并取得同意；涉及用戶個人信息的，還應當遵守本法和有關法律、行政法規關于個人信息保護的規定。

在CRA中，最為概括性說明的是第1條：

本法規規定了（a） 具有數字元素的產品在市場上的銷售規則，以確保此類產品的網絡安全；（b） 具有數字元素的產品的設計、開發和生產的基本要求，以及與這些產品相關的經濟運營者在網絡安全方面的義務；（c） 具有數字元素的產品的制造商關于漏洞處理流程的基本要求，以確保產品在整個生命周期內的網絡安全，以及經濟運營者對這些流程的義務；(d) 對上述規則和要求進行市場監控、監督和執行的規則。

當然，在其后的條款中，有著更為詳細和具體的安全規定與要求。 仔細閱讀，可以看出，這些法律法規，主要是說網絡產品的制造者、提供者這些主體，應該保證產品是安全的，并且在發現漏洞后，要及時報告和處置。 那么，開源項目的產出是不是“網絡產品”，是不是“具有數字元素的產品”呢？ 尤其是，作為一種最常見的情況，那些放在GitHub上的開源項目的產出，是不是法律所關注的產品？ 這就需要細究對“產品”的定義。 然而，這并不容易。

三、令人頭疼的關于“產品”的定義

網安法并沒有給出“網絡產品”的定義。 在國家標準《信息安全技術 網絡產品和服務安全通用要求》（GB/T 39276—2020）中，對“網絡產品”有定義，定義為：

網絡產品：作為網絡組成部分以及實現網絡功能的硬件、軟件或系統，按照一定的規則和程序實現信息的收集、存儲、傳輸、交換和處理。

那么，不賣的是不是產品？我自己在家里做一個小的網絡軟件自己玩，算不算網絡產品？ 畢竟，開源項目中，絕大多數都是自己玩玩的，并沒有考慮商業化。 在《現代漢語詞典》⁵中，“產品”是“生產出來的物品”，而“生產”是指“人們使用工具來創造各種生產資料和生活資料”，從這些定義上看，他們關注的是產品這個東西的最本質屬性，并沒有關注這個東西是否用于銷售。 《牛津高階英漢雙解詞典》倒是說product通常是用來銷售的。

Product：a thing that is grown or produced, usually for sale

在大多數人的直覺感受上，法律所關心的“產品”，應該是制作出來用于銷售的那些“產品”。 我翻了翻《民法典》，也沒有找到對“產品”的定義，但在《中華人民共和國產品質量法》⁶中，發現了對“產品”的定義，它在第二條中，明確寫道：

本法所稱產品是指經過加工、制作，用于銷售的產品。

雖然我不知道《產品質量法》中對產品的定義能否用在《網安法》中，但我認為大體上可以類比，在民法典和網安法中，也確實都提到了產品的“銷售”，也都沒有提及不用于銷售的產品如何規范，所以，我個人認為，網安法中的產品，應該不是泛指所有制作出來的物品，而更多是說指商業活動中的產品。 現在看看CRA。 CRA全文都是在描述對“具有數字元素的產品”（product with digital elements）的要求，并在第3條給出了定義：

‘product with digital elements’ means any software or hardware productand its remote data processing solutions, including software or hardware components to be placed on the market separately;

翻譯：“具有數字元素的產品”是指任何軟件或硬件產品及其遠程數據處理解決方案，包括單獨投放市場的軟件或硬件組件；

一樣地，CRA對產品的定義，也是關心它的本質屬性，而沒有說是否用于銷售。 但CRA在第2條明確說明了適用范圍：

本法規適用于市場上提供的具有數字元素的產品，這些產品可以與設備或網絡直接或間接數據連接。

這里明確了一點，但還是不夠，因為“市場”未必一定是商業的，“市場”是需求和供給相遇并通過某種機制達成交換的場所，完全可以把GitHub認為是一個代碼市場，程序員和用戶在這里實現需求和供給的交換：有人需要代碼，有人提供代碼。 幸好，CRA在第3條中對“在市場上提供”也做了定義：

“在市場上提供”是指在商業活動中，無論是有償還是免費，將帶有數字元素的產品提供給聯盟市場以供分發或使用。

這樣，疑惑就完全解開了。法律中所說的“網絡產品”、“具有數字元素的產品”，我認為，都明示或暗示了這樣的條件： 所謂產品，是指用于商業活動的產品。 所以，對于那些并不參與任何商業活動，僅僅是放在GitHub或是類似的代碼托管平臺上的開源項目，法律是不管的。 但，開源項目一旦涉及商業活動，相關主體就要受到約束。 這就是開源商業化的代價。

四、哪些主體受到法律約束？

在《網安法》中，最主要的受到約束的兩個主體是“網絡運營者”和“網絡產品、服務的提供者”。 在網安法的附則中，對“網絡運營者”有定義，“是指網絡的所有者、管理者和網絡服務提供者。”網安法對“提供者”沒有定義，但這相對容易理解，提供者應該是指產品的生產者、經銷者、集成者等。 在CRA中，涉及的主體主要是“經濟運營者”，主要是指制造商、進口商、分銷商等，每個主體在CRA第3條中有定義。 這些主體的義務，正如本文前面所提到的，在法律條文中有明確而詳細的規定。 綜上，開源項目只有涉及商業活動，其相關主體才受到法律約束。 這就是對【問題1】的回答。 然而，現實要更復雜一點，什么是涉及商業活動? 舉個例子，一個開源軟件，同時提供社區版和企業版，那么其社區版是否涉及商業活動？

五、如何判別開源涉及商業活動？

網安法沒有明確提及這些，但CRA有說。 CRA不僅說了，而且把這個說得很清楚。 在其序言部分的第10條中，明確說道：

(10) 只有在商業活動過程中在市場上提供的自由和開源軟件才應受本法規管轄。自由開源產品是否作為商業活動的一部分提供，應根據每個產品進行評估，同時考慮免費開源產品的開發模式和供應階段。

(10a) 例如，在完全去中心化的開發模式中，沒有任何一個商業實體對項目代碼庫中接受的內容進行控制，這應該被視為該產品是在非商業環境中開發的。另一方面，如果自由和開源軟件是由單個組織或不對等社區開發的，并且單個組織通過對其使用（與商業有關聯）產生了收入，則應將其視為商業活動。同樣，如果自由和開源項目的主要貢獻者是商業實體雇用的開發人員，并且當這些開發人員或雇主可以控制代碼庫中接受哪些修改時，該項目通常應被視為商業性質。

(10b) 在供應階段，自由和開源軟件的商業活動可不只是對產品收費，對技術支持收費也是商業活動，除非該收費只是為了收回實際成本；自由和開源軟件的制造商提供一個軟件平臺并通過其他服務收費也是商業活動；出于除專門提高軟件的安全性、兼容性或互操作性以外其他原因而使用個人數據也是商業活動；不以營利為目的接受捐贈不應被視為商業活動，除非此類捐贈是由商業實體提供的并且具有經常性。

(10c) 單獨為自由和開源項目做出貢獻的開發人員不應承擔本法規規定的義務。

(10d) 僅僅在開放式代碼庫上提供對自由和開源軟件的托管，該行為并不構成在市場上提供具有數字元素的產品。因此，大多數軟件包管理器、代碼托管和協作平臺不應被視為本法規含義內的分銷商。

(10e) ……如果產品制造商發現組件（包括免費和開源組件）中存在漏洞，則應通知該組件的開發人員，解決并修復該漏洞，并且在適用的情況下，為開發人員提供應用的安全修復。一旦制造商將產品投放市場，就應負責確保在整個支持期內處理產品中漏洞，包括其中集成的自由和開源組件。

以上幾條，足以解決絕大多數關于開源項目是否涉及商業活動的困惑了。 比如，按照以上定義，GitHub不是市場，GitHub公司也不是分銷商，無需承擔CRA中所述的分銷商義務。再比如，谷歌提供了Andriod平臺但通過服務收費，屬于受管轄范圍；RedHat收取技術支持費，屬于受管轄范圍；XX社區版有助于XX企業版的銷售，所以XX社區版被認定為涉及商業活動。當然，這個認定，需要“根據每個產品進行評估”。 如果僅僅是對開源項目作出個人貢獻，不適用CRA。 沒有任何商業化行為的開源項目，也不受管束。 之所以這樣做，原因很簡單，也很符合常識，在序言第9a里面說，這是“為了促進自由和開源軟件的開發和應用”。如果人家又不賺錢，你還要求人家做這個做那個，是不是太過分，以至于沒人愿意再搞開源？ 所以，我相信，不管是中國的立法者還是國外的立法者，都不至于真的強人所難。 多說一句，如果你是用別人的非商業化開源軟件搞自己的商業化，別人不用負責，但你要為那個開源軟件負責任。 簡單地講，誰掙錢誰負責任。 以上就是對【問題2】的回答。

六、發現漏洞后如何報告？

這并不是個問題，因為怎么報、報給誰，法律或相關規定都有寫得很明確，沒有歧義。 比如在我國的《網絡產品安全漏洞管理規定》中，第七條說明了產品提供者的義務：

第七條 網絡產品提供者應當履行下列網絡產品安全漏洞管理義務，確保其產品安全漏洞得到及時修補和合理發布，并指導支持產品用戶采取防范措施：

（一）發現或者獲知所提供網絡產品存在安全漏洞后，應當立即采取措施并組織對安全漏洞進行驗證，評估安全漏洞的危害程度和影響范圍；對屬于其上游產品或者組件存在的安全漏洞，應當立即通知相關產品提供者。

（二）應當在2日內向工業和信息化部網絡安全威脅和漏洞信息共享平臺報送相關漏洞信息。報送內容應當包括存在網絡產品安全漏洞的產品名稱、型號、版本以及漏洞的技術特點、危害和影響范圍等。

（三）應當及時組織對網絡產品安全漏洞進行修補，對于需要產品用戶（含下游廠商）采取軟件、固件升級等措施的，應當及時將網絡產品安全漏洞風險及修補方式告知可能受影響的產品用戶，并提供必要的技術支持。……

CRA中則在第十一條的1a中說明了制造商的義務：

(a) 在制造商意識到存在被積極利用的漏洞后的 24 小時內發出早期警告，不得無故拖延，包括是否有任何已知的糾正措施或建議的風險緩解措施可用；

(b) 制造商應在意識到存在被積極利用的漏洞后 72 小時內發出漏洞通知，不得無故拖延，如果適用，應更新 (a)中的信息，包括采取的任何糾正措施或緩解措施，并指出漏洞的危害程度，包括其嚴重性和影響；

(c) 當糾正措施或緩解措施可用時，或當(b)發出后一個月內，應提交漏洞最終報告，至少應包括以下內容：

(1) 對漏洞的描述，包括其嚴重性和影響；(2) 如果有的話，給出已利用或正在利用漏洞的行為者的信息；(3) 為修復漏洞而提供的安全更新或其他糾正措施的詳細信息。

其中，所謂“被積極利用的漏洞”，是指“有可靠證據表明攻擊者在未經系統所有者許可的情況下在系統上執行了惡意代碼的漏洞”。 對于有涉歐業務的中國企業，要注意學習CRA，按照如上要求及時報告，報告對象是ENISA（歐盟網絡安全局）。 有人說，“對于有涉歐業務的中國企業，發現漏洞先上報歐盟還是我國，我國不允許對外披露漏洞怎么辦？”這看似是一個難題，實則不然，處理起來也很簡單。 第一，對于我國，要在2日內報。對于歐盟，要在24小時、72小時、一個月內報。 第二，并不沖突，漏洞管理規定只是說在第九條里說，“從事網絡產品安全漏洞發現、收集的組織或者個人”“不得將未公開的網絡產品安全漏洞信息向網絡產品提供者之外的境外組織或者個人提供。”這里的被約束主體是專門從事漏洞發現和收集的組織和個人，而非“網絡產品提供者”。在對提供者的要求中（見第七條），沒有類似的約束。 也就是說，從漏洞管理規定上看，對于未公開的漏洞，發現者可以告訴產品提供者，但未公開前不能告訴產品提供者之外的境外組織和個人；有涉歐業務的產品提供者，一旦發現漏洞，不管是否已公開，沒有說不能報告ENISA（歐盟網安局）。 因為，發現者可能遠早于制造商知道漏洞，如果告訴境外某些組織或個人，可能給敵對方帶來極大便利。而制造商知道漏洞后，必須第一時間告訴監管機構（不管境內境外），并抓緊給出修復或緩解方案，禁止制造商報告境外監管機構意義不大，除非我們不信任ENISA（比如認為ENISA會濫用漏洞信息）。 在這方面，這兩個法規并不沖突。 這是對【問題3】的回答。

七、法律對基金會的約束是什么？

對這個問題，也要一事一議，要具體看一下某基金會的性質。 我們知道，基金會旗下有很多開源項目，基金會為其提供組織、法律和資金上的支持，那么，能否認為基金會就是開源軟件的制造商或分銷商？ 對此，有人很焦慮，覺得一旦落入XX商，基金會可能無法承擔起如此沉重的安全義務。 其實，我覺得并不難，雖然CRA并沒有具體說基金會算什么性質，但在序言第10條中其實已經說明了：

如果“沒有任何一個商業實體對項目代碼庫中接受的內容進行控制，這應該被視為該產品是在非商業環境中開發的。”

“不以營利為目的接受捐贈不應被視為商業活動，除非此類捐贈是由商業實體提供的并且具有經常性。”

一個基金會的項目，是不是有商業實體在對項目進行控制，基金會是不是以營利為目的接受捐贈，若涉及具體的案子，相信不難做出調查和判斷。 比如ASF（Apache軟件基金會），其宗旨⁷之一就是： “項目獨立于任何公司或組織的影響” 如果ASF真的是這樣做的，那就顯然不在CRA管束范圍之內。 但有的基金會顯然不是這樣，這里就不點名了。 這是對【問題4】的回答。

文末思考

下面提出兩個具體問題，請讀者思考： 1、“禪道”是一款研發項目管理軟件，它有開源版和企業版，如果開源版發現了安全漏洞，禪道軟件有限公司是否要履行法律中所規定的漏洞報告和漏洞修復義務？ 2、2023年11月23日，特斯拉CEO埃隆·馬斯克在個人微博上發布消息，宣布公司旗下初代特斯拉Roadster的原始設計和工程現已完全開源。那么，如果某公司用了這些開源技術出了嚴重事故，從法律上講，馬斯克要負責任嗎?

免責聲明：

本文僅僅是從個人角度出發，對法律做的一般性研究，僅代表個人意見，請讀者審慎閱讀并自行甄別, 作者不就讀者對任何依據本文采取的任何作為或不作為承擔責任。本文不代表開放原子開源基金會觀點。

---

1. 《中華人民共和國網絡安全法》(https://baike.baidu.com/item/中華人民共和國網絡安全法/16843044?fr=ge_ala)

2. 歐盟議會的CRA修正案(2023年7月)(https://www.europarl.europa.eu/doceo/document/A-9-2023-0253_EN.html)

3. 《網絡產品安全漏洞管理規定》(https://baike.baidu.com/item/網絡產品安全漏洞管理規定/57980910?fr=ge_ala)

4. 認識開源許可證—MIT

5. 《現代漢語詞典》(第 7 版）

6. 《中華人民共和國產品質量法》(http://www.npc.gov.cn/zgrdw/npc/xinwen/2019-01/07/content_2070255.htm)

7. Apache 項目成熟度模型

點擊文末“閱讀原文”

訪問AtomGit

下載《開源態勢洞察》電子版

閱讀原文，下載閱讀和一起洞察～