摘要
在本課程模組中，您探討了現代軟體開發如何依賴開放原始碼元件，並學習了實作開放原始碼軟體的策略，同時管理相關的安全、法律和營運風險。 了解這些概念使您能夠利用開源優勢，同時保護您的組織免受潛在責任的影響。
現代軟體是如何建置的
您了解到 ，現代應用程式是由元件組裝而成 ，而不是完全從頭開始建置：
- 組件組成： 現代應用程式由大約 80% 的在專案外部維護的現有元件組成，只有 20% 是原始業務邏輯程式碼。
- 開源與閉源： 開源元件提供公開可用的原始程式碼，任何人都可以檢查、修改和分發，而閉源元件僅分發二進位文件，無需原始碼存取權限。
- 包裝生態系統： 元件透過 npm、PyPI、NuGet 和 Maven Central 等套件管理器分發，這些管理器可自動執行依賴項管理。
- 元件型開發的好處： 重複使用經過驗證的組件可以加速開發，透過社群審查提高質量，透過避免授權費用來降低成本，並提供尖端創新的機會。
- 開發速度： 使用開放原始碼元件可讓團隊專注於獨特的商業價值，而不是重建通用基礎架構，從而大幅縮短上市時間。
企業對開源軟體的擔憂
您檢查了組織在採用開放原始碼元件時 面臨的重大風險 ：
安全問題：
- 已知漏洞： 每年在開源元件中發現數千個安全漏洞，需要持續監控和快速修補。
- 供應鏈攻擊： 攻擊者會破壞套件維護者帳戶、使用誤植或利用依賴性混淆來注入惡意程式碼。
- 未維護的專案： 許多開源專案缺乏主動維護，當維護者放棄專案時，漏洞就沒有修補。
品質和可靠性問題：
- 可變品質： 開源元件的範圍從專業維護的專案到測試不佳的業餘愛好程式碼。
- 重大變更： 元件並不總是優先考慮向後相容性，更新時需要更改程式碼。
- 文件差距： 文件不足會增加整合錯誤和濫用。
法律和許可問題：
- 授權合規義務： 每個開源許可證都提出了從簡單的歸屬到衍生作品的強制開源等要求。
- Copyleft 傳播：GPL 之類的強式 Copyleft 授權如果管理不當，可能會要求將您的整個應用程式的原始碼開放。
- 許可證激增： 應用程式可能依賴數百個具有數十種不同授權的套件，從而產生複雜的合規負擔。
營運問題：
- 外部基礎設施相依性： 應用程式依賴公用套件登錄，這些註冊表可能會遇到中斷或套件移除。
- 更新管理負擔： 保持相依性最新需要持續努力、測試和部署。
什麼是開源軟體
您了解了 開源軟體的基本特徵：
- 定義： 其原始程式碼公開可供檢查、修改和分發的軟體，並受開源授權的約束。
- 協同開發： 開源專案涉及全球自願參與的分散式貢獻者，開發在公共儲存庫中透明地進行。
- 廣泛採用： 超過 90% 的企業在生產中使用開源軟體，而開源技術為網際網路基礎設施、雲端平台和行動裝置提供支援。
- Microsoft的轉型： Microsoft 從將開源視為威脅轉變為全面擁抱它，開源 .NET，為 Linux 和 Kubernetes 做出貢獻，並創建 Visual Studio Code 和 TypeScript 等流行的開源工具。
- 戰略理由： 組織選擇開源是為了節省成本、靈活性和控制、透明度和安全性，透過程式碼檢查、避免供應商鎖定、社群支援以及儘早獲得創新。
開放原始碼授權基礎知識
您探索了 開放原始碼授權如何管理軟體使用：
授權目的：
- 定義權限： 許可證授予使用、修改和分發版權法禁止的軟件的權利。
- 施加義務： 許可證需要歸屬、原始程式碼揭露、許可證保存，有時還需要 Copyleft 合規性。
- 免責責任： 作者不對損害負責，軟體按「原樣」提供，不作任何保證。
開放原始碼定義準則：
- 免費重新分發： 對銷售或贈送軟體沒有限制。
- 原始碼可用性： 必須以偏好的形式包含來源以進行修改。
- 允許的衍生作品： 必須允許修改和衍生作品。
- 無歧視： 不得歧視個人、團體或事業領域。
- 技術中立： 不能要求特定的技術或介面。
授權類別：
- 寬鬆授權： 允許以最小的限制將程式碼合併到專有軟體中（MIT、Apache 2.0、BSD）。
- Copyleft 許可證： 要求衍生作品使用相同的許可證，確保軟體保持開源（GPL、AGPL）。
- 弱式 Copyleft 授權：要求對元件進行開放原始碼修改，但允許專屬使用 (LGPL、MPL)。
常見的開放原始碼授權
您檢查了流行的許可證及其主要特徵：
寬鬆授權：
- 麻省理工學院許可證： 最簡單的寬鬆授權，僅需要歸屬，最大限度地提高採用率和商業用途。
- Apache 許可證 2.0： 具有明確專利授予和防禦性終止條款的寬鬆授權，提供專利清晰度。
- BSD 許可證： 與 MIT 許可證類似，三條款 BSD 增加了用於商標保護的名稱使用限制。
強式 Copyleft 授權：
- GPL v2 和 v3： 要求衍生作品獲得 GPL 許可，並使用二進位文件分發原始碼;GPL v3 增加了專利保護和國際相容性改進。
- AGPL： 擴展 GPL v3，提供需要 SaaS 產品來源揭露的網路使用規定。
弱式 Copyleft 授權：
- LGPL： 允許從專有應用程式連結到函式庫，同時需要對函式庫本身進行修改才能開源。
- MPL 2.0：提供檔案層級的 Copyleft，僅對 MPL 授權的檔案要求原始檔揭露，而非相同應用程式中的專屬程式碼。
許可證相容性：
- 相容組合： MIT + Apache 2.0、MIT + GPL v3、Apache 2.0 + GPL v3、LGPL + GPL。
- 不相容的組合：GPL v2 + Apache 2.0，GPL + 專屬，不同 Copyleft 授權的組合。
授權影響和風險評級
您瞭解如何 評估授權風險並實作合規性：
授權風險框架：
- 低風險（綠色）： MIT、BSD、Apache 2.0 等寬鬆許可證對於任何商業用途都是安全的。
- 中等風險（黃色）： LGPL、MPL 等弱 Copyleft 許可證允許專有使用，但對修改有限制。
- 高風險（紅色）： 像 GPL、AGPL 這樣的強 Copyleft 許可證與專有軟件分發不兼容。
- 未知風險（橙色）： 自訂或不明確的許可證在使用前需要進行法律審查。
商業軟體的影響：
- 寬鬆授權： 允許專有分發只需附上原作者資訊。
- 弱授權：允許在專有應用程式中使用函式庫，但需要將修改後的函式庫開源。
- 強式 Copyleft：要求開放原始碼衍生工作，使其與專屬軟體不相容。
智慧財產權考量：
- 專有知識產權保護： 寬准许可证会保留专有程式码，互惠式許可證需要披露。
- 專利條款： Apache 2.0 和 GPL v3 包括明確的專利授權;MIT/BSD 缺乏專利清晰度。
- 營業秘密遺失： 原始碼揭露消除了商業秘密保護。
合規實施：
- 相依性清單： 維護全面的物料清單，追蹤所有開源元件和版本。
- 授權相容性驗證： 使用自動化工具來識別授權不相容。
- 歸因合規性： 產生授權彙總檔案，包含在關於對話方塊中，並在文件中維護。
- 原始碼提供： 對於 Copyleft 許可證，請提供完整的原始程式碼和建置說明。
軟體供應鏈安全：
- 漏洞掃描： 使用 Snyk、Dependabot 或 WhiteSource 等工具持續掃描相依性以尋找已知弱點。
- 供應鏈攻擊緩解： 驗證軟體包簽章，選擇信譽良好的來源，使用私人註冊庫，並鎖定相依性版本。
- 品質評估： 評估維護狀態、社群規模、文件品質和安全實務。
組織政策：
- 審批工作流程： 在採用新的相依性之前，先實作安全性、授權和品質的使用前評估。
- 批准的套件清單： 維護開發人員可以立即使用的預先審核元件的策劃清單。
- 開發者教育： 對開發人員進行授權影響、安全實踐和合規流程的培訓。
- 持續監控： 追蹤相依性更新、授權變更和弱點揭露。
重點摘要
當您在組織中實施開源軟體時，請記住以下基本原則：
策略性地擁抱開源： 開源提供了巨大的好處，包括開發速度、質量、成本節約和創新訪問。 與其因為風險而避免開放原始碼，不如實作能夠安全採用的治理程式。
了解您的依賴關係： 維護所有開源元件的全面清單，包括可轉移相依性。 您無法管理您不知道的風險，因此依賴項可見性是有效開放原始碼管理的基礎。
了解授權的影響： 不同的授權對商業軟體的影響截然不同。 像 MIT 這樣的寬鬆許可證對於專有軟體來說是安全的;像 GPL 這樣的 Copyleft 許可證需要開源衍生作品。 將許可證選擇與您的商業模式相匹配。
評估授權相容性： 驗證不同元件的授權是否可以合法合併。 不相容的授權可能會產生法律問題，需要昂貴的補救措施，包括元件更換或程式碼重寫。
實施自動化合規性： 手動授權追蹤無法擴展到具有數百個相依性的現代應用程式。 使用自動化工具進行依賴性掃描、許可證檢測和漏洞監控。
優先考慮安全性：相依性中的安全漏洞會影響您的應用程式，無論它們來自何處。 實施持續的漏洞掃描並為關鍵安全修補程式建立快速更新流程。
管理供應鏈風險： 除了已知漏洞之外，還可以透過套件驗證、來源信譽評估、私人註冊表和依賴關係固定來防範供應鏈攻擊。
平衡控制與自由： 開發人員需要自由使用現代工具和框架。 與其阻止開放原始碼採用，不如實施批准工作流程和批准的套件清單，以實現安全使用。
教育您的團隊： 開發人員對許可和安全問題的認識至關重要。 培訓計劃可幫助開發人員在組件選擇方面做出正確的決策並了解組織策略。
持續監控： 開放原始碼管理不是一次性活動。 新的漏洞不斷披露，許可證有時會發生變化，項目可能會被放棄。 持續監控可確保持續的合規性和安全性。
透過應用這些原則並實施系統的開源管理實踐，您可以使您的組織能夠利用開源軟體的巨大優勢，同時有效管理安全、法律和營運風險。