每天，GitHub 的工程師都會將新的相依性引入 GitHub 平台、內部應用程式以及開放原始碼專案。GitHub 不只是開放原始碼的家園，更是開放原始碼所驅動！而負責任地使用開放原始碼的重要一環，就是尊重管理您所依賴專案的授權。

在 GitHub，我們致力於履行對開放原始碼社群以及我們所使用相依性的義務。以下是我們的開放原始碼計畫辦公室（OSPO）如何運用新的 GitHub License Compliance 功能，來管理數千個相依性。

管理開放原始碼授權合規流程

幾乎所有軟體都會附帶某種授權協議。授權允許您使用專案，但前提是您必須遵守其義務。這些義務可能簡單到只要在文件裡給予原作者署名，也可能要求您在發行程式時一併散布所有原始碼。在某些情況下，授權也可能限制特定活動或使用類別。

您的組織很可能根據商業模式、軟體生態系統以及發行策略，制定了自己可接受的授權政策。例如，假設您的組織銷售的是商業、閉源的二進位應用程式，您可能會想避免使用那些會要求您開放自家專有程式碼的相依性。

或者，您可能有一個計畫以開放原始碼套件形式發行的專案。此時，您可能會想避免納入受商業授權或不相容開放原始碼授權管理的相依性。

如果無法遵守上述任一情境所需的義務，您就應該避免使用該相依性，以免產生法律或營運風險。事後移除這些授權可能需要額外的工程心力。對企業軟體而言，不合規的商業風險極高，因為可能導致昂貴的訴訟與聲譽損害。

傳統上，授權審查是由人工或第三方軟體執行。但現在，GitHub 已為 GitHub Advanced Security 客戶推出授權合規功能，讓您能直接在拉取請求上審查新的相依性。此審查有助於確保這些相依性的授權符合您的政策，同時也讓您有彈性擴充政策，以允許新的授權或個別專案。

兩個月前，GitHub 的 OSPO 已從我們原本用來管理合規的內部工具，遷移至新功能。身為早期採用者，我們向開發團隊提供了快速回饋，並協助確保此功能能達到大型、快速變動且具複雜合規需求企業的水準。

設定政策以取得成功

由於 GitHub 在產品推出前已建置內部授權合規工具，我們已有可接受的授權清單，可作為初始政策。您可能會發現許多相依性使用常見的寬鬆授權，例如 MIT、Apache 2.0 與 BSD-3-Clause，這些是建立政策的好起始清單。我們最初以組織層級的規則集，使用「Evaluate」模式推出此功能，該模式會在拉取請求中產生註解，但不會阻擋合併，讓我們能在不影響開發人員生產力的情況下，讓大家熟悉新工作流程。同時執行舊工具與新工具，也讓我們能查看兩者行為是否有差異。在這種模式運作約一個月後，我們發現警示主要出現在使用不常見、遺漏或明確不允許授權的套件上。

企業授權政策畫面顯示 SPDX 授權的已分頁清單，並可透過手動輸入或選取對話方塊新增更多授權。

GitHub 授權合規功能運作方式

在背後，授權合規檢查是透過規則集啟用。我們會透過自訂屬性鎖定存放庫，該屬性的值決定授權檢查是在「Active」還是「Evaluate」模式下啟用。在被規則集鎖定的存放庫中，修改專案相依性的拉取請求會觸發掃描，查詢每個新相依性所使用的授權。如果新相依性的授權已獲允許，或有特定套件的例外，則檢查會通過。若有失敗（無論是直接相依性還是傳遞相依性），工具會在拉取請求上留言，針對每個有問題的套件發出警示。

授權警示頁面，顯示套件名稱、不合規的授權識別碼，以及開發者與核准者之間的溝通時間軸。

開發者接著會審查這些警示。如果他們認為該相依性不可接受，可以更新程式碼或關閉拉取請求以移除它。如果他們認為應該允許該授權或套件，可以提出例外請求，通知組織內的特定團隊，由該團隊決定是否以及如何修改政策。

授權政策團隊的一天

GitHub 的授權政策團隊由 OSPO 成員以及具備授權審查與供應鏈分析專業知識的工程師組成。由於我們是一家全球性公司，政策審查團隊的成員橫跨不同時區，能及時審查警示。我們正在制定審查授權請求的 SLA，但在實務上，通常只需不到幾小時就能對新請求進行分類。

團隊成員會收到新審查請求的電子郵件通知，也能存取儀表板查看待處理請求的待辦清單。

發送給授權審查團隊的電子郵件通知，包含提出警示的使用者名稱、產生警示的存放庫，以及開發者要求允許該套件（因其為私人內部套件）的留言。

在核准請求時，我們有兩個決策點：首先，決定是否允許該授權或套件；接著，決定使用企業層級還是存放庫層級的範圍。如果是安全的授權，只是之前未出現過，我們會在企業層級新增，允許 GitHub 各處使用該授權的相依性。有些套件附帶商業授權，無法在各處允許，但應允許在已支付該軟體費用的團隊所擁有的存放庫中使用，因此這些政策修訂會在存放庫層級新增。套件例外適用於通常沒有授權資料的內部軟體。值得一提的是，此工具支援套件例外的萬用字元比對。例如，我們已允許 @github-ui/* React 命名空間中的所有套件，因此不需要逐一核准這些套件。

讓開發人員更輕鬆

為了支援此流程，我們已建立關於聯絡 GitHub OSPO 以及使用緊急「break glass」覆寫的程序。這些情況應該很少發生，但清晰的緊急覆寫程序對時間敏感度極高的拉取請求至關重要。如上所述，授權政策執行是透過規則集進行，而規則集的條件取決於自訂屬性。因此，切換屬性值可以暫時關閉執行，以因應被授權警示阻擋的關鍵修正。到目前為止，我們只使用過一次，但擁有這個選項非常有幫助。

我們也提供內部文件與訓練，幫助開發人員了解授權合規的重要性。最終，每個人都需要協助確保合規並管理風險，而我們的職責是讓這件事盡可能簡單。

總結

授權合規是管理軟體供應鏈的重要一環。透過幫助開發人員做出符合 GitHub 授權政策的明智相依性選擇，我們可以避免昂貴的重寫與潛在法律問題。我們已熱心地使用新 GitHub License Compliance 功能數個月，並提供回饋。現在此功能已進入公開預覽階段，我們很高興看到更多公司採用它，並希望我們的經驗能為剛開始的使用者提供一些指引。

GitHub Enterprise Cloud 客戶可在擁有有效 GHAS Code Security 授權的存放庫中使用 License Compliance 功能。更多資訊，請參閱 關於開放原始碼授權合規。