GitHubのオープンソース依存関係におけるコンプライアンスプレイブック

GitHubのオープンソースプログラムオフィス（Jeff率いる）は、ソフトウェアにおける最も重要なコンプライアンス業務の一つを静かに実行してきた。それは、GitHubのエコシステムを流れる数百万のオープンソース依存関係が、実際にライセンス義務を果たしていることを確認することだ。Jeffは以前、ソフトウェア構成分析会社を設立し、2004年からオープンソースコンプライアンスに携わってきた。彼は、GitHubがこれを内部でどのようにアプローチしているかを説明した。

大規模なライセンスコンプライアンス

GitHubは自動スキャナーだけに頼っているわけではない。チームはツールと手動レビューを組み合わせて、リスクの高い依存関係を処理している。パッケージレジストリからライセンスメタデータを追跡するが、デュアルライセンスのプロジェクトやリリース途中でライセンスが変更される依存関係などのエッジケースも扱う。目標は、違反が本番環境に到達する前に、その後にではなく、捕捉することだ。

サプライチェーンの整合性

ライセンス以外にも、GitHubはソフトウェアサプライチェーンの整合性に注力している。つまり、依存関係のソースが公開されたアーティファクトと一致していること、既知の脆弱性がないこと、出所が確認できることを検証する。これは、SLSAやSBOMの採用といった業界全体の動きと一致しているが、GitHubの内部プロセスはこれらの標準のほとんどに先行している。

エンジニアが気にすべきこと

オープンソースパッケージを取り込むコードを出荷しているなら（そしてほぼ間違いなくそうしている）、GitHubのアプローチは、コンプライアンスが単なる法的なチェックボックスではないことを思い出させる。それはエンジニアリングの問題だ。ライセンス違反はM&Aを妨げ、リリースを遅らせ、知的財産権の紛争に発展する可能性がある。賢明な方法は、コンプライアンスチェックをCI/CDパイプラインに組み込み、後付けとして扱わないことだ。

GitHubの内部ツールは公開されていないが、原則は明確だ。自動化できるものは自動化し、できないものは監査し、依存関係が人気があるからといって安全だと決して思い込まないこと。