鑽石舞台

cURL 作者 Daniel Stenberg 在 1 月 21 日收到了一家美國《財富》500 強企業發來的電子郵件，要求 Stenberg 回答關於 cURL 是否受到 Log4Shell 漏洞影響以及如何處理等問題。隨後，他將郵件內容截圖發到了推特上，並寫道：

這件事迅速引發了網友們的關注。

根據公開的郵件內容，這家《財富》500 強企業（暫且稱為「NNNN」）將 Daniel 團隊當成了產品供應商，並要求其 24 小時內免費提供關於 Log4j 漏洞的解決方案。下面是 NNNN 要求 Stenberg 回答的問題：

如果您在應用程序中使用了 Java 日誌庫，那么正在運行的是哪些 Log4j 版本？

貴公司是否發生過任何已確認的安全事件？

如果是，哪些應用程序、產品、服務和相關版本會受到影響？

哪些 NNNN 產品和服務受到影響？

NNNN 的非公開或個人信息是否會受到影響？

如果是，請立即向 NNNN 提供詳細信息。

什麼時候完成修復？列出每個步驟，包括每個步驟的完成日期。

cURL（client URL 請求庫的簡稱）是一個命令行接口，用於檢索可通過計算機網絡訪問資源的內容。資源由 URL 指定，並且必須是軟件支持的類型。cURL 程序實現了用戶界面，基於用 C 語言開發的 libcurl 軟件庫。

Apache Log4j 日誌庫被 Java/J2EE 應用開發項目和基於 Java/J2EE 的現成軟件解決方案的供應商大量使用。去年 12 月 9 日，Log4j 中被發現了一個漏洞，攻擊者通過該漏洞能夠進行遠程代碼執行，具體包括通過受影響的設備或應用程序訪問整個網絡、運行任何代碼、訪問受影響設備或應用程序上的所有數據、刪除或加密文件等。可以說，cURL 開源代碼與 Log4j 漏洞事件毫不相干。

雖然 Stenberg 從未參與過任何 Log4j 的開發工作，也沒有任何使用了 Log4j 代碼的版權產品，但 Stenberg 還是回復道，「你不是我們的客戶，我們也不是你的客戶。」並略帶調侃地表示，只要雙方簽了商業合同就很樂意回答所有的問題。

「這封電子郵件顯示出來的無知和無能程度令人難以置信。」Stenberg 在博文里寫道，「很奇怪他們現在才發送關於 Log4j 的查詢郵件，這似乎有點晚了。」

「這很可能只是一封發送給數十或數百個其他軟件供應商 / 開發人員的模板電子郵件。如果確實來自像我過去工作過的那些大型企業，他們很可能會要求各種 IT 支持和開發團隊編制一份企業使用的所有軟件 / 工具的列表以及每個軟件 / 工具的電子郵件地址。所以，很大可能只是有人按照項目計劃中的要求向供應商發送電子郵件以延緩問題，並勾選他們的方框，說明已聯繫該供應商 / 開發人員。」有網友猜測道。

網友「Jack0r」介紹，其所在公司規定要有一個記載依賴項的 Excel 列表，列表里大多數是開源軟件，還有一些封閉源代碼和付費產品。開發人員要為每個依賴項設置一個聯繫人，因此與某軟件相關的電子郵件可能會被放入列表中。但這個列表通常非常過時，也沒有人專門更新。

「我曾經被要求填寫一份 3 頁關於 Oracle 數據庫的詳細資料表，但我們從未使用過 Oracle。有的軟件運行在 Postgres 上，有的運行在 MySQL 上，有的運行在 NoSQL 上，但他們說，『MySQL 是從 Oracle 來的，不是嗎?』」網友現身說法。

而當出現嚴重安全漏洞時，負責 Excel 工作表的人員（非開發人員，也不知道這些依賴項如何使用，甚至不知道它們是什麼）必須聯繫每個依賴項的所有者並向他們提出相同的問題。他們這樣做不是為了做有用的事情，只是為了告訴他們的客戶「我們正在竭盡全力修復這個漏洞」。大多數情況下，這些甚至要被寫進合同中。

Reddit 上也有網友表示，Stenberg 收到的郵件來自對計算機或開源一無所知的律師助理。他只是有一長串的名字要聯繫，這樣就可以為公司建立防禦，防止因黑客攻擊而被起訴。他甚至不在乎公司是否被黑，也不在乎會不會被起訴，他只關心自己的工作，那就是做好準備，以防萬一。

因此，有人慶幸道，這就是為什麼開源許可證非常重要的原因。開源許可證保護了作者的權益，同時確保了治理到位是企業的責任。

「我認為，這可能是開源金字塔的一個很好例證，上層用戶根本不考慮底層設施的維護。只蓋房子而不關心地基。」Stenberg 寫道。

開源金字塔的最底部是基礎組件、操作系統和庫，上面所有的東西都是在此基礎上建立的。

越往上走，產品更多是面向終端用戶，企業能賺更多的錢，同時產品迭代更快、語言要求層次更高，開放源碼的份額也不斷減少。在最上面，很多東西已經不是開源的了。反之，越往下走，產品使用壽命更長，語言要求不好，但 bug 的影響更大，修復需要的時間更長，因此維護比重構更重要。在最底部，幾乎所有的東西都是開源的，每個組件都被無數的用戶所依賴。

只要有可能在不為「公共基礎設施」付出很多就能賺到很多錢，那麼企業就沒有什麼動力去投資或支付某些東西的維護費用。但足夠好的軟件組件也會偶爾出現 bug，但只要這些漏洞沒有真正威脅到賺錢的人，這種情況就不會改變。

Stenberg 認為，為依賴項的維護付費有助於降低未來在周末早上過早發出警報的風險。底層組件的開發者們的工作就是要讓依賴其組件功能的用戶相信，如果他們購買支持，就能更加放心，避免任何隱藏的陷阱。

根據 Linux 基金會和學術研究人員對 FOSS（免費和開源軟件）貢獻者進行的調查，開發者們花在安全問題上時間低於 3%，同時受訪者並不希望增加花在安全上的時間。「安全事業是一項令人沮喪的苦差事」「安全是令人難以忍受的無聊程序障礙」。有足夠的資金讓工程師將時間花在代碼維護上，或許可以降低嚴重故障的發生率。

與此同時，底層開發者與上層使用者之間的矛盾日益加深。1 月 11 日， Apache PLC4X 的創建者 Christofer Dutz 在 GitHub 發文稱，由於得不到任何形式的回報，他將停止對 PLC4X 的企業用戶提供免費的社區支持。若後續仍無企業願意站出來資助項目，他將停止對 PLC4X 的維護和任何形式的支持。

有的組件可能被成千上萬家公司用於一項很小而重要的任務，有的是與 Apache PLC4x 一樣，可能只有一個少數組織形成的自然市場。但目前沒有具體辦法來衡量使用組件給企業帶來的收益，更沒有一個通用方案可以用來收集和分配企業對開源項目的捐款。

開源可持續性問題的解決已經迫在眉睫。