源碼安全:懸在大廠頭上的達摩克利斯之劍

  • 2019 年 10 月 4 日
  • 筆記

「 Please help us!!!」

從 B 站源碼泄露開始到 GitHub 最終刪除程式碼的兩小時,大概是今年 B 站最煎熬的時刻,以至於他在向 Github 求助刪除的 DMCA 郵件中,在 Please help us 後寫下了三個醒目的感嘆號。

註:DMCA 即數字千年版權法(Digital Millennium Copyright Act),是美國制定的一項旨在保護版權的法律。它包括禁止分發受版權保護的材料和規避版權保護監管的規定。

B 站程式碼泄漏雖然不是中國第一次程式碼泄漏事件,卻是第一次因程式碼泄漏上熱搜的話題。

去年在阿里雲的程式碼託管平台上,也發生了企業程式碼泄漏事件。由於介面上的功能歧義,上百家企業在創建項目的時候誤選擇 「internal」 ,將企業項目程式碼進行了「平台公開」。同年八月份華住集團旗下酒店 5 億條公民個人資訊被曝泄露。針對此次泄漏的原因,相關科技組織分析是由於一位程式設計師(疑似華住程式設計師)曾在 GitHub 上傳了一個名為CMS 項目,項目的配置文件程式碼里包含了華住敏感的伺服器及資料庫資訊,被黑客利用攻擊導致泄露。

除了上述情況之外,一些新入門的同學還沒有意識到源程式碼屬於商業機密,將公司程式碼拷貝到個人電腦後,出於共享學習的心態傳到了公共平台;或者是離職的同學在離開公司時沒有帶走一片雲彩,卻帶走了源程式碼。總之,企業核心源程式碼被「開源」的現象屢見不鮮。

GitHub 2017~2018 年的 DMCA 刪除通知數量

不少企業都有自己的程式碼防泄漏機制,比如核心程式碼許可權控制、內外網隔離、保密協議等等措施,但程式碼泄漏的現象依然在發生。而且影響嚴重的程式碼泄漏事件不少都是由第三方發現的,等企業著手處理時已造成不少損失。接下來我們要探討的就是如何把程式碼泄漏的危害降到最低,我們列出常見的實踐,以及在主流程式碼託管平台上發現侵權的倉庫後可以怎麼做,以供讀者參考。

01 注重編程規範 對於企業來說,除了保障業務快速交付外,資訊安全也是重中之重。特別是在資訊及其敏感的行業,例如金融、公安、通訊、軍工等。不少公司都有非常嚴格的編程規範,例如:

  1. 不允許將敏感資訊硬編碼在程式碼中,敏感資訊通常包括用戶賬戶、密碼、電話號碼、資料庫密碼、伺服器遠程登錄密碼等等。如果確實需要在程式碼里的配置文件當中存儲敏感資訊,建議也不要明文存儲。
  2. 當程式碼涉及到加解密演算法時,密鑰不允許全部硬編碼在程式碼中。同時加解密演算法要選擇強度足夠的、業界認可的演算法,密鑰也要支援定期更換。

類似上述的編碼規範可通過源碼安全掃描工具對版本進行增量掃描,避免人工檢視的低效率。有一些團隊不願意花時間在這些並不直接或者並不立即產生價值的事務上,但我們建議在安全和進度之間,研發團隊需要找到一個平衡。

02

建立監控機制

越早發現泄漏程式碼,越容易控制源程式碼傳播範圍。通過定時掃描程式碼託管網站上的新增公開項目,查看是否存在可能涉及本公司項目源碼的倉庫。如何通過自動化掃描監控公開項目有如下幾種方式:

  • 現有的關鍵字掃描開源工具,市面上提供了不少工具幫助企業去實時監控公開網站上是否存在設定的關鍵字相關的,比如倉庫名稱、倉庫描述、倉庫文件名稱等等。
  • 根據程式碼託管網站的公開 API 來開發掃描工具。比如 GitHub 對公開倉庫提供的 Search 介面。
  • 通過爬蟲拉取程式碼託管網站上合法公開的資訊。由於一些現有工具存在限制或者不符合程式碼監控的需求,開發者也可考慮自行編寫數據獲取程式來進行監控,按照一定的搜索排序演算法獲取數據,每天定時識別可能涉及泄漏的關鍵記錄後發送郵件告警。

03 及時申訴 提前了解主流程式碼託管平台對於侵權程式碼的處理策略可以讓企業快速採取措施刪除侵權倉庫,把即將泛濫的 Fork 扼殺在搖籃里。

  • GitHub 的 DMCA 策略

GitHub 有兩種方式:版權所有者要求刪除內容的刪除通知程式;用戶在內容被錯誤取下時重新啟用內容的反通知程式。對於要求刪除倉庫的通知,GitHub 的處理流程:

  1. 如果通知聲明程式碼倉庫中部分內容涉嫌侵權,GitHub 會聯繫創建存儲庫的用戶,並給他們 24 小時來刪除或修改通知中指定的內容。如果倉庫擁有者由於節假日、垃圾郵箱的原因錯過通知郵件,那麼還有唯一一次額外的 24 小時來修改。
  2. 如果 DMCA 通知聲稱存儲庫的全部內容都存在侵權。那麼 GitHub 會迅速禁用整個存儲庫。就像 B 站這次的泄漏,就幾乎沒有整改時間窗直接被禁用。
  • CODING 996 貼心守護

CODING 不提供公開程式碼的功能,舊版個人版中可以通過分享鏈接的方式邀請外部人員查看程式碼倉庫,同時該外鏈不支援檢索。點擊閱讀原文即可體驗 CODING 程式碼安全保護。 若您在分享鏈接當中發現到侵權的內容時,可通過熱線聯繫我們 24 小時的運營人員([email protected]),告知侵權情況,我們會通知倉庫擁有者進行確認及整改。我們也建議個人開發者在分享程式碼倉庫前要慎重,保管好分享外鏈。

  • 在 Bitbucket 上報告版權違規行為

Atlassian 對雲產品或網站(包括 Bitbucket)上進行侵犯版權的活動也提供了對應政策。如果用戶通知網站上的數據或內容侵犯了自己的版權,按照政策當中要求的列表將侵權資訊通知給 Atlassian 版權代理人,Atlassian 會按照 DMCA 從服務中刪除涉及侵權的數據或內容。

04

嚴肅對待開源

1997 年的春天,包含 Eric Raymond,Tim O'Reilly 在內的自由軟體社團第一次提出了「Open Source(開源軟體)」這個術語。從那時起支援「開源軟體」與支援「專有商用軟體」已成為了軟體行業的兩大陣營。支援「開源軟體」的陣營以一個科研的角度對待源程式碼,他們堅信為了促進電腦科學的進一步發展,源程式碼是必須被共享和發布的科學知識。另一方則站在工業界的角度,認為企業必須對商業秘密守口如瓶。無論開源運動最終走向何方,從目前來看就算使用開源軟體也不意味著源程式碼就可以隨意共享,開發者必須嚴格按照開源軟體協議使用。

重視自己的程式碼版權,同時也尊重他人的程式碼版權。我們希望企業被「開源」的現象會越來越少,同時也希望意外的源碼泄漏不會成為企業的致命一擊。

註:

Eric Raymond,著名的程式設計師,開源軟體運動的代表人物之一。主持開發了開源軟體── Fetchmail。同時也是 NTERCAL 程式語言的主要創作者之一,曾經為 EMACS 編輯器作出貢獻。

Tim O'Reilly ,O'Reilly Media 出版公司的創始人,也是非會議的鼻祖 Foo Camp 的發起人。他是自由軟體和開源軟體運動的強力支援者,「 web 2.0 」一詞為他所首創。

參考 https://help.github.com/en/articles/dmca-takedown-policy https://www.atlassian.com/legal/copyright-and-trademark-violations https://baijiahao.baidu.com/s?id=1610052563948067365&wfr=spider&for=pc http://cloud.idcquan.com/yzx/159047.shtml 《開源軟體文集:開源革命之聲》作者: Chris DiBona / Sam Ockman / Mark Stone