はじめに

おのやんです。

AWS Summit 2025で行われたセッションの中で、こちらを聴講してきました

セキュアなソフトウェア開発ライフサイクルのための生成 AI

近年、開発の現場ではセキュリティに対する意識が高まっています。しかし実際にソフトウェア開発ライフサイクル (SDLC) に、開発者の負担なく、開発サイクルの効率を落とさず、セキュリティを組み込むにはどうすればよいでしょうか。このセッションでは、Amazon Q Developer、Amazon CodeGuru、Amazon Inspector といったサービスをシームレスに SDLC に統合する方法を示します。そして SDLC を通じて脆弱性を開発の中で事前に特定して軽減し、コードから本番環境まで堅牢なセキュリティを確保する方法を学びます。

内容

本セッションで最初に主張されていたテーマがシフトレフトです。こちらのスライドの右側の段階ではなく、できる限り左側、つまりプロジェクトの初期段階(上流工程)でセキュリティ対策を行うことが望ましい、ということです。開発の後半にいくほどセキュリティインシデントが発生したときに面倒なので、最初の方に問題を見つけていきたい、という考えがベースです。

本セッションでは、Amazon Q Developer（Q Developer）を使って、開発時だけでなく要件定義時でもセキュリティ対策を入れることがオススメされていました。しかし、現実的には開発の中期〜後半の段階でも、突如ミドルウェアの脆弱性が見つかるなどの対応に追われることがあります。ここを考えると、全体でセキュリティについて考えることがいい、という流れですね。

開発サイクルにおけるPlanは、開発者がセキュリティを意識しつつ設計することを指します。AWSコンソール内のQ Developerは、AWSアカウントのコンテキストを理解しているため、EC2インスタンス数やコンテナサイズなど、環境情報を考えながらセキュリティ設定を組み込むことができます。

開発サイクルにおけるCreateは、実際にコードを書く作業のことを指します。Q Developerは、さきほどのコンソールとは別にCLIでもOKです。Q Developersと動的な対話で作業できるため、例えばGitリポジトリには一般的にREADMEがあり、これを読んで全体感を掴んで開発するケースが多いと思います。しかし、プロジェクトによってはREADMEがない・更新されていないケースもあります。こういった際に、Q Developersに内容を理解させ、ドキュメント生成してもらうなどの利用もできます。従来のコード開発支援のように、要件を入力して開発自体をサポートしてもらうことももちろん可能です。

開発サイクルにおけるTest & secureは、文字通りプログラムコードのテストです。このケースではユニットテストを作成してっもらうこともできますし、Q Developersによるによるレビューも可能です。セキュリティだけでなく、読みにくいコード・わかりにくいコードも指摘してもらえます。Q Developersに修正案を作成してもらい、開発者はAccept,かDenyを選ぶような承認フローも組むことができます。

開発サイクルにおけるOpeateは、デプロイ後の環境を指します。デプロイ作業がうまくいかない場合は、Amazon CloudWatchの情報を読んでもらって、根本原因を解明してもらうことができます。あとはプログラム言語のバージョンアップも、AWS Transformで実施できます。Q Developerのおかげで、競争力を生む以外の作業を効率化できる、ということです。

Q Developersのセキュリティスキャンを、IDE上で実行することで、セキュリティ的な脆弱性を潰すこともできます。Q Developersのレビュー機能によって、既存プロジェクトに対して問題を列挙・詳細を説明してくれます。

本セッションでは、GitLabのマージプルリクエスト上でQ Developerにレビューを依頼する部部がデモで紹介されていました。/qでQ Developerにレビューしてもらい、SQLインジェクションの危険性があるというレビュー内容を作成してもらっています。

Q Deeloperで開発サイクルをセキュア化するにあたって、Amazon CodeGuru Security（以下、CodeGuru Security）を使った脆弱性検出がもうひとつのメインで紹介されていました。

CICDのパイプラインなどに対しても、CLIやSDKでCodeGuru Securityを呼び出せるので、ライフサイクル全体を通じて脆弱性の可視化ができます。

ただ、これとは別にセキュリティ要件を満たしていることをチェックする仕組みも開発サイクルでは必要になります。急遽パブリックに報告された脆弱性が、自分たちのシステムのどこに影響するか確認するなどのケースがあります。こういった場合は、Amazon Inspector（以下、Inspector）で検知します。

ソフトウェア開発現場では、SBOMというソフトウェアの部品表を作っているところもありますが、SBOMの更新ができている現場は、経験上少ないと感じるようです。発表者の方も、お客様から「依存関係のリストを出して」と依頼されたことがあるらしいです。

こういう場合は、Inspectorで、SBOMの作成をリクエストできます。S3バケットにSBOMを配置して、Amazon Athena, Amazon QuickSightで分析する運用も可能です。こういった運用のおかげで、どのサービスが脆弱性に関係しているかを判断できるようになります。

また、CICDパイプラインにSBOM作成を組み込んで、「1個でもCriticalやHigh, Mediumの脆弱性が発見された場合は、ビルドを落とす」というCICDも組むことができます。

まとめ

開発サイクルのセキュリティを改善するには、全ての段階で実施するのではなく、段階的に、開発の肝となる部分から始めることが重要、だといいます。ツールを入れるだけではあまり効果はなく、現場はそれを無視してしまうこともあります。これを生成AIで理解しやすい状態にしつつ、セキュリティは全員の責任であるという認識を持つことが極めて重要、とのことです。

恥ずかしながらあまり生成AIを支えていない自覚があったのですが、AWSの生成AIサービスを使った開発のイメージが具体的に持てて、これは実際の現場でも積極的に使ってみたい・検証してみたいと思えるセッションでした。