GitHub Advanced Security を試す方法

このガイドでは、GitHub Advanced Security とは何か、そしてその仕組みについて学びます。また、その主な機能の 1 つであるコード スキャンと、それが組織内のすべてのチームにどのようなメリットをもたらすかについてもご紹介します。

GitHub Advanced Security とは何ですか?

GitHub Advanced Security は、組織におけるアプリケーション セキュリティの認識および実装方法を刷新し、変革する開発者ファーストのアプリケーション セキュリティ ソリューションです。GitHub Advanced Security のエコシステムには、3 つの基本機能があります。

Gray circle with lock shield in the center

コード スキャン

静的アプリケーション セキュリティ テスト (SAST) を使用して、コードが本番環境にデプロイされる前にコード内のセキュリティ問題を発見して修正します。 機能を確認する

Gray circle with lock shield in the center

シークレット スキャン

シークレットの発見後、すぐに通知が行われる既知のシークレット フォーマットのリポジトリを監視することで、許可されていないアクセスおよび違反を妨ぐことができます。 機能を確認する

Gray circle with lock shield in the center

依存関係のレビュー

コード ベースに依存関係を追加する前に脆弱な依存関係を検出します。 機能を確認する

以下のマトリクスは、試用期間中に無料で利用可能な機能を示しています。これは、プライベート リポジトリを使用しているか、パブリック リポジトリを使用しているかにより異なります。

Free features during your trial

上記から分かるように、パブリック リポジトリでは、コード スキャンと依存関係のレビューが完全に無料で利用できます。第一に、多くのお客様はコード スキャンの試用に関心をお持ちです。まずは、コード スキャンの能力と機能をテストしてみましょう。シークレット スキャンが提供する完全な機能セットを試してみたいという場合は、ボタンがある場所のフォームを使用していつでもご連絡ください。

コードスキャンと CodeQL を有効にする方法

コード スキャンは、開発者ファーストの GitHub ネイティブなアプローチで、セキュリティの脆弱性を簡単に発見することができます。世界で最も強力なコード分析エンジンである CodeQL を搭載しており、作成されたコードをスキャンして、プルリクエスト内で実用的なセキュリティ レビューを表示します。

これを試すには、既に使用しているパブリック リポジトリで行う方法と、プログラミング言語に基づいたサンプル リポジトリで行う方法の 2 つがあります。

オプション 1: 管理しているオープン ソース リポジトリでコード スキャンをテストする場合。

コード スキャンは、すべてのパブリック GitHub リポジトリで無料で実行できます。オープン ソース ライブラリや使用済みのコードを含むその他のアクティブなパブリック リポジトリを管理していますか? 今すぐセットアップする方法をご紹介します。

  • リポジトリの [設定] にアクセスします。

  • [コードのセキュリティと分析] タブを選択します

  • [コードスキャン] セクションで、[CodeQL 分析] の横にある [設定] ドロップダウン メニューをクリックし、[デフォルト] を選択します

  • [CodeQLを有効にする] をクリックします

  • 正常に実行されたら、[セキュリティ] タブをクリックします。次に [コード スキャン アラート] の横にある [アラートを表示] をクリックし、CodeQL がコードの脆弱性を発見したかどうかを確認します

図 1: リポジトリでコード スキャンを有効にする方法を示す画像。

注: コード スキャンを完全にテストするには、管理者権限が必要です。

オプション2: GitHub が構築したサンプル リポジトリでコード スキャンをテストする場合。

パブリック リポジトリをお持ちではありませんか? 持っていなくても大丈夫です。GitHub は 5 つのリポジトリを管理しており、これらのリポジトリでは簡単なコード スキャンの例についての説明が表示されます。CodeQL は、コンパイルされた言語をインタープリタされた言語とは若干異なる方法で処理します。抽出は、コンパイルされた言語の標準的なビルド プロセスを監視することで動作します。

言語別のサンプル リポジトリ

  • コード スキャンのためのチュートリアル (JavaScript)

  • コード スキャンのためのチュートリアル (Java)

  • コード スキャンのためのチュートリアル (C#)

  • コード スキャンのためのチュートリアル (Python)

  • コード スキャンのためのチュートリアル (Go)

もっとお試しになりたいですか?

上記のオプションではコード スキャンの基本的な知識を得ることができますが、学べることはまだたくさんあります。引き続き以下を読んでいただければ、さらに多くの機能をテストしたり、より複雑なユースケースを確認したりできます。

Juice Shop を使用したアクションでのコード スキャン

最初のスキャンの実行は始まりにすぎません。チームの柔軟性を最大限に高めるため、コード スキャンは GitHub Actions ワークフロー、または継続的インテグレーション/継続的デリバリー環境とも統合されます。1 つのリポジトリ内で脆弱性のデータフローを確認し、偽陽性をすばやく排除し、その他の日常的なセキュリティ タスクを完了できます。

例として、Juice Shop リポジトリの使用方法を見ていきましょう。

手順 1: リポジトリをフォークする

前のチュートリアルに従い、Juice Shop リポジトリをアカウントにフォークして、コード スキャンを構成します。

手順 2: GitHub Actions を有効にする

ワークフローはフォークされたリポジトリ内にあるため、それらは有効にしない限り実行されることはありません。[アクション] タブに移動し、以下のスクリーンショットに表示されているボタンをクリックして、ワークフローを有効にします。

図 2: フォークされたリポジトリの GitHub Actions を有効にする方法を示すイメージ

手順 3: スキャンを実行する

リポジトリの README.md ファイルに小さな変更を加え、ワークフローをテストします。その後、既定のブランチに変更をコミットします。スキャンの完了後、[セキュリティ] タブでは新しい通知を 50 件確認できます。

手順 4: アラートを確認する

次に [セキュリティ] タブをクリックして、コード スキャン アラートのページに移動し、その後 [コード スキャン アラート] をクリックします。

この API を使用すると、プログラムでコード スキャンを有効または無効にできます。この API は、大企業向けに大規模にコード スキャンを導入する際に便利です。

図 3: コード スキャン アラートを見つける方法を示すイメージ

アラートをクリックすると、次のページが表示されます。

図 4: コード スキャン アラートのページを示すイメージ

このページには、最新のスキャンデータ、検索機能、アラート ビューの 3 つのコア セクションがあります。

  • 最新のスキャンデータ - 上部のカードには、最新のスキャンに関するデータがあります。これは、前回の実行に関するデータを見つけることができる、迅速かつ簡単な方法です。

  • 検索 - メタデータを基づいて特定のアラートを探すためのフィルター可能で簡単な検索メカニズムです。

  • アラート ビュー - リポジトリの既定のブランチ内で見つけることができるリスト形式のすべての結果です。

コード スキャンの結果を理解する

自動化ツールでセキュリティ スキャンの結果が生成される際、それらに対処し、修正を行うかどうかは開発者次第です。そのため、開発者ファーストのツール導入は重要であり、GitHub コード スキャンの結果は開発者を念頭に置いて構築されています。表示される情報により最初に対処すべき項目が優先順位付けされ、脆弱性の修正方法が示されます。

結果の検索およびフィルタリング

リポジトリの既定のブランチ内で見つけることができるすべてのアラートを表示する規定ビューです (通常はメイン)。ヘッダー内にある検索またはフィルターのオプションを使用して、ニーズに合わせて結果を絞り込むことができます。

特定のアラートへのディープ ダイビング

特定のアラートに関する詳しい情報については、アラート名をクリックし、詳細ビューでそれが何であるか、およびその修正方法を確認できます。タイムライン ビューで、最初にアラートが見つかった場所や、現在のアラートの場所を確認することもできます。

GitHub Advanced Security がワークフローに与える影響

セキュリティはチームの責任です。「セキュリティのシフトレフト」としてよく知られていますが、脆弱性からコードを保護するには、ソフトウェア開発ライフサイクルのあらゆる段階で関与しているチームの意見が必要です。コード スキャンと GitHub Advanced Security を使用することで、開発者、セキュリティ担当者および管理者は、有意義な方法で結果から学び、それについて決定を下すことができます。

以下では、セキュリティ チームのメンバーから開発者、プロダクト オーナーまで、組織における特定の役割のために設計されたタスクを実行することで、コード スキャンの多くの機能について把握できます。さまざまなユースケースをご覧ください。現在の役割とは関連がなくても、それらから学べる内容に驚くことでしょう。

セキュリティ チーム向けコード スキャンの例

私はセキュリティ監査者として、すべてのコード スキャン アラートを SQL インジェクションのみにフィルタリングしようと思います。その後、特定の SQL インジェクションの詳細で、対象のアラートのタイムライン履歴を調べます。検索しているデータは、アラートがコミットされたタイミング、コミットした人物、そして脆弱性が警告されたか変更された場所です。これにより、時間と共に発生し得る影響の評価が行えます。- セキュリティ監査者

検索機能を使ってみましょう。[ルール] をクリックして、'コードインジェクション'を検索します。

図 5: ルールでフィルターする方法を示す画像

返されたアラートのいずれかをクリックすると、この画面が表示されます。

Image showing a specific alert

図 6: 具体的なアラートを示す画像

これは、アラートに関するすべての情報が表示されるページです。このステップでは、特に重要な情報は最下部にあります。

Showing the timeline/alert audit history

図 7: タイムライン/アラートの監査履歴を示す画像

この機能により、脆弱性が最初に検出された場所と、それにコミットした人物のタイムライン ビューあるいは監査履歴が提供されます。(これにより、脆弱性の履歴とそれにコミットした人物を追跡できるようになります。) いずれかのユーザーがこの脆弱性を取り込んだ場合は、それをブランチ内で警告するかプッシュ アップすると、それに応じてタイムラインが更新されます。

アラートをレビューするセキュリティ エンジニアとして、ユーザー提供の値のデータ フローをソースからシンクまで確認したいと考えています。これにより、この脆弱性の真の (肯定的あるいは否定的な) 性質を理解することができます。- セキュリティ エンジニア

ソース、シンク、およびユーザー提供のパスを、単一のアラート ページから見つけることができます。開始するには、[パスの表示] ボタンをクリックします。

Image showing how to find the show path button.

図 8: [パスの表示] ボタンを見つける方法を示す画像。

次のようなポップ アップが表示されます。

Image showing the source/sink pathway

図 9: ソース/シンクのパスウェイを示す画像

完了しました! ここからは、データが入ってくる上部のソースと、データが実行されるシンクを確認することができます。異なるステップ間をスクロールすると、実行までのパスウェイ表示されます。その SQL インジェクションが、考慮するべき対象なのかどうかを、確認することができます。また、このステップではユーザーの入力を正確に表示します。図 9 の中で、[ユーザー提供の値] のハイパーリンクをクリックします。これで、入力値の正確な場所が表示されます。

開発者向けコード スキャンの例

私はジュニア デベロッパーの立場で、SQL インジェクションについて詳しく知り、それを修正する方法についてより良く理解したいと考えています。ジュニア デベロッパー

1 つの詳細なアラート ページから移動せずに、SQL インジェクションについての詳しい情報を見つけ出してみましょう。

[詳細を表示] をクリックします。

Image showing user how to see more information about an alert

図 10: アラートに関する詳細情報を確認する方法をユーザーに示す画像

完了しました。必要な作業はこれですべてです。ここでの目的のすべては、潜在的な脆弱性について開発者が学ぶのを助けることです。この問題に初めて接した開発者は、以下の点を知りたいと思うでしょう。

  • 脆弱性の概要

  • 脆弱性へのアプローチに推奨される方法

  • 脆弱性の修正方法の例

  • 外部リファレンス

このすべての詳細は、上記で展開された画像内の要約の中で提供されています。

私は開発者の立場で、テストからのアラートである結果を素早く突き止め、それらを終了済としてマークし、ソース コードに関連するアラートに注目したいと思っています。- 開発者

このトピックは、いつの時も話題になります。「脆弱性」が見つかりました。ただし、テスト ファイル内でのことです。まず、ホーム画面に戻り、すべてのアラートを見ます。この画面は、次のようなものです。

Image showing code scanning alerts page

図 11: コード スキャン アラートのページを示すイメージ

ルールによりフィルターを実行しますが、ここでは、ハードコードされた資格情報でフィルタリングします。これにより、ハードコードされた資格情報を示す脆弱性がすべてリスト化されます。テストで発見された脆弱性には (テスト) がプレフィックスされるので、すぐにそれを見つけることができます。次の例をご覧ください。

Image showing a vulnerability found in a test.

図 12: テストで見つかった脆弱性を示す画像。

これらの脆弱税のいずれかをクリックします。[却下] > [テストで使用] ボタンを 1 つあるいは複数クリックします。対象の脆弱性が自動的に閉じられます。

Image showing how a developer can mark a code scanning result as closed.

図 13: 開発者がコード スキャンの結果を終了としてマークする方法を示す画像。

この操作は簡単です。開発者はページを開いて脆弱性がテストによるものかを確認した後、それを打ち切るだけです。脆弱性に対しては、同様のアプローチを使用して、[修正されない][偽陽性] としてマークすることも可能です。

注意点:

  • [テストで使用] をクリックした後、アラート ページの最下部にある、タイムライン/監査の履歴を見てください。このイベントに関する情報で、この箇所が更新されている場合があります。

  • [テストで使用] ボタンをクリックすると、コード スキャン アラートの webhook が起動します。これはどのような意味ですか? 特定のユーザーのみにコード スキャン アラートを終了させたいのであれば、対象の webhook イベントでコードを実行し、終了させたユーザーをチェックすることができます。このユーザーが承認リストにある GitHub ハンドルでなかった場合には、このアラートを自動的に再開できます。(これは、タイムライン上でも更新されます。)

追加の手順

  • 大きな 1 つのリポジトリ全体で、上記の操作を手動により行うのは、やや面倒なことがあります。その場合は API を使用しましょう。すべての結果を取得するには、コード スキャン API を使用します。ルール ID の Hard-Coded Credentials と一致するアラートでフィルタリングし、そのファイル名を調べます。その名前が「tests/」で開始しているのであれば、「コード スキャン API を更新する」に従い自動的に終了することができます。

  • これは JavaScript プロジェクトなので、codeql-analysis.yml ファイルを作成して、そのファイルにパスを無視するセクションを追加できます。これにより、テスト ディレクトリが無視されます。このファイルをプッシュ アップし、対象のフォルダーで、フラグが付いていない検出結果を監視します。

私は開発者の立場で、リポジトリのリスク レベルについてのスキャン タイプを調整し、高いリスクと低いリスクのリポジトリ を同じレベルで実行しないようにしたいと考えています。- 開発者

特に github/codeql-action/init@v1 アクションにおいて、github/workflows/codeql-analysis.yml ファイルの中で構成が指定されていない場合には、デフォルト セットのクエリが実行されます。これはどのような意味ですか?

サポートされるすべての CodeQL の言語には、3 つのパック (標準 (セキュリティ)、セキュリティ拡張、セキュリティと品質) の標準セットが含まれます。

  • 標準

    特に他の指定がない場合、標準パックは、高精密で高精度のクエリを実行します。これは、返された結果が非常に精密で実用的であり、レビューの対象となることを意味します。ただしこれは、利用可能なすべてのクエリを実行するわけではありません。

  • セキュリティ拡張 

    これには、広範な (依然としてセキュリティーに注目した) クエリのセットが含まれますが、自分には適用されない検出結果も返されることがあります。このパックで実行されるクエリは、実用的な結果を返すことを目的にしており、依然として精密かつ正確ですが、すべてのチームに関連性があるわけではないシナリオまでもカバーしています。

  • セキュリティと品質

    セキュリティと品質パックでは、構文チェックツールが提供するものと同様のコード品質クエリの一部に加え、セキュリティ拡張に含まれるすべてのクエリが実行されます。このパックは、セキュリティだけでなくコード品質の結果にも関心を持つチームにのみ関連します。この目的は、リポジトリのニーズに対し実行されるクエリの種類を多様化することで、完全に異なるプロジェクトに対しては、同じ種類のスキャンを実行しないようにすることです。

注意点: クエリ パックを作成することには、多くの利点があります。アプリケーションの種類 (SPA、API など) に特有のクエリ パックを作成することも、SANS 25 か OWASP Top 10 からのクエリのみを含むパックを作成することもできます。このステップでは、クエリの正確性と精密性に基づいて、組み込みのクエリ パックを使用していきます。

私は開発者として、マークダウン ファイルへの変更時に、main と QA ブランチでのみセキュリティ スキャンが実行されるようにワークフローを構成し、必要のない結果を待つ時間の無駄を省きたいと考えています。- 開発者

標準的なセキュリティ ツールで最もフラストレーションの元となるのは、不必要なスキャニングです。これは、プルリクエストのリリースやマージを遅延させます。そのような場合には、GitHub Actions が活躍します。GitHub Actions は GitHub Advanced Security とのインテグレーションが容易なので、例えば特定のファイル タイプを無視するといった、スキャンの構成が簡単に行えます。それでは、マークダウン ファイルのスキャンを実行しないよう、.github/workflows/codeql-analysis.yml ファイルの内容を変更してみましょう。これは、開発者が一般に要求する構成でもあります。

ファイルの不必要なスキャンを回避するためのステップに従います。終了後は、次のようになります。

Image showing how you can configure GitHub Actions to ignore paths/file types.

図 15: パス/ファイルの種類を無視するように GitHub Actions を構成する方法を示す画像。

README.md に移動し、ファイルを変更します。キック オフされたワークフローが無いということは、スキャンが関連する変更のみに対し実行されていることを意味します。main ブランチだけが変更されているので、上記に加えて feature/123 というブランチでも変更を行ってみると、やはりワークフローはトリガーされません。

その他の構成向けの GitHub Actions 構文を確認する

開発者、そしてセキュリティ アドボケートとして、セキュリティ ポリシーを有効化し、適用することで、コードが組織の要件を満たすことを確実にしたいと考えています。開発者

コード スキャンの初期設定の後、ユーザーは標準機能を拡張するために、サードパーティ連携を構成することができます。例えば Advanced-Security-Compliance Action / Tool では、ユーザーがポリシーをコードとして定義することができます。

上記のアクションを .github/workflows/codeql-analysis.yml に追加する様子を確認してださい。追加することができるポリシー例の 1 つは、特定のライセンスを導入するプルリクエストをブロックするものです。コードの視点から創造性を活かすことで、ポリシーに起因して、何がビルドを合格とし何が不合格とするのかを指定することができます。

プロダクト オーナー向けのコード スキャン例

私はプロダクト オーナーの立場で、リリースでのセキュリティ体制を示す PDF レポートを生成し、内部的なリリース ドキュメントをサポートするエビデンスとして、これを添付できるようにしたいと思っています。プロダクト オーナー

PDF では、セキュリティ概要をサポート エビデンスとして公式ドキュメントに添付できます。そのため、大型の企業にとっては実用的です。GitHub Security レポート アクションを使用して PDF を作成するには、リリースが取り出されるリポジトリ内に新しいワークフローを作成し、リリースを作成し、公開される新しいレポートを確認します。それ以降は、必要とするサポート ドキュメントを取得できるようになり、自分が特定のセキュリティ必須要件に準拠しているかどうかを知ることができます。

プロダクト オーナー向けのコード スキャン例

私はプロダクト オーナーの立場で、リリースでのセキュリティ体制を示す PDF レポートを生成し、内部的なリリース ドキュメントをサポートするエビデンスとして、これを添付できるようにしたいと思っています。プロダクト オーナー

PDF では、セキュリティ概要をサポート エビデンスとして公式ドキュメントに添付できます。そのため、大型の企業にとっては実用的です。GitHub Security レポート アクションを使用して PDF を作成するには、リリースが取り出されるリポジトリ内に新しいワークフローを作成し、リリースを作成し、公開される新しいレポートを確認します。それ以降は、必要とするサポート ドキュメントを取得できるようになり、自分が特定のセキュリティ必須要件に準拠しているかどうかを知ることができます。

DevSecOps アーキテクト向けのコード スキャン例

私はサードパーティ セキュリティ ツールの管理者/アーキテクトとして、今使用しているサードパーティ ツールからの結果を GitHub Advanced Security にアップロードし、開発者が GitHub に留まったまま、複数のツール間を切り替える必要もなく、すべての結果を確認できるようにしたいと考えています。— DevSecOps アーキテクト

この例では、SARIF をサポートしているものであるなら、サードパーティ製の任意のセキュリティ スキャンまたはコード品質ツールを、好みによって使用することができます。つまり、現在のツールを 3 つか 4 つ、GitHub のコード スキャンと併せて使用できるということです。

思い浮かぶツールが既にありますか? SARIF を生成して、自分の標準的な手法でそれをエクスポートし、Upload SARIF API を使用してデータをアップロードします。GUI の中では、どのように表示されているのかを確認してください。

特定のツールを使用していないのであれば、GitHub Actions Marketplace に豊富なツールが用意されています。これというものが見つからない場合、例えば、Aqua Security Trivy アクションが使用できます。Trivy は、コード スキャンと簡単にインテグレーションできる、サードパーティ製のコンテナ ツールです。

スキャンが終了しデータがアップロードされると、結果をツールごとにフィルタリングできます。下のスクリーンショットに示すように、[セキュリティ] 内の [コード スキャン アラート] タブにもどり、[ツール] でフィルターをかけます。

Image showing how you can filter results by tools.

図 16: ツールで結果をフィルタリングする方法を示す画像。

ぜひお話ししましょう

このページで、GitHub Advanced Security の開発者ファーストのアプローチの概要を理解し、コード スキャンに取り組むのに必要な自信を得ていただけることを願っています。さらに詳細を知りたい場合や、GitHub Advanced Security の全ての機能をお試しになりたい場合は、以下のフォームに記入してセールス チームにお問い合わせください。

octocaptcha spinner