開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 1

開発者ファーストの アプリケーション セキュリティ完全ガイド

G i t H u b作 成

目次

10

16

33

24

パート1：アプリケーションセキュリティの現状

パート2：アプリケーションセキュリティに対する従来のアプローチと新しいアプローチ

まとめ

パート3：GitHubで実現する開発者ファーストのアプリケー ションセキュリティ

3

5

はじめに

エグゼクティブサマリー

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 3

はじめに

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 4

グローバル化とデジタル変革が進んだ結果、ビジネスは 0 と 1 のビットの上で運営されています。業界に関係なく、高い業績を上げている企業はすべて、同じゴールに向かってと競い合っています。カスタマーエクスペリエンスを、卓越したデジタルファーストの媒体へと転換しようとしているのです。

こうしたデジタルエクスペリエンスはソフトウェアによって促進されるため、ビジネスプロセスの遂行に必要なソフトウェアの開発はあらゆる規模の企業にとってコアコンピテンシーとなっており、今やすべての企業がテクノロジー企業です。それと同時に、企業におけるソフトウェアの利用と重要性が高まったことで悪意ある行為者にとって絶好のターゲットとなっており、その結果、破壊的なデータ侵害が発生しています。侵害の最初の攻撃ベクトルを特定することは困難ですが、後からの調査により、最近の大規模な侵害の多くはアプリケーション層の脆弱性を利用していたことが分かっています1。

ソフトウェアが提供する機能と処理するデータの観点から、多くの企業にとってソフトウェアがいかに重要であるかを考えると、ソフトウェアのセキュリティ侵害を生じさせ続けるわけにはいきません。ソフトウェア開発が重視され、アプリケーションセキュリティが向上しているにもかかわらず、ソフトウェアの脆弱性はコードによって直線的に増え続けています。どうすればこの関係を断ち切り、より安全なソフトウェアを提供することができるでしょうか？このホワイトペーパーでは、アプリケーションセキュリティの現状に目を向け、持続可能なソリューションを提案します。また、世界のソフトウェア保護に対する GitHub の責任と、企業がより安全なソフトウェアを提供し、革新を実現できるようサポートする GitHub の取り組みについてもお伝えします。

はじ め に

-------- 1: 「2020 Open Source Security and Risk Analysis Report (2020年オープンソースセキュリティおよびリスク分析レポート)」、Synopsys

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 5

エグゼクティブサマリー

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 6

パート1：アプリケーションセキュリティの現状

アプリケーションセキュリティでは、ツール、プロセス、ベストプラクティスのシステムを活用して、ソフトウェア開発におけるビジネスリスクを管理します。ソフトウェア開発セキュリティは、リスクアペタイトやソフトウェアの重要度、セキュリティプログラムの成熟度に応じて、単純なリスク認識から、脆弱性を迅速 ( 理想としては本稼働前 ) に識別して修復する確立されたパイプラインまで、大きな幅があります。最新のソフトウェアはオープンソースで構築されていますが、オープンソースコンポーネントの導入が増えるにつれ、開発者およびセキュリティチームに対するセキュリティリスクも増大しています。

現在の平均的な企業の場合、アプリケーションセキュリティは、ソフトウェア開発サイクルと統合された少数のテストツールで構成されています。現在の一般的なコンセプトには、静的アプリケーションセキュリティテスト(SAST)、動的アプリケーションセキュリティテスト (DAST)、パッシブおよびアクティブ統合アプリケーションセキュリティテスト (IAST)、ランタイムアプリケーションセキュリティ保護 (RASP)、ファジング、ソフトウェア構成分析 (SCA)、侵入テスト、バグ報奨金などがあります。

アプリケーションセキュリティは、企業の成熟度、使用ツール、能力に応じて、ソフトウェアをデプロイする前の最終ゲート、または開発サイクルに統合された一連のテストとして扱われます。

エグゼクティブ サ マリー

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 7

パート2：従来型とエンドツー エンド型

従来型アプローチ：ゲートとしてのセキュリティデプロイメントの前にゲートとしてセキュリティ対策を講じることは最も伝統的なアプローチであり、多くの場合、アプリケーションセキュリティを開始する企業にとって最初のステップとなります。このアプローチは、品質保証フェーズで行われる複数のセキュリティテストで構成されます。これらのテストはセキュリティチームやサードパーティベンダーによって提供され、その結果は、本稼働環境にデプロイする前にすべてを修正するため開発者にまとめて提供されます。

この従来型のゲートアプローチで最もよく使われているセキュリティ評価ツールは、SAST、DAST、IAST、SCAです。ゲートとしてのセキュリティはアプリケーションセキュリティがまったくないよりは良いのですが、このアプローチは安全なソフトウェアを提供する上で、開発者の摩擦と開発の遅れを引き起こします。セキュリティフィードバックの遅れは混乱を引き起こし、手動でのレビューはボトルネックにつながり、スキャン結果はノイズ対信号比が高くなります。これらすべてが開発者の不満を招き、開発スピードを乱します。

エンドツーエンド型アプローチ：開発サイクルの各ステップに統合されたセキュリティ

アプリケーションセキュリティの成熟度が高い企業は、エンドツーエンド型アプローチを採用しています。このアプローチでは、開発者にアプリケーションのセキュリティに関するフィードバックをより早く提供 (「セキュ

エグゼクティブ サ マリー

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 8

リティをシフトレフト」) し、開発ライフサイクル全体で統合および自動化機能を活用することにより、従来型アプローチより優れた結果をもたらします。ただし、従来型アプローチの欠点と同様に、エンドツーエンド型アプローチには以下の 4 つの摩擦を生むポイントがあります。

1. 統合を常に維持する必要があり、バージョンの更新により頻繁に中断が生じる

2. セキュリティチームと開発チームが引き続き連携せずに作業している。

3. 自動化ツールでは誤検知の問題は解決しない。

4. 従来のツールではソフトウェアエコシステムのペースについていけない。

DevOps ライフサイクル (DevSecOps と呼ばれることもあります ) のセキュリティや、セキュリティのシフトレフトなど、アプリケーションセキュリティへの比較的新しいアプローチにより、上記のアプローチが大幅に改善されることが示唆されましたが、ツールとプロセス自体が停滞しているため、ほとんど変化はありませんでした。

パート3：GitHubで実現する開発者ファーストのアプリケーションセキュリティ

運用コードの脆弱性の数を実際に減らすには、セキュリティチームは開発者と協力して、望ましい環境で既存のワークフローを活用する必要があります。開発者をアプリケーションセキュリティの中心に置くことは、セキュリティをシフトレフトし、最高のチームでさえ圧倒するほど増大している技術的負債に対抗する最も効果的な方法です。

エグゼクティブ サ マリー

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 9

GitHub を使用すると、開発者ファーストのアプローチで安全なソフトウェアを作成し、開発者は学んだ教訓を共有して、現在のアプリケーションセキュリティの問題にすぐに取り組むことができます。GitHub は摩擦の原因となる複数のツールに依存する代わりに、開発者ワークフローに既に組み込まれている統合されたネイティブの自動化ソリューションと、開発プロセスの各ステップで行う追加のセキュリティコードレビューを提供します。開発者は、サプライチェーンおよびコードセキュリティ機能 ( コードスキャン、脆弱な依存関係に対する Dependabot アラート、Dependabot セキュリティアップデート、シークレットスキャンなど )を使用して、開発ワークフロー内でセキュリティフィードバックを取得します。セキュリティリスクに早期に対処して、脆弱性の修正を自動化し、より安全なソフトウェアをより迅速に出荷できます。

エグゼクティブ サ マリー

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 1 0

パート 1：アプリケーションセキュリティの現状

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 1 1

アプリケーションセキュリティでは、ツール、プロセス、ベストプラクティスのシステムを活用して、ソフトウェア関連のビジネスリスクを管理します。アプリケーションセキュリティは、許容するリスクレベルとソフトウェアの重要度に応じて、リスクをただ認識することから、脆弱性を迅速 ( 理想としては本稼働環境へのデプロイ前 ) に特定して修正する確立されたプロセスを持つことまで、大きな幅があります。

最新のソフトウェアはオープンソースで構築されています。Synopsys の「2020 Open Source Security and Risk Analysis Report (2020 年オー

プンソースセキュリティおよびリスク分析レポート)」によると、企業のコードベースの 99 パーセントにオープンソースコードが含まれています 1。しかし、オープンソースコンポーネントの導入が増えるにつれ、攻撃にさらされる可能性が高まり、開発者およびセキュリティチームに対するセキュリティリスクも増大しています。たとえば、プロジェクトでは、依存関係として使われている、パッチが適用されていないオープンソースコンポーネントから脆弱性を継承することがよくあります。このようなリスクが生じる可能性は高まっています。Sonatype の「2019 State of the Software Supply Chain Report (2019 年ソフトウェアサプライチェーン状況レポート)」によると、「過去 5 年間で確認された、または疑わしいオープンソース関連のセキュリティ侵害は 71 パーセント増加」しています 2。

アプリケーションセキュリティへのさまざまなアプローチの詳細を説明する前に、一般的なアプリケーションセキュリティのコンセプトを確認しましょう。

静的アプリケーションセキュリティテスト(SAST)：

SAST では、ソフトウェアのソースコードまたはバイナリコードを入力し、このコードをスキャンして既知の脆弱なコードパターンを探し、生成する結果で潜在的な脆弱性を特定します。SAST ツールは通常、ソフトウェア開発の初期段階から後期段階、特にコードを製品化する前に使用します。

パ ート1：ア プ リケ ー ション セ キュリティの 現 状

-------- 1: 「2020 Open Source Security and Risk Analysis Report (2020年オープンソースセキュリティおよびリスク分析レポート)」、Synopsys 2: 「2019 State of the Software Supply Chain Report (2019年ソフトウェアサプライチェーン状況レポート)」、Sonatype

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 1 2

パ ート1：ア プ リケ ー ション セ キュリティの 現 状

SAST ツールでは複数のアナライザーを実行して、コード全体から潜在的な脆弱性を探します。ただし、コンテキストと悪用可能性を検証できなければ「ノイズの多い」結果になる可能性があります。スキャンの結果は既知の脆弱性パターンに基づいて生成されるため、あまり正確ではなく、多くの SAST ツールが誤検知を起こします。スキャンには数時間から数週間という非常に長い時間がかかるだけでなく、未加工のスキャン結果をレビューするには大変な労力を要します。セキュリティチームや開発リーダーは、誤検知を排除しながら、正しく検知されたものを検証して優先順位付けを行う必要があります。これは、従来のSASTツールのボトルネックになっています。

動的アプリケーションセキュリティテスト(DAST)：

DAST では、該当するソフトウェアのコードを調べて攻撃面またはアプリケーションツリーを特定し、ソフトウェアをテスト環境にデプロイして、シミュレートされた攻撃を実行します。DAST ツールは通常、コード出荷前の QA 中、および本稼働ソフトウェア上で使用します。

このプロセスは未加工のスキャン結果を生成し、ユーザーインターフェイスを介して利用できる脆弱性など、潜在的に悪用可能な脆弱性を指摘します。結果として、DAST ツールは、SAST ツールで報告された、悪用可能であることがわかっているアプリケーション層の脆弱性のサブセットを特定します。また、DAST ツールは、ソフトウェアの実行環境 ( サーバー、フレームワーク、ネットワーク ) に関連する脆弱性など、SAST ツールが見逃した脆弱性も見つけることができます。これが、ソフトウェアのリスク状況を包括的に理解するために、SASTと DAST を補足的に使用する理由です。DAST ツールは、受信したサーバー応答を使って攻撃結果を検証するため、修正を計画する前にスキャン結果を手動でレビューする必要があります。

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 1 3

パ ート1：ア プ リケ ー ション セ キュリティの 現 状

統合アプリケーションセキュリティテスト (IAST)：

IAST では、該当するソフトウェアと一緒に実行するエージェントをインストールすることにより、セキュリティの脆弱性を見つけます。IAST は通常、継続的インテグレーション (CI) および品質保証 (QA)フェーズで使用します。

IAST には 2 つのバリアントがあります。

パッシブ IAST は、テスト環境で実行するアプリケーションに使用します。アプリケーションでユースケースベースのQAテストを実行すると、エージェントがセキュリティの潜在的な脆弱性を特定します。このアプローチでは、SAST または DAST を使用して検出できる脆弱性のサブセットも検出します。

アクティブ IAST は、ライブ環境で実行しているアプリケーションに使用します。これは DAST ツールの拡張機能として機能します。実行中のアプリケーションにエージェントがインストールされ、アプリケーションに対して DAST テストを実行します。エージェントはスタックトレース情報を確認し、サーバー側で詳細な動作を分析できるため、DAST のプロセスと結果が改善されます。アクティブ IAST は、スキャン時間を短縮し、DAST の攻撃結果を検証するのに役立ちます。

ランタイムアプリケーションセキュリティ保護(RASP)：

RASP では、実行中のアプリケーションにアクティブエージェントをインストールし、このエージェントを使用してアプリケーションを実行時に保護します。他の AST ツールとは対照的に、RASP ツールは、本稼働環境で実行しているアプリケーションのアクティブな脆弱性の悪用に対して使用します。RASP エージェントは、事前定義された一連の脆弱性を検出し

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 1 4

て防止できますが、特に使用量が多い場合や、DoS 攻撃、DDoS 攻撃の場合にアプリケーションのパフォーマンスを低下させる可能性があります。

ファジング： ファジング ( またはファズテスト) では、自動または手動による方法で無効なデータ、予期しないデータ、またはランダムなデータを生成し、テスト環境で実行しているアプリケーションへの入力として使用します。これらの入力を送信する際、該当するソフトウェアのクラッシュ、異常な動作、潜在的なメモリーリークなどの例外を継続的に監視します。ファジングは該当するソフトウェアに関する追加の情報を提供し、DAST を補足する手段として機能します。

ソフトウェア構成分析 (SCA)：

SCA は、オープンソースソフトウェア（OSS）などサードパーティのコンポーネントのセキュリティ問題とライセンスコンプライアンスに焦点を当て、ソフトウェアを分析します。SCA は、ソフトウェア開発の初期フェーズでよく使用されます。

今日の SCA ツールでは、サードパーティコンポーネントのインベントリーを作成し、それらのコンポーネントを確認して、既知の脆弱性やライセンスコンプライアンスのようなその他の運用上のリスクがないかを確認します。場合によっては、開発者が使用できる、検証済みのコンプライアンス対応コンポーネントライブラリーも提供します。

侵入テスト：侵入テストには、実行しているアプリケーションのセキュリティ制御のテストを目的とした、自動および手動でのテストが含まれます。ほとんどの

パ ート1：ア プ リケ ー ション セ キュリティの 現 状

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 1 5

場合、侵入テストは本稼働環境で実行しているソフトウェアのみを対象としますが、本稼働前の環境を対象とすることもできます。

侵入テストは、内部または外部のチームによって実行され、通常はレポートにまとめられます。これらのテスト結果は、既にテストチームによって検証されていますが、侵入テストは計画が必要であり、自動スキャンによる方法より時間がかかります。侵入テストでは、技術的な脆弱性だけでなく、ソフトウェアの論理フローやユーザーエクスペリエンスの障害も検出できます。

バグ報奨金： バグ報奨金は、クラウドソーシングによるセキュリティテストプログラムであり、各セキュリティ研究者が発見した脆弱性に応じて報奨金を支払います。バグ報奨金は、上記のすべての方法を補うソリューションとして機能しますが、通常はソフトウェアのセキュリティ状況を包括的にカバーするものではありません。

現在の平均的な企業の場合、アプリケーションセキュリティは、ソフトウェア開発サイクルと統合された少数のテストツールで構成されています。アプリケーションセキュリティは、企業の成熟度、使用ツール、能力に応じて、ソフトウェアをデプロイする前の最終ゲート、または開発サイクルの一部として統合された一連のテストとして扱われます。

では、2 つのアプローチとそれらが開発者にとって何を意味するかを見ていきましょう。

パ ート1：ア プ リケ ー ション セ キュリティの 現 状

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 1 6

パート 2：従来型とエンドツーエンド型

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 1 7

従来型アプローチデプロイメントの前にゲートとしてセキュリティ対策を講じることは一般的なアプローチであり、多くの場合、アプリケーションセキュリティを開始する企業にとって最初のステップとなります。この「従来型」アプローチは、品質保証フェーズ中に実行する単一または一連のセキュリティテストで構成されます。これらのセキュリティテストはセキュリティチームやサードパーティによって実行され、セキュリティテストの結果は修正のために開発者にまとめて提供されます。テストで判明したことは、アプリケーションを本稼働させる前に修正することが求められます。

ゲートとしてのアプリケーションセキュリティ

パ ート2：従 来 型 と エ ンド ツ ーエ ンド 型

PR

プロジェクトの設定

出荷

プロジェクトの開始

SASTSCADASTIAST

SAST DASTSCA IAST

マージ

コードレビュー

CD

コミット

コーディング/テスト

継続的なデプロイメント

QAと統合テスト

継続的インテグレーション/テスト

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 1 8

この従来型のゲートアプローチでは通常、チームは SAST、DAST、IAST、SCA ツールを使用します。

ゲートとしてのセキュリティはアプリケーションセキュリティがまったくないよりは良いのですが、安全なソフトウェアを提供する上で、開発者の摩擦と開発の遅れを引き起こします。これは、主に以下の 3 つの理由によります。

1. セキュリティフィードバックの遅れにより混乱が生じる。セキュリティフィードバックは開発後期 ( 大抵はコード作成から数週間後 ) に届くため、開発者は既に次のスプリントやプロジェクトに進んでおり、問題の脆弱なコードのことはもはやあまり考えていません。開発者がコードとコンテキストを思い出すまで時間がかかる場合がある上、修正には追加のスプリント計画が必要になることが多く、現在のプロジェクトが遅れる可能性があります。Veracode の「State Of Software Security Report Volume 9 ( ソフトウェアセキュリティ状況レポートVol. 9)」によると、「すべての欠陥の 70 パーセント以上が発見から1 か月経ってもそのままであり、約 55 パーセントは発見から 3 か月経っても残っている」としています3。

2. スキャン結果のノイズが多い。従来のアプリケーションセキュリティツールでは、正確な検知ごとに複数の誤検知が生じるため、スキャン結果のレビューは大変な作業となります。こうしたレビューは通常、スキャンしたプロジェクトについて限定的な知識しかないセキュリティチームが行うため、スキャン結果の監査は困難で大変な労力を要します。別のアプローチとして、レビューしていないスキャン結果を開発者にプッシュすることもできますが、評価する負担が開発者にかかり、実際に問題を修正する取り組みの優先順位が下がります。 どちらの場合も、修正すべき項目としてかなりの量の誤検知が開発者に伝わり、混乱と不満が生じます。

パ ート2：従 来 型 と エ ンド ツ ーエ ンド 型

-------- 3: 「State of Software Security Report Volume 10 (ソフトウェアセキュリティ状況レポートVol. 10)」、Veracode

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 1 9

パ ート2：従 来 型 と エ ンド ツ ーエ ンド 型

3. 手動によるレビューがボトルネックを生む。自動ツールでスキャン結果を生成した場合でも、正確な検知を特定し、誤検知を排除するためには手動によるレビューが必要です。セキュリティチームは開発者よりもはるかに人数が少ないため、レビューを必要とする膨大な量のレビューされていないスキャン結果に対応していくことができません。手動によるレビューは、平均的なプロジェクトで数日から数週間かかる場合があり、プロジェクトのタイムラインにボトルネックと遅延を生じさせます。手動によるレビューの結果が期待されたものでなかった場合、遅延はさらに不満を生む可能性があります。ほとんどの場合、セキュリティ結果の遅れは、問題を修正するとプロジェクトのタイムラインに間に合わなくなるため、既知の脆弱性を含んだままリリースを出荷しなければならないことを意味します。 従来のセキュリティのもう 1 つの欠点は、優先順位の高いプロジェクトでなければ、手動によるレビューを受けられないことです。レビューされていないスキャン結果は開発者と直接共有できますが、これは誤検知 ( 非検出 ) 率の高い、未検証のスキャン結果です。こうしたスキャン結果はすぐにフラストレーションを引き起こすものとなり、開発者は頻繁に発生する誤検知に鈍感になって、スキャンを無効にしたり結果を無視したりするようになります。どちらの場合も、企業のリスクが高まります。セキュリティ問題への対処が間に合わないと、セキュリティ問題がデータ漏洩の原因となっていることが判明した場合や、既知の問題を修正しないことが顧客との契約上の違反となるなど、法的責任になる可能性があります。

エンドツーエンド型アプローチアプリケーションセキュリティの成熟度が高い企業は、エンドツーエンド型アプローチを採用しています。このアプローチは開発の初期段階から始まり、開発ライフサイクル全体に、より多くの相互作用ポイントがあります。

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 2 0

「エンドツーエンド型アプローチ」

パ ート2：従 来 型 と エ ンド ツ ーエ ンド 型

エンドツーエンド型アプローチでは、早期にセキュリティフィードバックを開発者に提供し、ツールの統合および自動化機能を活用します。ただし、従来型セキュリティと同様に、エンドツーエンド型セキュリティにも摩擦を生むポイントがいくつかあります。

1. 統合を常に維持する必要があり、バージョンの更新により頻繁に中断が生じる。セキュリティツールは開発プロセスと統合されていますが、この統合は頻繁に中断されます。セキュリティ問題に対処するために、開発者は現在のタスクを切断して別のポータルにログインし、別のツールやシステムを処理する必要があります。セキュリティフィードバックはコンテキストが不十分で、コンテキストの切り替えは依然として課題となっています。ユーザーエクスペリエンスは、開発者にとって問題のある非効率的なものとなります。

2. セキュリティチームと開発チームが連携せずに作業している。ツールを変更するだけでは、プロセスは変わりません。エンドツーエンド型セ

PR

プロジェクトの設定

IDE プラグインIASTSCA

出荷

プロジェクトの開始

SASTSCA

SASTSCADASTIAST

SASTDASTSCA

侵入テストバグ報奨金

マージ

コードレビュー

CD DAST

コミット

コーディング/テスト

CD

QAと統合テスト

CI/テスト

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 2 1

キュリティが機能するには、セキュリティチームとソフトウェア開発チームの連携不足に対処する必要があります。統合ツールはアプリケーションセキュリティプロセスの一部を効率化しますが、このアプローチでも、セキュリティチームと開発チームのコラボレーションを強化するには不十分です。 セキュリティチームは、これまでと同様にテスト結果のレビュー担当者の役割も果たしています。たとえば、メインブランチのすべてのコミットがスキャンされ、新しいアラートはレビューのためにセキュリティチームに送信されます。セキュリティチームは問題をトリアージし、修正のために開発者に返送する必要があります。また多くの場合、セキュリティチームがリリース時のゲートプロセスも担当しています。早期に発見されるものもあるため、これはセキュリティテストをゲートとして使用するより優れたアプローチです。ただし、これらのチームには、コラボレーションするための共通のプロセスとプラットフォームがまだありません。連携およびコミュニケーション不足により、問題がチーム間でやり取りされるうちに大抵は遅延が生じ、時には衝突も生じます。

3. 従来のツールを自動化しても、誤検知の問題は解決しない。自動化されたアプリケーションセキュリティツールについて考えることは素晴らしいことですが、実際には、スキャンを自動化して問題追跡ツールに結果をプッシュすると、対処できない問題が大量に発生します。ここで問題となるのが誤検知と、ノイズに鈍感になる開発者です。アラートが多すぎると、それらをすべて「誤検知」または「修正しない」としてマークするなど、開発者はテスト結果を無視します。従来のセキュリティツールには、時間をかけて感度を調整したり結果を改善したりするカスタマイズ機能がないため、結果が開発者フローにプッシュされると、開発者はこれらのツールをオフにしてしまいます。

4. 従来のツールではソフトウェアエコシステムのペースについていけない。今日のソフトウェアエコシステムは、オープンソース、新しいプログラミング言語、新しいフレームワーク、そして驚異的なペースで進化する新しいツールで構成されています。従来の商用ツールは小規模なベンダーチームによって作成、更新、サポートされているため、エコシステ

パ ート2：従 来 型 と エ ンド ツ ーエ ンド 型

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 2 2

ムのペースについていくのはとても大変です。また、こうしたベンダーと開発者コミュニティの間のコミュニケーションは非常に限られているため、調査チームは OSS の脆弱性を積極的に探す必要があります。これは 1 億以上のパブリックリポジトリを検索する必要があり、スケーラブルではありません。結果として、ほとんどの商用ツールは、アプリケーションセキュリティの少数の側面だけうまく機能しているか、ソフトウェアエコシステムのごく一部のみにサポートを限定しています。つまり、開発者とセキュリティチームは、単一のユースケースに対して複数のツールを使い、複数のベンダーと協力するか、自社製のソリューションに投資して、商用ツールで対応できない欠落部分を埋める必要があります。

DevSecOps とシフトレフトアプリケーションセキュリティへの比較的新しいアプローチ(DevSecOps やセキュリティのシフトレフトなど ) は、従来型およびエンドツーエンド型のセキュリティが大幅に改善されることを示唆しています。ただし、ツールとプロセスがほぼ変わっていないため、変革はほとんど進んでいません。

DevSecOps を活用しても、従来型およびエンドツーエンド型のセキュリティアプローチは依然として次のような共通の問題を共有しています。

1. 開発者とセキュリティチームの間で高い摩擦が生じる

2. 既知の脆弱性を持ったままソフトウェアがリリースされることが多い( ソフトウェアの 83 パーセントは最初のスキャンでセキュリティ上の欠陥が 1 つ見つかり、3 分の 2 のソフトウェアが OWASP Top 10 とSANS 25 に基づくテストに合格しない 3)

パ ート2：従 来 型 と エ ンド ツ ーエ ンド 型

-------- 3: 「State of Software Security Report Volume 10 (ソフトウェアセキュリティ状況レポートVol. 10)」、Veracode

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 2 3

3. 発見された脆弱性の修正率が低い (セキュリティ上の欠陥の 56 パーセントしか修正されず、重大度が高い欠陥の 24 パーセントが開発者によって修正されないままになっている 3)

4. 検出された問題が長期間公開されている (セキュリティ上の欠陥が修正されるまでの期間の中央値は 59 日 3)

これらすべての課題が組み合わされた結果、過去 5 年間にわたり Webアプリケーションがセキュリティ侵害の主な原因として報告されていることは驚きに値しません 4。

パ ート2：従 来 型 と エ ンド ツ ーエ ンド 型

-------- 3: 「State of Software Security Report Volume 10 (ソフトウェアセキュリティ状況レポートVol. 10)」、Veracode 4: 「2016, 2017, 2018, 2019 and 2020 Data Breach Investigation Reports (2016、2017、2018、2019、2020年データ漏洩調査レポート)」、

Verizon

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 2 4

パート 3： GitHub で実現する開発者ファーストのアプリケーションセキュリティ

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 2 5

GitHub で実現する開発者ファーストのコミュニティ主導型セキュリティ

開発ライフサイクルの早い段階で開発者がセキュリティの問題を特定して修正できない限り、技術的負債はソフトウェアエコシステムの課題であり続けます。また、他の多くの課題と同様に、アプリケーションセキュリティの問題は、ソース上で解決することが最も簡単で、コスト効率が最も良くなります。運用コードの脆弱性の数を実際に減らすには、開発者と協力して、望ましい環境で既存のワークフローを活用する必要があります。

セキュリティをシフトレフトし、圧倒的な技術的負債を克服する方法は 1 つしかありません。開発者をアプリケーションセキュリティの中心に置くことです。

GitHub は、開発者を優先し、最も効率的に機能するツールを提供することにより、ソフトウェアの安全性を高めるという責任を果たします。GitHub は、コミュニティ主導型アプローチで安全なソフトウェアを作成し、開発者から来ることが多いフィードバックに早期に対処します。また、研究者が検索機能を強化できるようにし、クラウドソーシングによるバグ報奨金テストプログラムを実施します。プロセス内で摩擦を引き起こす複数のツールに依存する代わりに、GitHub は開発者のワークフロー内に統合されたネイティブな自動化ソリューションを提供します。セキュリティリスクに早期に対処し、脆弱性の修正を自動化して、アプリケーションを構築および保護する優れたセキュリティガバナンスを実現できます。

パ ート3：G I T H U B で 実 現 す る 開 発 者 ファースト の ア プ リケ ー ション セ キュリティ

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 2 6

GitHub を使ってプロジェクトのセキュリティを高める方法

1. セキュリティを念頭に置いて開始するプロジェクトを実装する前にセキュリティ要件を確認し、潜在的なリスクを特定することは、高いコストがかかる脆弱性の修正を防止する重要なステップです。これを実践する方法を以下に示します。

プロジェクトの設定にセキュリティのベストプラクティスを適用する

プロジェクトをセキュリティのベストプラクティスと一致するように設定すると、多くの問題を回避できます。アカウントとアクセスの設定 ( 役割と責任、2 要素認証、SSH 経由の git、チーム管理、統合、プロジェクトなど )を確認し、SECURITY.md の脆弱性開示とレポートポリシーを設定することは、非常に効果的です。

プロジェクトの脅威をモデル化する

ソフトウェア脅威のモデル化は、プロジェクト内の潜在的な脅威、脅威アクター、脆弱性のあるコンポーネントの特定に役立つ一連のアクティビティです。脅威のモデル化では、ソースやシンクなどのライブラリー APIを介してビジネスロジックと機密データのフローを分析する必要があります。ソースはデータを取り込むコードの一部であり、シンクはデータフローを完了させるコードの一部です。

CodeQL は、業界をリードするセマンティックコード解析エンジンであり、データのようにコードをクエリーできます。これにより、不正パターンを簡単に発見し、コードベース全体で同様のパターンが発生している箇所を容易に見つけることができます。CodeQL の適応脆弱性モデリング機

パ ート3：G I T H U B で 実 現 す る 開 発 者 ファースト の ア プ リケ ー ション セ キュリティ

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 2 7

能は機械学習技術を自筆の JavaScript セキュリティクエリーと裏で半自動的に組み合わせることで脆弱性をより広く検知し、汚点定義を向上させています。汚点定義はソースやシンクというライブラリAPI の役割を担っており、情報の流れで脆弱性を特定しようとするコード汚染解析ツールに欠かせない部分になります。その後、強化されたクエリーは、確認用に、ランク付けされた結果リストを生成します。継続的に脅威をモニタリングするモデルを使用すると、JavaScript および TypeScript クエリーにより、さらに多くのセキュリティ問題が特定されます。たとえば、GitHub Security Labでは、50 件の JavaScript プロジェクトで 118 件の NoSQLインジェクションの新しい脆弱性を検出できました。

静的スキャンをカスタマイズする

カスタムクエリーは、標準のルールやクエリーセットでは対応できないセキュリティ問題を検出します。これは、静的なアプリケーションセキュリティテストソリューションにおける強力な手段となります。標準のクエリーセットで対応できない問題は、そのコード特有であったり、またはコンテキスト内の問題と見なされるパターンに固有である可能性があります。CodeQL を使用すると、SQL のようなクエリー言語でカスタムルールを簡単に追加できます。また、CodeQL エンジンを構成して、プロジェクトが存続している間に静的スキャンの標準クエリーセットとカスタムクエリーが実行されるようにすることもできます。

2. 開発プロセスのすべてのステップを保護する従来型のセキュリティアプローチでは、ソリューションによって開発者が問題を早期に発見して修正できない場合、失敗する可能性が高いことが示されています。また、プロジェクトの脆弱性を定期的にスキャンしても、技術的負債の増加を止められないこともわかっています。その結果、技術的負債が増大し続け、チームの他の問題と共にセキュリティ上の欠陥を引き起こします。

パ ート3：G I T H U B で 実 現 す る 開 発 者 ファースト の ア プ リケ ー ション セ キュリティ

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 2 8

GitHub は、開発プロセスのすべてのステップに対し追加のセキュリティコードレビューを提供します。開発者は、サプライチェーンおよびコードセキュリティ機能 ( 脆弱な依存関係に対する Dependabot アラート、シークレットスキャンなど ) を使用して、開発ワークフロー内でセキュリティフィードバックを取得できます。

サプライチェーンを保護する

ソフトウェアサプライチェーンには、開発から CI/CD パイプラインを通して本稼働に至るまで、コードベースに含まれる、またはコードベースに影響を与えるすべてのものが該当します。サプライチェーン内の至る所に、ソフトウェアの依存関係があります。プロジェクトでは通常、自分で記述していないオープンソースの依存関係を使用します。Sonatype の「2019 State of the Software Supply Chain Report (2019 年ソフトウェアサプライチェーン状況レポート)」では、企業のコードベースの 85 ～ 97 パーセントでオープンソースが使われていると報告されています2。

依存関係に脆弱性がある場合、アプリケーションにも脆弱性がある可能性があります。何千人ものオープンソース開発者の仕事を活用できるということは、何千人もの見知らぬ人があなたの運用コードを効果的に制御できるということです。サプライチェーンに対する故意でない誤りと悪意のある攻撃はどちらも、コードベースに広範な影響を及ぼす可能性があるため、セキュリティは予防的かつ対処的なものになっていきます。ソフトウェアサプライチェーンの保護は、環境内の状況を把握し、依存関係を管理して、サプライチェーンを監視する継続的なプロセスです。

依存関係グラフ、インサイト、Dependabot

開発者は、依存関係グラフ、依存関係に関するインサイト、

パ ート3：G I T H U B で 実 現 す る 開 発 者 ファースト の ア プ リケ ー ション セ キュリティ

-------- 2: 「2019 State of the Software Supply Chain Report (2019年ソフトウェアサプライチェーン状況レポート)」、Sonatype

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 2 9

Dependabot アラート、Dependabot セキュリティアップデートなどの機能を使って、使用している依存関係を簡単に確認し、修正を含む Pull Request を開いて自動的に解決することができます。依存関係を確認すると、Dependabot アラートにより、新たに発見された脆弱性の影響を受けるリポジトリが通知されます。これを実行するため、GitHub は依存関係グラフの情報とGitHub Advisory Database の情報を比較します。Dependabot アラートは、新しい依存関係を追加したときに送信することも (GitHub がその依存関係の脆弱性をチェック )、新しい脆弱性が発見されたときに送信することもできます (GitHub から脆弱性のあるリポジトリにアラートを送信 )。デフォルトでは、アラートはリポジトリオーナーに送信されます。

Dependabot セキュリティアップデートでは、既知の脆弱性を解決する最小バージョン、つまりパッチを適用した最初のバージョンに依存関係を更新するよう Pull Request を送信します。ロックファイルに対して提案されたその変更は、アラートに基づいて自動的に行われます。

コードを保護する

カスタムコードは、プロジェクトにアプリケーションロジックと独自の機能を提供します。カスタムコードは、プロジェクトチームの開発者またはベンダーが開発します。プロジェクト内のカスタムコードを保護することは、安全なソフトウェアを出荷し、潜在的なゼロデイ脆弱性を防ぐための重要なステップです。

GitHub Code Scanning

GitHub Code Scanning は、GitHub に組み込まれている開発者ファーストの SAST 製品です。設定後は、リポジトリ内のすべてのコード変更をスキャンしてセキュリティの脆弱性を検出し、開発者ワークフロー内にフラグを立てます。これにより、本稼働に至る前に、コード内のセキュリティの脆弱性を簡単に見つけることができます。

パ ート3：G I T H U B で 実 現 す る 開 発 者 ファースト の ア プ リケ ー ション セ キュリティ

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 3 0

GitHub Code Scanning を有効にすると、すべての「git push」で新しい潜在的なセキュリティ脆弱性がスキャンされ、結果が Pull Requestに直接表示されます。デフォルトでは、GitHub Code Scanning はCodeQL を使用します。CodeQL には、実際の脆弱性を検出するための他にはないレコードがあります。これには GitHub Security Lab と主要なセキュリティ研究者が記述してオープンソース化した 2,000 件以上のCodeQL クエリーが含まれており、最小限の構成でコード内の潜在的な脆弱性を検出します。

また、GitHub Code Scanning を拡張して、Anchore Container Scan、RuboCop Linting、ShiftLeft Scan、Open Source Static Analysis Runner (OSSAR) など、他の商用およびオープンソーススキャンテクノロジーを組み込むこともできます。こうすることで、複数のオープンソースセキュリティ静的分析ツールなどを実行できるようになります。

シークレットスキャン

GitHub は 2018 年より、API キーや認証トークンを含む、パブリックリポジトリのシークレットスキャンを提供しています。シークレットスキャンは、トークンで保護されたサービスの不正使用からパートナーとコミュニティを保護します。

GitHub Advanced Security の一部として、プライベートリポジトリに対しても超高速スキャンエンジンと幅広い27 社のパートナーを導入しており、トークンをスキャンできます。対応するトークンはすべての主要クラウドプロバイダーと多くの一般的な SaaS プロバイダーが含まれており、そのリストは増え続けています。リポジトリ管理者にはトークンを含むすべてのコミットが通知され、検出されたすべてのシークレットをリポジトリのセキュリティタブですぐに確認できます

GitHub Actions を利用したサードパーティのセキュリティ機能

GitHub Actionsを使うと、コーディングを行うのと同じ場所で、ソフトウェ

パ ート3：G I T H U B で 実 現 す る 開 発 者 ファースト の ア プ リケ ー ション セ キュリティ

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 3 1

ア開発ワークフローを自動化、カスタマイズ、実行できます。他の人が作成した GitHub Actions を探したり、自分で作成したり、共有して、CI/CD を含む任意のジョブを実行できます。Actionsで完全にカスタマイズしたワークフロー作成することができます。個々の Actions はコードとして再利用できるため、ソフトウェアの場合と同様に、何百万もの他の開発者やセキュリティチームの集合知を簡単に活用できます。

GitHub Actions は、サードパーティのセキュリティツールと簡単に統合できるオープンプラットフォームとして機能します。現時点で統合されているものには、OWASP ZAP (Baseline Scan と DAST の Full Scan の両方をサポート)、SonarCloud Scan、Snyk など、多数あります。

3. コラボレーションを改善し、継続的にセキュリティフィードバックを取得するセキュリティを GitHub の開発者ワークフローの不可欠な部分にすると、個々のチーム、企業全体、コミュニティのすべての人が安全にコラボレーションできるようになります。

開発のすべての段階でセキュリティチームと協力する

Pull Request レベルでセキュリティ情報を取得することにより、開発者は適切なコンテキストとタイミングでフィードバックを早期に得られるため、コードの同じ部分で作業している間にセキュリティ問題を修正できます。また、セキュリティ問題に関する豊富な情報を確認できるため、セキュリティチームはコードが作成された場所と時間を GitHub に入力し、トリアージおよび修正プロセスの一端を担うことができます。開発チームとセキュリティチームが連携すると、問題をより効率的に優先順位付けし、最適な修正について話し合い、協力して結果を検証できます。

パ ート3：G I T H U B で 実 現 す る 開 発 者 ファースト の ア プ リケ ー ション セ キュリティ

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 3 2

開発者、セキュリティチーム、コミュニティ間でコラボレーションする

開発チームとセキュリティチーム間のコラボレーションの増加と CodeQLのカスタマイズ可能な性質により、各チームは既存の CodeQL クエリーを最大限に活用し、プロジェクトのニーズに対応する新しいクエリーを作成できます。開発チームはクエリーに必要なものを具体的に特定できる一方、開発チームのセキュリティ担当者やセキュリティチームは、既存のCodeQL クエリーをカスタマイズしたり、新しいクエリーを作成したりすることができます。カスタマイズしたクエリーを作成したら、企業全体で共有できます。チームは、コミュニティで使用できるよう、オープンソースのクエリーセットにクエリーを提供することもできます。

プロジェクトのセキュリティの脆弱性についてコミュニティに警告することは、セキュリティチーム、セキュリティ研究者、開発者、およびコミュニティが協力できるもうひとつの方法です。GitHubでネイティブにセキュリティアドバイザリを公開して、プロジェクトを使用するすべてのユーザーにすばやく通知し、問題修正プロセスをすぐに開始することができます。GitHub は、公開された各セキュリティアドバイザリを確認して GitHub Advisory Database に追加します。また、セキュリティアドバイザリを使用して、影響を受けるリポジトリに Dependabot アラートを送信する場合もあります。

コミュニティ内でコラボレーションする：コミュニティ 主導型アプローチ

GitHub Code Scanning を強化する標準の CodeQLライブラリーとクエリーはオープンソースなので、Pull Request を開くだけで誰でもレビューや投稿が可能です。GitHub のセキュリティ機能はオープンソースであるため、クエリーを投稿またはレビューすると、私たち全員が使用しているソフトウェアのセキュリティ保護にも役立ちます。

パ ート3：G I T H U B で 実 現 す る 開 発 者 ファースト の ア プ リケ ー ション セ キュリティ

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 3 3

まとめ

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 3 4

これは誇張ではありません。オープンソースソフトウェアは世界を変えています。現在、革新的なアプリケーションの多くは、誰もが自由にアクセスして貢献できるコードに基づいて構築されています。増加の勢いを増し続けている現在のコード、および技術的負債に対処する唯一の方法は、オープンソースチームが共有プロジェクトでコラボレーションするのと同様に、協力してセキュリティの問題を解決することです。コミュニティ主導型セキュリティは、セキュリティの専門家が学んだ教訓を共有し、今日のアプリケーションセキュリティの問題を解決する、より良い方法を提供するのに役立ちます。

また、開発者に焦点を当てた、コミュニティ中心のセキュリティは、問題を早期に発見して修正できると同時に、企業およびオープンソースコミュニティとのコラボレーションを改善できます。大規模なソフトウェアエコシステムを最新の状態に保ちたい、または最新の脅威を認識したいかに関係なく、GitHub を利用すれば、すべての人にメリットと力をもたらす、セキュリティのベストプラクティスの開発に貢献できます。

まと め

開 発 者 ファースト の ア プ リケ ー ション セ キュリティ 完 全 ガ イド 3 5G i t H u b 作 成

アプリケーションセキュリティの疑問をお寄せください。詳細はこちら：github.com/learn/security またはセールスチームにお問い合わせください。