セキュアなソフトウェアを、共に開発する

ソフトウェアは、私たちの身の回りにある、あらゆるものに力を与えています。私たちが作るもの、服用する薬、そして摂取する食べ物ですら、その背後にはソフトウェアが存在しています。これから起こる飛躍的な進歩のすべてが、ソフトウェアの力を借りて成し遂げられることでしょう。ソフトウェアが使用されいないものを見つけることは、これからますます難しくなっています。

ソフトウェアが世界に力を与える存在であるならば、オープンソースはその鼓動を打つ心臓です。現在、すべてのソフトウェアプロジェクトの99%でオープンソースが使用されています。これは、本当に驚くべきことであり、非常に多くのオープンソースが無償で提供されているという取り組みの証です。オープンソースに貢献している人は皆、私たちすべての前進に一役を担っていることを誇りに思うべきです。

こうした成功には責任が伴います。オープンソースは、世界中の人々が信頼できるものでなければなりません。オープンソースの作成と使用は増加し続けているため、この問題はさらに重要になり、その困難も増しています。

新しいアプローチ

現在、セキュリティライフサイクルは崩壊しています。

脆弱性の特定は手作業で行われるため、その場しのぎのプロセスである。
仮に脆弱性情報が公表されたとしても、無責任に行われることが多い。
時期尚早な脆弱性情報の公表を回避するため、脆弱性の修正作業は通常のオープンソースワークフローの外部で実施されており、修正にあたってのサポートは提供されていない。
脆弱なソフトウェアを使用しているプロジェクトに関するセキュリティ警告の通知が開発者に配信されない。配信されたとしても、調査すべき問題(本物と誤検出の両方から成る可能性がある)の数と複雑さに圧倒されてしまう場合がある。
脆弱な依存関係の更新に非常に長い時間が必要、あるいは単に更新がまったく行われない。
脆弱性を引き起こしたミスの再発防止ができない。

世界中の大多数のオープンソースの中心的な存在として、GitHubはこの問題に対処する責任があると感じています。しかし、当社だけで対処することは不可能ですし、誰も単独では実現できません。ソフトウェアのセキュリティは全員で共有する問題であり、ソースコードの生産者と利用者、オープンソースのメンテナー、セキュリティ研究者、およびセキュリティチームに関係する責任です。GitHubでは、誰もが頼りにしているソフトウェアを保護するのに必要なツールをコミュニティに提供したいと考えています。

10年前、GitHubがPull Requestを導入したことで、開発者間のコラボレーションが促進されました。Pull Requestによってコントリビューションを管理する標準的なプロセスが作成されたように、開発エコシステムにも、オープンソースコードに含まれる脆弱性を管理するためのより適切に定義されたプロセスが必要です。これこそ、GitHubが構築しようと挑戦しているものです。

セキュリティアドバイザリ

オープンソースソフトウェアにおけるセキュリティ脆弱性の典型的なワークフローには、研究者、メンテナー、および開発者が関与します。

研究者が脆弱性を特定し、それをメンテナーに公表します。
メンテナーはその問題を修正し、コミュニティに警告を送信します。
開発者は修正済みバージョンに更新して、再発の防止を目指します。

私たちは、このワークフロー全体が現在のPull Requestと同じくらい自然なものになる必要があると信じており、すでにそのための対策を講じています。そして、引き続きさらなる対策を講じていきます。

GitHubでは現在、セキュリティアドバイザリを利用して、このライフサイクルの始めから終わりまで脆弱性を追跡できます。また、セキュリティアドバイザリによって、問題を発見した研究者と、その問題を修正したメンテナーおよびそれを頼りにしている開発者の連携が実現します。

セキュリティ研究者

世界中のコードベースを保護するにあたって、セキュリティ研究者は、脆弱性を特定し公表する点で重要な役割を担っています。ソフトウェア開発件数は増加していますが、セキュリティ研究者のコミュニティは拡大していません。よって、開発者に対するセキュリティ研究者の比率は低下し続けています。

大切なのは、こうしたセキュリティ研究者が可能な限り生産的に仕事ができることです。そのため、SemmleがGitHubの仲間となったことを非常に嬉しく思っています。

脆弱性を発見するには、通常、侵入テストを実行するか、手作業でソースコードを検査します。Semmleは、コードをデータとして扱うことでセキュリティ研究者の作業範囲を拡大します。QLという名前のコード解析エンジンは、コンパイラ最適化における最新調査と、データベース実装における洞察を組み合わせて使用します。コードに内在する複雑なデータ構造を把握し、研究者が宣言型でオブジェクト指向のクエリ言語を使用して解析を利用できるようにします。

リレーショナルデータベースにおいてデータに関する非常に高度な問い合わせが簡略化されるのと同じように、Semmleでは、研究者は大規模なコードベースに含まれるセキュリティ脆弱性を非常に簡単かつ迅速に特定することができます。多くの脆弱性には、その根本的な原因と同じタイプのコーディングミスが存在しています。Semmleを利用することで、コーディングミスのバリエーションをすべて見つけることができるため、同様な脆弱性を除去できます。Semmleはこのアプローチを取ることで多くの問題を飛躍的に少ない誤検出で見つけることができます。

セキュリティ研究者は、QLクエリを使用して脆弱性とその変種を特定します。このクエリを共有し、多くのコードベースで実行できるため、セキュリティ研究者は自由になった時間を使って自分の好きなことをしたり、新しい脆弱性の追跡などに全力を尽くすことができます。QLは宣言型およびオブジェクト指向であるため、従来のコードアナライザーを使用する場合よりもはるかに簡単に新しい解析を作成することができます。ユーザーは他のツールで見つけられなかった多くの脆弱性を発見できるようになり、以前は数週間以上かかっていたタスクを数時間で完了することができます。

Semmleのアプローチの成功を計る重要な評価基準となるのが、Semmleのテクノロジーによって特定、公表された脆弱性の件数です。現在、オープンソースプロジェクトに存在する100件以上ものCVEがSemmleを使用して検出されており、その中にはApache Struts、AppleのXNU、Linuxカーネル、Memcached、U-Boot、およびVLCといった話題のプロジェクトも含まれています。同等の成功率を誇るコード解析ツールは、他に存在しません。

GitHubユーザへのSemmleテクノロジーの提供は、まだ初期段階です。今後もご期待ください。

研究者または開発者が脆弱性を発見したら、その次は、プロジェクトメンテナーと共に公表を調整します。しかし、メンテナーを特定すること、ましてや非公開の方法で連絡を取るのが難しい場合があります。どのようなOSSプロジェクトであっても、誰もがセキュリティの脆弱性について安全に報告できるようになるべきです。セキュリティポリシーは、それをGitHub上で実行できるように支援する、小さな第一歩です。

プロジェクトの脆弱性が報告されると、プロジェクトのメンテナーはセキュリティアドバイザリを作成できます。これにより、研究者、メンテナー、および開発チームはその脆弱性への最善な対処方法を非公開で調整できます。

メンテナー

メンテナーが受けるプレッシャーは、計り知れません。公開発表するすべてのリリースが安全であることを確認しなければならない上に、脆弱性が見つかったときに迅速に修正する責任を負っています。メンテナーが抱える課題がより一層難しくなっているため、問題を誤って公表してしまうことを恐れて、通常のツールで修正に取り組むことすらできないことが多くあります。

セキュリティアドバイザリ内において、メンテナーは共同で修正を行うための安全な場所としてプライベートフォークを作成できます。将来的には、Github Actionsを使用したプライベートCI機能を搭載するなど、このプライベートフォークを完全な作業環境にする予定です。

メンテナーは修正が完了したら、脆弱性に対応するパッチ適用済みバージョンを公開し、さらに重要なこととしてセキュリティアドバイザリを公開します。コミュニティが必ず適切なタイミングで脆弱性の存在を認識できることは、私たちがGitHubで実行できる最も価値あることの1つです。利用可能な解決策があるにもかかわらず、大規模コミュニティによって取り上げられていない脆弱性を使用したエクスプロイトが頻繁に発生しています。現在、ますます増え続ける言語に対応して、GitHubではプロジェクトに存在する依存関係を依存関係グラフで把握できます。

これにより、GitHubでは、脆弱性の影響を受けるすべての下流ユーザに対して、GitHub内およびメールで警告することができます。また、今後も、こうした警告方法の最適化に取り組みます。

GitHubは現在、GitHub上で直接報告されたアドバイザリ、および他のソース(脆弱性情報データベース、MITRE、およびWhiteSourceなど)をベースにして脆弱性に対する警告を出しています。GitHubはそれらすべての脆弱性を監視するだけでなく、警告を出す前にその影響と影響を受けるユーザーを確認し、実用的な情報に編集してユーザーに通知します。

GitHubがCVE採番機関に認定

私たちは、脆弱性データを迅速かつ自由に移動させることは、ソフトウェアセキュリティの改善に不可欠であると確信しています。だからこそ、GitHubがオープンソースプロジェクトのCVE採番機関として承認されたことをお伝えできることを大変嬉しく思います。私たちは、GitHubで開かれているセキュリティアドバイザリに対してCVEを採番することができ、業界全体でさらに広範囲な認知を可能にします。

開発者

開発者には、安全なソフトウェアを提供するという極めて重要な仕事があります。その仕事の大部分を占めているのが、依存関係を最新の状態に保つことです。

しかし、警告を通知するだけでは十分でないことが多く、かなりの割合の重要な脆弱性が数カ月間も未パッチのままに放置されています。パッチを当てていないコードが急増すれば、企業やユーザーへのリスクは増大します。

依存関係の更新はできる限り簡単に実行できる必要があります。今年の上半期に買収したDependabotによって、現在、GitHub内でセキュリティ修正を自動で行えるようになりました。この機能により、開発者は依存関係に手作業でパッチを適用する必要がなくなります。依存関係に脆弱性が見つかると、GitHubはパッチを受け入れるのに必要な情報と共に、下流のリポジトリで自動的にPull Requestを発行します。

開発者の希望として、新しい脆弱性を発生させたくないということもあるでしょう。これは、いろいろな意味で、特に困難な課題です。業界内で継続的な革新が行われている分野ではありますが、私たちが現在取り組んでいることが幾つかあります。

GitHubトークンスキャニングでは、15社を超えるプロバイダのパブリックコードをスキャンしてシークレットを探します。GitHubは、AzureおよびAWSなどのプロバイダと連携して、シークレットが有効であることを確認し、シークレットの所有者に対してその公開を安全に無効化および修正するように通知します。近日中に、この機能にはコミュニティのプライベートコードを対象としたオプションのスキャニングも追加される予定です。

最後に、Semmle QLは開発者とメンテナーの両者にメリットをもたらします。Semmle QLには、業界トップクラスの複数名のセキュリティ研究者によって定義された数千件のクエリとすべてのオープンソースのライブラリが含まれています。これらのクエリを使用して、Pull Requestワークフローの一環として脆弱性を検出し、リリース前に脆弱性を阻止することができます。

セキュリティチーム

開発者は多忙なため、セキュリティの脆弱性を見過ごしまう可能性があることを、私たちは理解しています。これにより、企業が顧客を脆弱性に晒してしまう恐れがあります。そのため、GitHubではセキュリティ、コンプライアンス、およびオープンソースを担当するすべてのスタッフが、依存関係インサイトを使用して、セキュリティの脆弱性に関する企業のオープンソースの依存関係をすぐに検査できるようにしています。

すべての人にとってより安全な未来

非常に大規模なオープンソースコミュニティは、セキュリティ研究者を抱える企業の支援を受けています。しかし、大多数のプロジェクトにはセキュリティ問題を調査、対処、および連絡するためのツール、専門知識、またはリソースがまったくありません。

私たちはこの問題の解決に取り組んでいます。GitHubの使命は、開発者が共同作業するためのグローバルなプラットフォーム、つまり、私たち全員が共に世界中のソフトウェアを保護するために利用できるプラットフォームを構築することです。