re:Invent 2024: AWSのSDLCセキュリティ強化 - Amazon Q DeveloperとInspector活用
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Amazon Q Developer, Amazon Inspector & AI remediation for secure SDLC (DOP213)
この動画では、AWSが提供するセキュリティツールを組み合わせて、ソフトウェア開発ライフサイクル全体のセキュリティを確保する方法について解説しています。Amazon Q Developer、CodeGuru Security、Amazon Inspectorなどのツールを活用し、開発段階からデプロイ後まで一貫したセキュリティ対策を実現する手法を紹介します。特に、GitLabとのパートナーシップによるMerge Request時のコードレビュー機能や、Lambda関数、EC2インスタンス、ECRコンテナイメージに対する継続的なセキュリティスキャン機能など、最新の機能についても詳しく説明しています。また、SBOMの生成やGitHub Actionsとの連携など、実践的な実装方法についても具体的に解説されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSのセキュアなソフトウェア開発ライフサイクル：概要と本日の議題
皆さん、こんにちは。私はEmil Lerchです。本日は、AWSが提供するツールを組み合わせて、ソフトウェア開発ライフサイクルのセキュリティを確保する方法についてお話しさせていただきます。Amazon Q Developer、Inspector、そしてCodeGuru Securityを活用することで、開発、デプロイ、本番運用の各段階でソフトウェアの問題を検出し修正するためのAIを導入することができます。私たちは、ソフトウェア開発ライフサイクル全体を通じて、セキュリティ態勢をいかに改善できるかに注目しています。私はAWSの開発ツール、特にQ Developerを専門とするPrincipal Go-to-Market Specialistです。本日は、AWSのPrincipal Development EngineerであるCasey Leeも同席しています。
本日は以下のような内容をカバーしていきます。まず最初に、ソフトウェア開発ライフサイクルとそこにセキュリティをどのように組み込むことができるかについて、皆さんと認識を合わせたいと思います。次に、Q Developerの概要についてお話しします。今週は多くの発表がありましたので、それらについても触れながら、Q Developerがソフトウェア開発ライフサイクル全体をどのようにサポートするかについてご説明します。その後、IDE内外でのコードセキュリティスキャンについて説明します。これは、コアとなる開発部分からCIシステム、ソース管理システム、そして本番環境へとコードを移行する際の話です。最後に、Caseyがデプロイ後のコードセキュリティ維持におけるInspectorの役割について説明します。
ソフトウェア開発ライフサイクルにおけるセキュリティの重要性
では、ソフトウェア開発ライフサイクルから始めましょう。お客様がコードを本番環境に移行するためのパイプラインを構築する方法は様々です。コードのアイデアを出し、具体的にやりたいことを明確にし、コードを書き、それをソース管理システムに入れ、そしてパイプラインでの測定、検査、テストを経て本番環境に投入します。これらすべては、特定の問題にどのようにアプローチし、アプリケーションで何を実現したいのかを計画する人的要素から始まります。セキュリティについて考える際、できるだけ左シフトしたいと考えています。スライド上では物理的に左側に位置していますが、ソフトウェアの要件を考える際には、セキュリティファーストの考え方で臨みたいと思います。
実際の設計、アーキテクチャ設計、開発を行う際にも、セキュリティを最優先に考えながら進めていく必要があります。ここでQ Developerが初めて重要な役割を果たします。要件収集、設計、そしてIDE内での直接的な構築の段階においてです。セキュリティの専門家の方々は、「これは開発者のラップトップ上での作業で、その環境を完全にコントロールできないし、会社のシステムや本番環境に入るコードが確実に安全であることを確認したい」とおっしゃるかもしれません。コードがラップトップを離れた後、本当にコントロールを取りたい部分であり、そこでこのプロセスの残りをサポートするツールが役立ちます。
コードはソースコードリポジトリに入り、その時点でセキュリティチェックを適用したいと考えます。CodeGuru SecurityとAmazon Inspectorは、ソフトウェアコンポジション分析、静的アプリケーションソフトウェア分析を支援し、私たちが書いているコードと、ライブラリや依存関係の観点で依存しているコードがその時点で安全であることを確認します。コードがソースコードリポジトリに入ったら、それを本番環境にデプロイしたいと考えます。このプロセスには、AWS CodePipeline、AWS CodeBuild、GitLab CI/CD、またはGitHub Actionsを使用することができます。
コードを取得してビルドし、デプロイするためのプロセスがあります。このプロセスはセキュアである必要があり、デプロイが完了しても終わりではありません。なぜなら、コードの作成中やパイプラインを通じてテストを行っていても、本番環境に入ってから新たな問題が発生する可能性があるからです。
ソフトウェアはライブラリに依存しており、それらのライブラリには後から脆弱性が発見される可能性があります。そのため、デプロイ後も継続的にコードをスキャンし、新しい脆弱性が発見された際にそれを把握できるようにしたいと考えています。ここで Amazon Inspector が役立ちます。継続的なスキャンを行い、セキュリティチームが監視できる中央管理インフラストラクチャを通じて発見事項を表示します。ここでは、セキュリティチームがそれらの発見事項を AWS Security Hub で確認している様子が分かります。
Amazon Q Developerの機能と活用方法
これが全体の概要で、この後の1時間は、それぞれの詳細について説明していきます。まず、コードの作成、アイデア出し、何を変更したいのか、どのように変更するのかを学ぶところから始めますが、ここで Amazon Q が活躍します。Amazon Q Developer の目標は、ソフトウェア開発ライフサイクル（SDLC）全体をサポートすることです。Q Developer については、IDEにおける多くの機能について話題に上がりますが、AWSの目指すところは、実際にはプロセス全体を加速することにあります。
これは、システムに加えたい変更や構築したい新しいシステムについて理解したときに、Q Developer が参加できる計画フェーズから始まります。ベストプラクティスを念頭に置いてアーキテクチャを設計し、詳細レベルの設計も同様にベストプラクティスに基づいて行う必要があります。AWS ドキュメントや AWS コンソール内で Q Developer を利用できるのは素晴らしいことです。なぜなら、コンソールには AWS アカウントとそこにあるインフラストラクチャのコンテキストがあるため、解決しようとしている問題に関連するアカウント固有の質問をすることができるからです。
この1、2週間で、Q Developer の課金に関する機能強化をリリースしました。インフラストラクチャの特定の部分について質問できるようになり、EC2インスタンス、コンテナ、Lambda の使用数を確認して、会社の他のソフトウェア開発との一貫したアーキテクチャを維持することができます。EC2を使用している場合、適切なインスタンスサイズの検討などにもこれを入力として使用でき、Q Developer はそのような活動もサポートできます。
コンソールの外では、私たちが目指す方向性を理解した上で、既存のコードを見てみましょう。新入社員かもしれませんし、新しいコードベースかもしれませんし、あるいは1年前に最後の変更を加えたコードベースかもしれません。そこで、何が起きているのか、どのようなパターンが使われているのか、ソフトウェアがどのように設計されているのかを正確に理解するためのリフレッシュが必要です。この段階で、Amazon Qを使用して詳細を掘り下げ、目の前にあるものを説明してもらうことで、変更を加える準備が整います。コード作成フェーズに入ると、Amazon Q Developerを使用する際は主にIDEで作業しますが、CLIを使用することもあります。CLIはその場で直接実行する方法についての提案を提供します。
Matt Garmanのキーノートで2日前に発表された機能がいくつかあります。その中には、/docコマンドでREADMEを作成する機能も含まれています。説明フェーズでは、READMEがないコードベースに対して使用したり、既存のREADMEの更新が必要な場合に使用したりします。私たちは、さまざまなスタイルでの作成をサポートする新機能を、Amazon Q Developerに継続的に追加しています。
IDEでコードを書いている際には、提案を受けることができます。IDE左側のチャットインターフェースを通じて対話形式でコーディングを行ったり、最近リリースしたインラインチャットを使用して質問をし、チャット会話をしている場所に直接挿入したいコードを取得したりすることができます。Amazon Q Developerでの機能開発では、チャットで/devコマンドを呼び出し、要件を提供することができます。要件を提供すると、コード、ドキュメント、テストを1つのユニットとして作成し、開発を加速することができます。これは、特に新しい機能やアプリケーションの開発を始める際に役立ちます。
コードができたら、テストを行い、セキュアであることを確認する必要があります。Amazon Q Developerは、セキュアなコードを書いているかを継続的にスキャンします。火曜日のキーノートで発表された新しいコマンド/testは、ユニットテストの生成に特化しています。Amazon Q Developerでユニットテストを作成する方法は複数あります：入力中のインライン提案、インラインチャット、IDE側面のチャット、またはプロジェクト全体のテストを生成するソフトウェア開発エージェントの使用などです。ユニットテスト生成機能はテスト生成に特化しており、コードが書かれた後でAmazon Qとやり取りする効果的な方法となっています。
テストが完了したら、この1時間後半でデモンストレーションされる予定の完全なコードレビューも行いたいところです。セキュリティと、混乱を招く可能性のある最適化されていないコードの両方をレビューします。コードの論理エラーを見つけ、さらに重要なことに、それらを修正するのに役立ちます。火曜日に発表されたコードレビュー機能を通じて報告された問題に遭遇した場合、そのインターフェース内で直接修正を生成できます。コードを書いてデプロイした後は、運用も必要です。Amazon Q Developerは、トラブルシューティングに役立ちます。多くの場合、コンソールで1つのEC2インスタンスが別のEC2インスタンスに到達できないような状況で、デバッグの支援を求めることができます。Lambda関数の実行に関する問題が発生した場合も、Amazon Q Developerがそこで修正を提案できます。
コンソール全体を通して、S3、EC2、EKSなどの様々な領域でサポートできるように、Amazon Q Developerが組み込まれています。
火曜日に、Amazon Q Developer Investigationsのプレビューを発表しました。Investigationsは、Generative AIの力を活用して運用ログを分析し、発生した運用上の問題の根本原因に関する仮説を提供できる機能です。運用担当者や、実行中のシステムを確認する開発者として、Investigationsを使用することで、本番環境で起きていることを素早く要約し、対応することができます。これは、お客様に大きな成果をもたらすことが期待される非常に強力な機能です。
さらに、運用中のコードを長期間使用している場合、新しいフレームワークやプログラミング言語のバージョンにアップグレードする必要が出てくることがあります。そこでQ Developerのトランスフォーム機能が役立ちます。現在、Java 8からJava 17へのTransformが利用可能で、火曜日には.NETコードをアップグレードするための機能がプレビューとして発表されました。これらは、Java 8からJava 17への移行のような差別化されない重労働を軽減し、時代とともにコードベースを迅速にアップグレード、保守、モダナイズできるよう、私たちがお客様に提供しようとしている機能の一例です。
Amazon Q Developerのコードレビュー機能：実践的なデモンストレーション
火曜日に発表した「slash review」について触れましたが、カンファレンスで皆さん忙しかったので、まだご覧になっていない方も多いかもしれません。これが実際の画面です。この例では、プロジェクトのレビューを実行した後、特定の問題を確認しているところで、Q Developerが発見した問題について詳細な情報を提供してくれています。これは私のコードではありません。いや、私のコードですが、GitHubにあるオープンソースプロジェクトのOpenSUUで、slash reviewを実行しました。実際にはそれほど多くの問題は見つかりませんでした。これは数バージョン前のもので、これらの問題の多くはすでに対処されていると思います。
このコードベースでQ Developer Reviewを実行したところ、いくつかの異なる問題が見つかりました。この例では、Android開発において、アプリケーションを起動する際にIntentを使用しますが、デフォルトのIntentが存在しない可能性があり、つまりnullの処理が行われていないということです。修正を生成することができ、これについては後ほどデモでお見せしますが、ここではQ Developer Reviewがこのコードベースで発見したすべての内容の要約を示していることが重要だと考えました。ここには、特定のチェックが欠けているといった決定論的な問題から、循環的複雑度（Cyclomatic complexity）が高すぎるといった問題まで、様々な指摘があります。この指標をご存知の方もいらっしゃると思いますが、これはコードの分かりにくさを測る指標です。多数のif文や条件分岐があると、開発者がコードを読んで変更を加えようとする際に混乱を招く可能性があります。Q Developerはこのような問題を検出し、最終的な目標を達成しながらもコードをよりシンプルにする方法を提案することができます。
コードの最適化とセキュリティの観点から、レビューではさまざまな点をチェックしています。左下にサマリーが表示され、中央にはコードベースが表示されています。Reviewが発見した特定の問題を強調表示するため、コードをそのまま残してあり、その詳細は右側に表示されています。このように、コードと詳細情報があり、Amazon Q Developerが発見した内容について明確な説明を読むことができます。
画面下部には、修正を生成するためのアクションボタンがあり、この問題への対処方法についてLLMから別の提案を得たい場合は、修正を再生成することもできます。また、後ほどお見せする動画の中で説明されているように、何が起きているのかをより詳しく説明することもできます。あるいは、これは問題ないと判断して承認する、つまりこの特定の問題を無視することもできます。
では動画をご覧ください。まず、プロジェクトはワークスペースに読み込まれていますが、何も開いていない状態です。ここでAmazon Q Developerとの対話を開始します。スラッシュコマンドを使用できるので、レビュープロセスを開始するために「/review」を使用します。プロジェクト全体をレビューするか、開いているファイルだけをレビューするか選択するように求められます。プロジェクト全体を見たいので、ワークスペース全体のレビューを実行するように指示します。この動画では一部時間を省略していますが、実際には数秒から1、2分ほどかかることがあります。
その後、先ほどのスクリーンショットで見たようなサマリーが表示され、いくつかの問題が示されます。その中の1つがリソースリークです。ここでは、データベースを開いて、数行下にcloseがありますが、その間に条件分岐があり、データベースを閉じずに関数から返ってしまう可能性があります。これがAmazon Q Developerが指摘している問題です。
何が起きているのか説明を求めると、チャットで問題全体の説明と対処方法が生成されます。まずリソース管理の概要と、なぜリソースを閉じることが重要なのかについての説明があります。そして、このデータベースオブジェクトの設計に応じて、リソースが確実に閉じられるようにするための複数の選択肢が提示されます。最後に、続けるためのキーポイントがいくつか示されます。開発者の学習を支援することが目的なので、今後コードを作成する際にこれらの点を念頭に置いておくことができます。
いくつかの異なる問題を見ていきましょう。これが最初に取り上げる問題です。これは、nullになる可能性のある私のintentです。先ほど見た別の画面が表示される詳細を表示して、修正を生成してみましょう。この部分は何もカットしていないので、この生成にかかる時間がそのまま表示されます。この場合は数秒しかかからず、修正案が表示されます。この時点で、修正を受け入れるか、無視するか、再生成するか、あるいはdiffを開いて「修正を受け入れる」をクリックした時に何が起こるかを正確に確認することができます。
黄色のハイライトは、追加が提案されている新しいコードです。この修正を受け入れて、ファイルを下にスクロールすると、確かにファイルが修正され、その特定の領域にnullチェックを追加する2行が新しく追加されているのが分かります。これがIDEにおけるAmazon Q Developerのレビューの様子です。しかし、火曜日に発表されたもう一つの重要なアナウンスメントについてまだ触れていません。これは、先ほど説明したSecure SDLCの観点から、ソース管理システム内でもコードレビューを開始できるようにしたいという理由で、Amazon Q Developerにとって画期的な発表でした。
GitLabとの統合：ソース管理システムでのAmazon Q Developer活用
GitLabとのパートナーシップにより、GitLab環境でAmazon Q Developerを利用できるようになりました。これにより、開発者やセキュリティアナリストなどのプロジェクトメンバーが、GitLab上で直接レビューを開始し、先ほど見たような体験ができるようになります。
このビデオは少し点滅があるので、光過敏症の方はご注意ください。これはGitLab環境で、Merge Requestを作成しているところです。この時点で、開発者がコードを書いてMerge Requestを発行しようとしています。GitLabに詳しくなくてもGitHubをご存知の方なら、Merge RequestとPull Requestはほぼ同じものだとご理解いただけると思います。このMerge Requestを作成すると、他のソース管理システムと同様に、そのMerge Requestにコメントを付けることができます。
ビデオを再生すると、Merge Requestにコメントを付け、そのコメントをAmazon Qに割り当ててレビューを依頼する様子が分かります。では再生してみましょう。Merge Requestを作成すると、このボタンをクリックした後に、Merge Request画面が表示されます。その画面にはアクティビティが表示され、Amazon Qにコードレビューを依頼することができます。スラッシュQと入力することで、Amazon Qサービスと対話を開始します。もう一度レビューを依頼して、コメントを投稿すると、しばらくしてQサービスからステータスについてのコメントが返ってきます。
ここでは、「リクエストを受け取りました」「コードをレビュー中です」「レビューが完了しました」「問題を発見しました」といったコメントがいくつか表示されます。この場合、SQLインジェクションの脆弱性が潜在的にあり、文字列の連結は避けて、PreparedStatementを使用すべきだということです。このような説明が提供され、プロジェクトチームの誰もがいつでも確認できるように記録されます。これはプロジェクトの履歴の一部となり、行われた全ての変更とその理由を追跡することができます。
Amazon Q Developerの評価に同意したので、もう一度Qを呼び出して修正をお願いすることにします。Qに修正を依頼すると、Qサービスが修正を生成し、Merge Requestに直接変更を提案してくれます。私たちはそれを確認して、受け入れるかどうかを判断できます。下にスクロールすると、先ほど見た文字列連結を削除するdiffが表示され、SQLのPreparedStatementを使用する新しいコードに置き換えられています。
PreparedStatementについてご存じない方のために説明すると、これを使用するとSQLインジェクション攻撃に対して脆弱性がなくなります。パラメータとしてuserIdに疑問符を使用し、その下のsetString文でuser変数をそのステートメントに割り当てています。これで問題なさそうなので、この提案を適用することにします。この時点で、Merge Requestを承認するか、人間によるレビューを続けるかを選択できます。
作成からソース管理システムへの取り込みが完了したら、そのコードをデプロイする必要があります。ここで、Amazon Q DeveloperからAWSが提供する他のコードセキュリティスキャンツールに移行します。主にCodeGuru Securityが、このセキュアなソフトウェア開発ライフサイクルの次のステージを担当します。
Amazon Inspectorによる継続的なセキュリティスキャン
CodeGuru Securityはこのプロセス全体に組み込まれています。先ほど見た図と同じですが、CodeGuru SecurityはAmazon Q Developerのレビューで使用されているコンポーネントの1つです。これは唯一のツールではありませんが、Amazon Q DeveloperがInspectorを使用するプロセスの一部です。AWS CodeBuild、AWS CodePipeline内のCI/CDパイプラインで直接使用できます。GitHub ActionsやGitLab CIを使用している場合も、CodeGuru Securityの統合方法が文書化されています。
コードの静的解析を通じて、開発ライフサイクル全体におけるこれらのセキュリティ脆弱性の完全な可視性を得ることができます。リポジトリやS3に存在する特定のコードに対してCodeGuru Securityを実行すると、AWS ConsoleのCodeGuruダッシュボードで検出結果を確認できます。その様子がこちらの画像です。コード内でハードコードされた認証情報が見つかっています。この時点で、その問題の詳細な説明を確認し、お好みのエディタに戻って問題に対処することができます。
CI/CDにおいて、異なる重要度レベルの検出結果に基づいてビルドをブロックすることができます。この例では、GitLab CIを使用しており、CodeGuru Securityのイメージを使用して、重要度レベルが「Critical」の場合にビルドを失敗させるように設定しています。これはテスト環境では非常に有用ですが、StagingやProduction環境では、このしきい値を調整したいかもしれません。例えば、Productionには「Medium」以上の脆弱性を一切プッシュさせたくないけれど、Stagingではそれを少し緩和して「Medium」は許可し、より重要度の高い脆弱性だけをブロックするといった具合です。CodeGuru Securityではこのような柔軟な設定が可能です。
コードを作成し、ソース管理システムでレビューを行い、パイプライン全体でセキュリティレビューを実施してProductionにプッシュするというプロセスを見てきました。Productionに移行したら、次はAmazon Inspectorについて話をしたいと思います。そのために、同僚のCasey Leeを招きたいと思います。Emilは、開発者のワークステーションやIDEで、開発ライフサイクルの早い段階でセキュリティを確保するための優れた手法を紹介してくれました。また、CI/CDパイプラインやソース管理システム内でのセキュリティ確保についても見てきました。これらは、ソフトウェアのデプロイと運用の準備が整っているという確信を得るための素晴らしい手法です。
しかし、ソフトウェア開発ライフサイクルはデプロイ時点で終わるわけではありません。むしろそこからが本番で、ソフトウェアの実行時間が最も長くなります。私たちが本当に必要としているのは、ソフトウェアが継続的にセキュリティ要件を満たし、脆弱性がないことを検証できる仕組みです。ここでAmazon Inspectorの出番となります。Amazon Inspectorは、アカウントや組織内のソフトウェアを継続的に監視し、脆弱性を探し続けるサービスです。新しい脆弱性は常に発見されており、デプロイ時点で脆弱性がなかったソフトウェアでも、数日、数週間、数ヶ月後には、インフラストラクチャで実行しているパッケージやソフトウェアが使用しているサードパーティライブラリに新たな脆弱性が発見される可能性があります。現在では、EC2、AWS Lambda、ECSやEKSのコンテナワークロードなど、あらゆるコンピューティング環境を継続的に監視できる機能を備えています。
これらすべてのケースで、Inspectorを簡単に有効化して設定することができます。ワークロードを実行する様々なコンピューティングリソースに対して、Amazon Inspectorを簡単に有効化して設定できます。組織やアカウントでこれを有効にすると、脆弱性が発見された際に明確なコンテキスト情報が得られます。リソースがどのアカウントのどのリージョンにあるか、そしてECRリポジトリのDockerイメージなのか、Lambda関数なのか、それともEC2インスタンスなのかといったリソースの種類も分かります。また、脆弱性の深刻度、脆弱性のあるパッケージの詳細、そして関連するCVEの詳細情報も得られます。
Amazon Inspectorが提供するもう一つの価値ある機能は、Software Bill of Materials（SBOM）を生成する機能です。私たちは、すべてのアカウントにわたるワークロード内に存在するこれらの依存関係をすべて把握したいと考えています。Inspectorを有効にすると、組織全体、特定のアカウント、あるいは1つのLambda関数や1つのEC2インスタンスといった特定のリソースを対象としてSBOMを生成するよう要求できます。SBOMは、SBOM生成の2大標準フォーマットであるCycloneDXまたはSPDXフォーマットで生成されます。OSパッケージとソフトウェアパッケージの両方のすべての依存関係が含まれます。例えば、Javaを使用している場合は依存しているjarファイル、JavaScriptを使用している場合はpackage.jsonの依存関係などが含まれます。
SBOMはお客様が所有するS3バケットに保存され、そのデータを分析することができます。一般的なパターンとして、QuickSightやAthenaなどを使用してこれらのSBOMファイルに対してクエリを実行し、特定のサードパーティの依存関係が組織のどこで実行されているかを確認することができます。気になるCVEに気付いた場合、生成したSBOMに対してクエリを実行することで、それらのリソースが組織内のどこで実行されているかを正確に把握できます。SBOMの生成はInspectorの使用に含まれており、追加料金はかかりません。
また、CI/CDパイプラインにInspectorのSBOM生成を組み込むこともできます。こちらはSBOMを生成する特定のジョブを含むGitHubワークフローの例です。まず、Inspectorが設定されているアカウントと通信するためにAWSクレデンシャルを設定する必要があります。AWSが提供・管理している事前パッケージ化されたconfigure AWS credentialsのGitHub Actionを使用しています。これはOpenID Connectを使用してアカウント内で管理しているロール（この場合はsample role）を引き受けており、そのロールがInspectorでスキャンを実行して脆弱性を送信するために必要なアクセス権を持っていることを確認する必要があります。
ジョブの次のステップでは、Amazon Inspector用のvulnerability scan GitHub Actionを使用してInspectorでスキャンを実行します。このアクションはコードを取得してInspectorに送信し、すべての依存関係を含むSBOMを生成して、ジョブの他のステップで利用できるようにします。このアクションには特定の設定があります。まず、artifact typeをrepositoryに設定し、このアクションが実行されている現在のGitリポジトリのすべてのコードをスキャンするように指定します。他のオプションとして、archiveを選択してzip、war、jarファイルなどの特定のファイルを指定したり、containerを選択してビルドプロセスで作成されたばかりのOCIイメージを指定したり、GoやRustを使用している場合はbinaryを選択してビルドしたばかりのバイナリを指定したりすることができます。GoやRustを使用している場合、ビルドしたばかりのバイナリを指定すると、そのバイナリのビルドに使用された依存関係のSBOMを生成できます。
もう一つの有益な機能は、脆弱性が見つかった場合にビルドを失敗させる機会を提供することです。critical、high、mediumのしきい値を1に設定しており、これはSBOM生成中に依存関係で1つ以上のcritical、high、またはmediumレベルのCVEが見つかった場合、その時点でビルドが失敗することを意味します。SBOMは取得できますが、ビルドは失敗してそこで停止します。他のステップでは、ログファイル内でレビューするためにSBOMを出力していますが、おそらく後で参照できるようにSBOMをより永続的に保存したいと考えるでしょう。このアクションの最後の注目すべき機能は、そのアクションの使用中に見つかったすべての異なる脆弱性を明確に表示するGitHubワークフロー内にアクションサマリーを生成することです。
それでは、組織内でInspectorを実際にどのように有効化するのかについて説明しましょう。まず大きな利点として、組織レベルでの設定が可能だということが挙げられます。すべてのアカウントにまたがる設定を一括で管理する委任アカウントを1つ用意することができます。そのアカウントから、Amazon EC2やAWS Lambda、あるいはECRを使用するECS上のコンテナサービスなど、スキャンしたいコンピュートリソースを選んで有効化できます。まずはEC2のケースから見ていきましょう。EC2でInspectorの継続的なスキャンを実行する場合、2つのオプションがあります。1つ目は従来型のエージェントベースのスキャンです。このモードでは、EC2インスタンスにSSM agentをインストールし、Amazon Systems Managerと接続してInventoryデータを送信するように設定する必要があります。これには、エージェントのインストールと稼働確認、SSMと通信するための権限を持つロールを含むインスタンスプロファイルの設定、そしてインスタンスとSSMサービス間のネットワーク接続の確保が必要です。
最近では、もう1つのオプションとしてハイブリッドスキャンモードが登場しました。これは、IAM権限の付与やネットワーク接続の確立、SSM agentのインストールを避けたいお客様のワークロードに特に有用です。Inspectorコンソールでハイブリッドスキャンモードを有効にすると、まずエージェントモードを試みます。すでにEC2インスタンスでエージェントが稼働している場合は、変更なしでそのアプローチを継続します。しかし、EC2インスタンスがSSMに登録されておらずInventoryデータを送信していない場合、Inspectorはエージェントレスモードにフォールバックします。このモードでは、InspectorがEBSボリュームのスナップショットを作成し、そのスナップショットに対してスキャンを実行します。スナップショットはお客様のアカウント内に留まり、スキャン完了後にクリーンアップされます。どちらのケースでも、Inspectorはインスタンス上のInventoryを継続的にスキャンします。新しいパッケージのインストールやInspectorサービスに新しいCVEが登録された場合、Inspectorは検出結果を作成します。
次に、ECSやEKSでコンテナワークロードを実行するためのOCIイメージを保存するサービスであるAmazon ECRについて説明しましょう。ECRでは、イメージをスキャンするための2つのオプションがあります。1つ目は、Inspectorとは別のECRに付属する基本スキャンです。基本スキャンの中でも2つのオプションがあります。長年使用されてきたオープンソースの実装があります。
これはオープンソースプロジェクトのClairに基づいていますが、より新しいAWSネイティブな基本スキャン方式も登場しています。これらはどちらもAmazon ECRに含まれており、現在利用可能です。ただし、これらはオペレーティングシステムレベルのパッケージのみをスキャンします。つまり、OCIイメージ内にパッケージをインストールした場合、基本スキャンのどちらのオプションでもそれらはスキャンされます。しかし、Java、Python、JavaScriptなどのプログラミング言語が依存するサードパーティの依存関係はスキャンされず、検出されません。
基本スキャンで実行できる頻度は2種類のみです。イメージを最初にプッシュしたときか、任意のタイミングで手動で実行するかのどちらかで、先ほど説明したInspectorのような継続的なスキャンはできません。そこで登場するのが拡張スキャンです。拡張スキャンでは、Inspectorコンソールで拡張スキャンを有効にすると、ECRリポジトリ内のすべてのイメージが、付属のスキャン技術ではなくInspectorによってスキャンされるようになります。Inspectorのスキャンは、オペレーティングシステムのパッケージとプログラミング言語が使用するサードパーティの依存関係の両方をスキャンします。
Inspectorでは、スキャン頻度に関して「continuous（継続的）」というオプションも用意されています。ECRリポジトリに対して、イメージが変更されたときや新しいCVEが登録されたときに継続的にスキャンを実行します。その際、Inspectorはイメージを再スキャンします。また、Enhanced Scanningでは、イメージのプッシュ日またはプル日に基づいて再スキャンの頻度を設定できる機能もあります。これにより、アカウント内での再スキャンの回数を制限することができます。例えば、過去90日以内にECRにプッシュされたイメージのみを再スキャンするように設定できます。同様に、過去1週間以内にプルされたイメージのみをスキャンするように設定することで、環境内で実際に使用されているイメージだけをスキャンすることも可能です。
最後に説明が必要なコンピューティングプラットフォームは、AWS Lambdaです。Lambdaにも、スキャン方式についていくつかのオプションがあります。これらのオプションは、組織全体でInspectorコンソール内で設定します。Standard Scanningは、Lambda関数のパッケージの脆弱性のみを検出します。これは、Lambdaの実行に使用するZIPファイルやOCIイメージの内部を調べ、ソフトウェアの依存関係におけるパッケージレベルの問題のみを検出します。一方、Standard Scanningを含むCode Scanningは、実際のソフトウェアのコードの脆弱性を検出します。例えば、先ほどEmileが示したSQLインジェクションの例は、サードパーティの依存関係の脆弱性のみを検出するStandard Scanningではなく、Code Scanningで検出されることになります。
アプリケーションにシークレットを注入したり、ハードコードしたりしている場合、InspectorはCode Scanningモードでそれを警告し、修正方法についてのアドバイスを提供します。両方のモードで提案が生成され、Code Scanningアプローチでは、Generative AIを使用して検出された問題を修正するためのソースコードの変更が提案されます。どちらの場合も、Inspectorは、Lambda関数を最初に作成したとき、新しいバージョンで関数を更新したとき、または新しいCVEやコード検出器がInspectorに登録されたときにスキャンを実行します。
Inspectorのもう一つの優れた点は、AWS Security Hubとの簡単な統合です。「簡単」というのは、組織でSecurity Hubを有効にしていれば、それだけで完了するということです。Inspectorは自動的に検出結果をSecurity Hubに送信します。この例では、Inspectorから送られてきた7つの検出結果がSecurity Hubに表示されており、4つのHighと3つのMediumの重要度が示されています。これにより、これらの検出結果の重大度と関連するCVEを確認することができます。
重要なコンテキストデータとともに、検出結果の追加詳細を確認することができます。このビューではアカウント番号は非表示になっていますが、アカウント情報を示す列があります。リージョンやリソースの種類（ECRイメージ、Lambda関数、EC2インスタンスなど）を確認することができます。これらの詳細情報を表示し、他のSecurity Hubの検出結果と同様にインシデントとして対処することができます。
また、SDLCが自身にフィードバックを与えるという観点もあります。Amazon Inspectorから生成されるGenerative AI駆動の推奨事項がその一例です。この例では、Pythonコードにハードコードされた機密情報があり、Amazon Inspectorがその認証情報をソースコードから分離して環境変数に置き換えるという変更を提案しています。このように、運用段階で生成された新しいコードが作成段階にフィードバックされ、ソフトウェアを継続的にセキュアに運用することができるのです。
セキュアなソフトウェア開発ライフサイクルの総括
私たちは、開発者のワークステーションという、できるだけ右側からSDLCのセキュリティ確保を始めたいと考えています。IDE内でAmazon Q Developerを通じて、開発者に早期かつ頻繁にフィードバックを提供することで、自分のラップトップ上のコードがセキュアであるという確信を持ってもらいたいのです。また、開発者のラップトップを離れたコードに対しては、CICDパイプライン内でGitリポジトリに対してCodeGuruやAmazon Inspectorなどのツールを使用してスキャンを行います。本日はGitLabやGitHubの例を見ましたが、CodePipelineとの連携についても説明してきました。
また、ソフトウェアの継続的なスキャンも重要です。SDLCはデプロイで終わるわけではなく、むしろそこからが始まりなのです。そのため、新たな脆弱性が検出され続ける中で、継続的にスキャンを行う必要があります。Inspectorは、そうした脆弱性の可視化だけでなく、コードの変更によって迅速に対処・解決するための推奨事項も提供します。さて、残り時間が少しありますので、この後5分ほど質疑応答の時間を設けたいと思います。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion