GitHub がオープン ソース ソフトウェアをセキュリティ保護する方法

オープン ソース ソフトウェアのセキュリティ保護における GitHub の役割

オープン ソース ソフトウェアはいたるところにあり、チームが毎日使う言語、フレームワーク、アプリケーションを支えています。シノプシス オープン ソース リサーチ & イノベーション センターが実施した調査では、現在のエンタープライズ ソフトウェアの 90% 以上がオープン ソース コードで構成されていることが明らかになり、さまざまな企業の注目を集めています。Red Hat による「エンタープライズ オープン ソースの現状 (State of Enterprise Open Source)」でも、「組織の戦略にとってオープン ソースが重要であると答えた回答者は 95% に上る」ことが確認されました。コードを広く利用可能にし、コードや複雑な依存関係の再利用が増えることにより、ソフトウェアの構築方法が変化しただけでなく、セキュリティやコンプライアンスの懸念も生じています。オープン ソース プロジェクトにも、すべのソフトウェア同様、脆弱性のある可能性があります。それどころか、オープン ソース コードを使用して脆弱性をダウンストリームのアプリケーションにも波及させ、ソフトウェア サプライ チェーンを攻撃しようとする、悪意のある攻撃者の標的になる可能性さえあるのです。こうした脅威により、組織はさらなるリスクに晒されてしまいます。

GitHub ではセキュリティをコミュニティとして取り組む必要のある問題だと考えています。プロプライエタリ コードがどれだけ含まれているかにかかわらず、セキュリティは全てのソフトウェアに影響を及ぼす問題です。同様に、安全で健全なオープン ソース コミュニティは単にオープン ソース ソフトウェアにとってよいというだけではありません。オープン ソース コミュニティを利用する何百万もの企業にもメリットをもたらします。そこで GitHub は、組織とオープン ソース メンテナーがソフトウェア開発ライフサイクル全体を通してセキュアにコーディングを行えるツールとプロセスを構築しました。セキュリティ対策を講じ、それを「シフト レフト」することにより、組織やプロジェクトはセキュリティ インシデントが発生する前にエラーや不具合を防ぐことができます。

GitHub はユーザーが安全に利用し、開発し、貢献できる GitHub のコミュニティとオープン ソース ソフトウェアのセキュリティ保護に取り組んでいます。機能、サービス、セキュリティ イニシアチブを通して、GitHub の何百万ものオープン ソース プロジェクトおよびワークフロー全体でそれらを利用する企業に、学び、活用すべきベストプラクティスを提供します。

より安全なオープン ソースへの取り組み

GitHub Advisory Database、脆弱な依存関係のアラート、Dependabot

セキュリティ問題を特定するうえで重要な要素の 1 つは、情報量の豊富な脆弱性データベースと連動することです。GitHub の依存関係脆弱性検出ツールでは、GitHub Security アドバイザリと National Vulnerability Database (NVD) から直接取得したデータを組み合わせて使用し、オープン ソースにおける脆弱性の全体像を把握します。このデータセットの組み合わせは、GitHub Advisory Database 内に存在し、Dependabot のアラートやセキュリティの更新に利用されます。また、GitHub Advisory Database は Creative Commons Attribution 4.0 ライセンスの下に提供されているため、データソースとして GitHub を明示すれば誰でも無料で利用できます。

自動修正を生成するには、まず脆弱なバージョンと修正済みのバージョンの説明を含む CVE アラートを作成します。次に、各言語の依存関係管理の定義を使用して影響を受けやすいリポジトリを特定します。これにより、リポジトリのマニフェストを解析し、脆弱な依存関係、特にこれらの問題を修正するために更新する必要のあるバージョンについて、管理者にアラートを出すことができます。2017 年にセキュリティ アラートをリリースして以来、GitHub では、オープン ソース リポジトリ内に見つかった 8,900 万件以上の脆弱性についてアラートを送信してきました。

同様の機能を提供しているサードパーティーのツールもありますが、GitHub の調査からはオープン ソース リポジトリの多くがそれらを十分に活用できていないことが明らかになっています。アラートによる脆弱性通知だけでは、問題は解決されません。GitHub のデータによると、送信された 8,900 万件の脆弱性アラートの 70% が、通知から 1 か月経っても修正されないままだったという驚くべき結果が明らかになっています。脆弱性があることがわかっていても、開発者や管理者の多くはどう解決してよいかわからず、アプリケーションをセキュリティ問題や攻撃にさらされた状態で放置しているのです。こうした状況に対処するため、GitHub では自動修正を提案しています。脆弱性が見つかったら、Dependabot を使用して自動的に既知の脆弱性を取得するプル リクエストを作成します。これによりユーザーは修正内容をすばやくマージしてコード ベースに展開できます。つまり、各セキュリティ アラートには現在、セキュリティ レベル、プロジェクトで影響を受けたファイルへのリンク、自動セキュリティ修正によるプル リクエストへのリンクが含まれます。

さらに GitHub では、オープン ソース プロジェクトのメンテナーが新しく見つかったセキュリティの脆弱性への対処と共有をより簡単にできるようにしています。メーリング リスト、オープン ソース グループ、リリース ノート、変更ログを使ってユーザーに知らせるのではなく、プロジェクトが直接 GitHub とやり取りできるようになったのです。GitHub は CVE 採番機関 (CNA) であり、CVE 識別番号の割り当てを許可されています。このため、メンテナーは対処している問題の CVE 番号をリクエストできます。また、GitHub コミュニティ内の開発者が最初にアドバイザリを確認できるように、GitHub 上に直接情報を公開できます。これによりコミュニティ全体の脆弱性に関するセキュリティ アラートを生成し、最初に GitHub で共有できるようになります。

しかし、メンテナーはセキュリティの修正を常にマークしているわけではありません。このため、毎日生成される膨大な数の GitHub のプロセスの中からコミットされた修正を見つけるには、追加のしくみが必要となります。弊社の機械学習モデルは、依存関係ファイルの全てのコミットをふるい分け、セキュリティリリースに関連する可能性があるものを抽出します。このモデルでは diff とコミット メッセージを使用して、どのように必要なバージョン範囲が変更されたかを学習し、変更の意図を理解します。次に、時間をかけて蓄積した学習データをもとに、依存関係がアラートをトリガーする必要のあるセキュリティ修正のある新しいバージョンをリリースしたかどうかを判断します。

今後の展望

現在 GitHub では、NuGet、Python、Ruby、npm、Yarn、Composer、Maven のエコシステムへのセキュリティ アラートと自動セキュリティ更新をサポートしていますが、オープン ソースのメンテナーはプロジェクトへの適用時に GitHub でアドバイザリを公開できます。弊社は今後も、脆弱性データに社内外で行われた更新を追加し、プロジェクトがリスクをより詳細に把握できるようサポートしていく予定です。また、サポートするエコシステムの数を増やすことも検討しています。

信頼できる情報開示とアクセス

コード スキャンや、悪意のある攻撃者からの保護を行ったとしても、脆弱性は必ず見つかるでしょう。そこで、脆弱性が発見された場合の情報開示と管理の方法はできる限りシンプルにしています。

まず、公共サービスとしてセキュリティ アドバイザリを提供するために、Security Advisory API をリリースしました。この API は強力なセキュリティ プラットフォームのビルド ブロックであり、GitHub が集約し、検証するセキュリティ フィードにアクセスする手段を提供するだけでなく、何百万ものプロジェクトにわたって弊社が監視する依存関係のアップグレードも提供します。これにより脆弱性データを簡単に入手でき、日常的に利用するツールやワークフローにすぐに統合できるようになりました。

また、Security Advisory API は追加の機能を提供し、GitHub Security Lab が発見して共有したマルウェアやその他の脆弱性などの懸念がある National Vulnerability Database フィードを補完します。API は公共サービスとして GitHub、研究者、インテグレーターが共同でよりセキュアなソフトウェアを作成するための基盤を提供します。

オープン ソース サプライ チェーンのセキュリティを改善するために、メンテナーは脆弱性を修正し、GitHub のリポジトリ内でアドバイザリを公開することにより脆弱性の存在を開示できます。この機能で作成されたアドバイザリはその後、内部アドバイザリ データベース サービスを通してキュレートされ、依存関係のアラート、外部データベース、API を使ってブロードキャストされます。ユーザーは CVE 識別子の割り当てをリクエストすることもできます。

弊社の最終的な目標は、セキュリティの脆弱性がどのように生じるかをより深く理解し、この情報を利用してコードの脆弱性ツールの改善と問題のより迅速な特定を実現することです。

今後の展望

脆弱性が導入された時期に関する Git History の詳細、その脆弱性に関連付けられたレビューなどを含む、トレーサビリティ機能を拡張する予定です。

パッケージ

パッケージに依存関係を持つプロジェクトに参加している場合、それらのパッケージを信頼し、コードを理解し、パッケージを構築したコミュニティとつながることが重要です。また組織の内部では、どのパッケージの使用が承認されているかをすばやく把握できることが必要です。GitHub Packages では GitHub と同一の使い慣れたインターフェースを利用して、あらゆる場所にある GitHub のパブリック パッケージだけでなく、企業やリポジトリ内で安全に保護されているプライベート パッケージも簡単に見つけることができます。1 つの場所からパブリックおよびプライベートのパッケージを安全に発見、利用、公開することが可能です。GitHub 上でホストされるパッケージには、パッケージ コンテンツ、ダウンロード統計、バージョン履歴といった全ての必要情報も含まれます。

今後の展望

GitHub Packages は現在、JavaScript (npm)、Java (Maven)、Ruby (RubyGems)、.NET (NuGet)、Docker イメージなどの使い慣れたパッケージ管理ツールをサポートしており、今後さらに多くのツールが追加される予定です。

依存関係インサイト

セキュリティが重要なのは、個々のリポジトリだけではありません。組織全体のセキュリティを理解するには、チームがビジネス クリティカルなアプリケーションをサポートする適切なスタッフを確保できるよう、どの言語に依存しているかを理解するなど、さらに多くのことが必要になります。中でもセキュリティでは、ソフトウェアの健全性をリアルタイムで把握することが必要です。

GitHub は組織に依存関係インサイトへのアクセスを付与することで、チームが使用中の全てのソフトウェアの依存関係を一度に、1 つの場所で閲覧できるようにします。また依存関係インサイトにより、セキュリティやコンプライアンスのポリシーが厳格な組織にとって特に重要な、セキュリティ アドバイザリが公開されている依存関係、特定のライセンスを使用する依存関係などをすばやくフィルターし、簡単に確認できるようになります。最後に、特定の依存関係を含む、全てのリポジトリや依存関係のマニフェストのリストを表示できるようになったため、自社の必須要件を満たさない依存関係のアップグレードや削除が可能です。

今後の展望

弊社は引き続き、その他のセキュリティ ツールだけでなく、インテグレーションやレポート機能を追加できるよう、依存関係インサイトのダッシュボードを拡張していく予定です。

トークン スキャン

オープン ソース プロジェクトを脆弱性のあるライブラリに依存しないようにすることは、すぐに効果を上げられる方法の 1 つです。別の方法として、セキュア コーディング プラクティスを適用したプロジェクトの開発をサポートして、セキュリティの脆弱性が明らかになる前に防ぐこともできます。リポジトリへのアクセス認証情報はコードの安全性を維持するうえで重要で、通常はチームにより管理されます。

しかし万が一誤って漏洩した場合には、どれほど安全な組織のアクセス トークンでも攻撃者の恰好のターゲットになります。GitHub では、弊社のプラットフォームに脆弱性や依存関係のセキュリティ情報をネイティブに提供したのと同様、開発者も秘密の漏洩から保護したいと考えています。

その第一歩が GitHub のトークン スキャンです。これは受信するコミットに極秘情報がないかを検査するスケーラブルなリアルタイム コード スキャン プラットフォームです。トークン スキャンでは、Amazon Web Services、Microsoft Azure、Google Cloud Platform、Slack、Stripe といった複数のプラットフォームからの認証情報を検出します。パブリック リポジトリでは、開発者が誤ってサポート対象のサービスのいずれかに認証情報をコミットした場合、それらのサービスと連携して、開示された情報を特定し、悪意のある攻撃者がそれらの情報を悪用する前に、その認証情報を無効にします。GitHub では 2018 年にトークン スキャンをリリースして以来、既に何百万ものトークンを特定してきました。今後はサポート対象のフォーマットやツールの幅をさらに広げていく予定です。

今後の展望

弊社はパブリック リポジトリで現在提供されているリソースを組織が利用できるよう支援します。組織は個人を特定できる情報やその他の極秘データを検索できる可能性のあるフォーマットなどの、定義したトークンをスキャンできます。

GitHub ではこれらのトークン フォーマットに加え、GitHub のコード スキャン プラットフォームに次のようなさまざまな機能やインテグレーション ポイントを追加していく予定です。

• 作成中のコードに対する一般的なセキュリティの脆弱性の検出
• ユーザー名やパスワードの漏えいといったその他の脆弱性の検出

また GitHub とコミュニティが構築したセキュリティ機能をサポートするため、弊社の機械学習とデータ サイエンス チームはセキュリティ問題の特定精度を高められるよう、ペタバイト単位のデータを解析します。こうした解析により、脆弱性を含むコードがマージされる前に開発者に通知し、開発者が最初からよりセキュアなソフトウェアを作成できるようサポートします。弊社の目標は、セキュリティの脆弱性が見つかった後で対応するだけでなく、オープン ソース プロジェクトに新たな脆弱性が取り込まれないよう阻止することです。

アクティビティのインサイト

オープン ソース プロジェクトは単なるコードではありません。あらゆる企業と同様、時間の経過と共にその人気と影響度は変化します。現在は特に重要なツールチェインでも、数か月後にはほとんど使われなくなっているかもしれません。GitHub では各オープン ソース プロジェクト コードの背後にある情報をユーザーが簡単に理解できるようにしています。

アクティビティ ダッシュボードにより、組織はチームが行っている作業に関するインサイトを得ることができます。ダッシュボードには開発パターン、チームがどのように GitHub プラットフォームを活用しているか、依存関係の脆弱性、問題に関する情報が提供されます。チームはこのデータを利用して、組織全体で使用している開発言語やセキュリティの脆弱性およびそれらの解決方法などの情報を入手することで、意思決定の精度を高め、よりセキュアなソフトウェアを構築できます。

また、アクティビティのインサイトは企業がチームでコラボレーションしながらコーディングを行ううえで GitHub をどう活用しているかを理解するのにも有効です。さらに、自組織のオープン ソース使用率の追跡、レポート、実行すべきアクションの見極めにも役立ちます。

プラットフォームのセキュリティ、コンプライアンス、健全性

GitHub プロジェクトのコードを適切に保護するには、プラットフォーム自体の安全性を確保する必要があります。4,000 万ものユーザーと何千もの企業にサービスを提供するソフトウェアを維持することは大仕事です。特に 2018 年初めに発生した過去最大の DDOS 攻撃など、システムダウンを目的とした侵害行為が活発に行われている状況ではなおさらです。

プラットフォームの保護と並んで、コンプライアンスも GitHub のセキュリティの重要な要素です。弊社は、GitHub が SOC II に準拠し、FedRAMP (低レベル) の認定を受けていることを誇りにしています。

オープン ソース コードを利用して開発されるソフトウェアの安全性を確保する

オープン ソース コードの安全性が向上すれば、その上に構築される内部ソフトウェアの安全性も高まります。弊社では同じツール、機能、製品を利用して企業のプライベート リポジトリの保護を行うと同時に、チームが外部コードを管理するお手伝いもしたいと考えています。

この戦略の第一弾が GitHub Connect です。これは GitHub Enterprise Cloud (弊社の SaaS ベースのソリューション) と GitHub Enterprise Server (オンプレミス、ファイアウォール内、プライベートクラウドで実行可能なセルフホステッド ソリューション) の間でより緊密なインテグレーションを実現する一連の機能です。

GitHub Connect

安全なオープン ソースは企業内で簡単に利用できて初めて有効と言えます。GitHub Connect により、最も重要なコードをファイアウォールで保護しながら、世界最大のソフトウェア開発者コミュニティおよび GitHub のオープン ソース プロジェクトに安全かつセキュアに接続できます。また GitHub Connect により、弊社は GitHub のパブリック リポジトリから取得した機能やデータをビジネス環境に提供できます。

ユニファイド サーチを使用すれば、開発者は GitHub Enterprise 内からオープン ソースとプライベート リポジトリを直接検索できます。これらのリポジトリに直接アクセスできるということは、既存のプロジェクトを活用し、ユーザーが求めるものを理解できるということです。これらは全て、適切に管理された可視性の高い安全なワークフローから実行できます。

また GitHub Connect を通して、重要なセキュリティ アラートと脆弱性の低減への明確な道筋といった情報など、GitHub のデータを利用することもできます。開発者と組織はプロジェクト内の脆弱性を修正しても、必ずしもそのことを他者に通知するわけではありません。これらの修正の背後にある集合データを可視化できることで、弊社はユーザーが脆弱または古いライブラリを使用しないようにし、万が一使用した場合にはユーザーに通知します。

最後に、開発リーダーには多くの意思決定が必要となりますが、GitHub Connect により、オンプレミスのままか、クラウドを使用するかという 1 つの重要な選択が不要になります。イノベーションに満ちたコミュニティとつながる、業務効率を最大化する、安全性を高める、優れたデベロッパーエクスペリエンスを提供するといったさまざまなメリットを全て、コードをすぐに利用できる状態に維持しながら実現できます。

今後の展望

これらの機能は序の口にすぎません。弊社は次に、現在オープン ソース プロジェクト全体で使用されているフォークとプルのワークフローを GitHub Enterprise に統合します。組織は GitHub からの単一の暗号化されたゲートウェイを使用して、企業の環境にコードをフォークし、ローカル アクセスできるようなります。単なるリリース済みバイナリとしてコードにアクセスするだけでなく、独自のツールでスキャニングや調査を実施できます。また GitHub に接続することにより、ボタンを押すだけでライブラリを最新の状態に維持でき、最新のセキュリティおよび重大なバグ修正を容易に統合できます。

さらに強化された検索機能により、企業の管理者はライセンスや評判を始めとするさまざまな要素に基づいて、ユーザーが環境に持ち込むことのできるオープン ソース ライブラリを制限することで、利用可能なコードを制御できるようになります。また GitHub の依存関係グラフを活用し、使用中の全てのライブラリが承認されたチャネルからのものであることを確認することが可能になります。

組織内のオープン ソース コードは、消費するだけでなく共有される場合もあります。自社のプロジェクトを世界に共有する場合でも、オーバーヘッドを削減するためにバグ修正やパッチを上流化する場合でも、GitHub Connect は社内の安全な環境から GitHub のオープン ソース プロジェクトへの接続を提供します。単なるプル リクエストではなく、オープン ソースのパッチやライブラリが法務、技術、場合によってはさらに上層部の承認を含む、社内承認基準を満たしているかどうかの追加のチェックを行うこともできます。開発者が使い慣れたオープン ソース ワークフローでの開発に加え、レビュー、承認、コンプライアンスの機能も提供されることで、組織はオープン ソースを最大限活用できます。

拡張可能なプラットフォームとしての GitHub

GitHub には常に、最善の組み合わせの理念があります。弊社はパートナーがシームレスなインテグレーションを作成し、新しい機能やワークフローで GitHub を拡張することができるプラットフォームを構築しています。この戦略はセキュリティ ツールにも当てはまります。

弊社はさまざまな組織がセキュリティ ワークフローに対してさまざまな戦略を取っているのを見てきました。ニーズに最も合う 1 つのツールを統合している企業もあれば、セキュリティ対策にはコストを惜しまないというアイディアで複数のツールを統合している企業もあります。GitHub Actions の導入により、必要なツールをこれまで以上に簡単に統合できるようになります。

どのような戦略であれ、セキュリティを運にまかせたいと考える企業はないでしょう。Black Duck、HP、IonChannel、Sonatype、Snyk、White Source を始めとするセキュリティ分野のリーダー企業のツールを統合できることにより、最新のアプリケーションとサービスを利用してビジネスを安全に保つことができます。また、新しいツールが利用可能になると、追加時と同じくらい容易に既存のツールを更新または置換できます。

社内ツールを使用して脅威インテリジェンスの管理やソフトウェア脆弱性の特定を行っている場合、GitHub の API を使ってそのツールを弊社のプラットフォームに統合したり、必要に応じて置き換えたりすることも可能です。GitHub Advisory Database 内で独自のアラートを作成したり、依存関係の API を使用したりして、使用中のライブラリやコードをより詳しく理解することにより、セキュリティをシフト レフトすることができ、ソフトウェア ライフサイクルのより早い段階で戦略を統合し、メリットを得ることができます。

今後の展望

GitHub のプラットフォーム戦略は、追加のインテグレーション方法、GitHub へのサポートを強化するパートナー、パートナーのやり取りをより豊かにする新たなデータセットにより、加速する一方です。多様な開発者のチームによって最適なソフトウェアが構築されるように、多様な一連のツールによって最適なソフトウェアが開発されます。GitHub ではこのサイクルをより容易かつ強力にしていきたいと考えています。