AWS Continuum for code vulnerabilitiesが一般提供開始。検証から修正まで一貫支援
AWSがコード脆弱性の検証から修正までを一貫して支援する新サービス「AWS Continuum for code vulnerabilities」を一般提供開始した。スキャン結果の単なる列挙ではなく、実際に攻撃可能かどうかの検証、ビジネス影響度による優先順位付け、修正パッチの提示までを担う。
提供リージョンは米国東部（バージニア北部）と米国西部（オレゴン）の2つだ。修正はプルリクエストとして生成され、現時点では必ず人間の承認を経てからマージされる設計になっている。大量の脆弱性アラートに悩む開発チームにとって、対応の優先順位を判断する手がかりになる。
近年は生成AIの進化により、脆弱性の公開情報から攻撃コードが数分で作られるようになった。スキャナーが吐き出すアラートは日々数千件に達し、その多くは実害のない誤検知だ。AWS Continuumは「どの脆弱性に本当に対処すべきか」を絞り込む役割を担う。
AWS Continuumとは何か
従来の脆弱性スキャナーが抱えていた課題
従来のスキャナーはCVSSスコアなどの汎用指標で深刻度を付ける。深刻度が高くても実際には到達不可能な脆弱性と、中程度でも決済データベースのすぐ隣にある脆弱性が同じように扱われてしまう問題があった。開発専用のユーティリティに付いた「深刻度 高」と、決済データの1歩手前にある「深刻度 中」のどちらを優先すべきか、スコアだけでは判断できない。
検証には数時間の手作業が必要だった。修正に至ってはセキュリティ、インフラ、アプリケーションの各チームが数日かけて調整する。変更の影響範囲をビジネス文脈なしに評価するのが難しいからだ。AWS Continuumはこのギャップを埋めるため、検証可能な攻撃経路と修正の影響範囲を具体的に示す。
従来型のスキャナーとAWS Continuumの違いは、アラートを「数える」か、リスクを「証明する」かにある。
Continuumが提供する3つの価値
- 対象環境で実際に攻撃可能かを検証する
- ビジネス影響の大きさで課題を優先順位付けする
- 修正パッチまたは設定変更をプルリクエストとして提示する
この3つが連動することで、セキュリティ担当者が手作業で行っていた調査と調整の大部分を自動化できる。特に2つ目の優先順位付けは、従来の深刻度スコアでは見えなかったビジネス上の重要度を反映する点で独自性がある。
脆弱性の検証と優先順位付けの仕組み
コンテキストグラフの構築
AWS Continuumは2つの情報源からコンテキストグラフを作る。1つはコードリポジトリ、もう1つはAWS環境だ。AWS環境側は、コードが動作するアカウントとリージョンにコレクターを設置し、AWS Configのリソース情報やネットワーク設定を収集する。
このグラフから、顧客データストア、決済パイプライン、認証サービスといったビジネス上重要なシステムを特定し、各脆弱性の攻撃経路がそれらにどれだけ近いかで優先順位を付ける。汎用的なCVSSスコアではなく、自社環境の文脈に沿った評価が可能になる。
コンテキストグラフにより、深刻度スコアだけでは見えなかったビジネス上の影響度が明確になる。
エビデンスレベルとサンドボックス検証
各findingはコードと環境コンテキストに照らして分析され、エビデンスレベルが付与される。例として、静的解析で脆弱なコードパスが証明された場合は「Static proven」という判定が付く。再現可能なfindingは隔離されたサンドボックスで攻撃を実行し、概念実証コードと再現手順を添付する。
スコア単体ではなく、攻撃経路、ソース解析の根拠、影響範囲の評価をセットで提示するのが特徴だ。既存の防御策が検証済みの攻撃経路を検知・阻止できるかも評価する。こうした根拠があるからこそ、開発チームは修正の優先順位に納得感を持てる。
修正提案とワークフロー
プルリクエストによる修正と人間の承認
検証が完了した各issueについて、コードパッチ、依存関係のアップグレード、設定変更のいずれかの修正が生成される。接続先のリポジトリに「Continuum fix」というタイトルでプルリクエストが作成され、レビューできる状態になる。
現時点ではすべての修正に人間の承認が必要だ。プルリクエストをレビューしてマージするかどうかは開発チームが決める。生成されたパッチが「修正済み」を意味しない点はAWSも明確にしており、レビューとテストは引き続き開発側の責任だ。
現時点ではすべての修正が人間の承認待ちになる。最終判断をチームが握りつつ、バックログを計画的に減らせる設計だ。
管理コンソールの画面構成
管理コンソールはOverview、Issues、Findings、Scans、Configurationの5つのタブで構成されている。Overviewページにはコード連携、環境、AWSコレクターの状態が一覧表示される。Issuesタブには検証済みで優先順位付けされたissueだけが並び、深刻度、ステータス、作成日時を確認できる。
issueの詳細画面では、リスク評価、攻撃可能性、可能性、影響度、ブラスト半径が示される。証明セクションには判定の根拠となったソース解析が含まれ、修正セクションにはプルリクエストの状況が表示される。プルリクエストの説明文にはコンソールと同じリスク評価と修正概要が載るため、GitHubでのレビュー中にツールを切り替える必要がない。
Findingsタブは生のスキャナー出力、Scansタブはスキャン履歴と頻度設定、Configurationタブはコードソースや修正パッチ生成の有無などを管理する。環境構築にはGitHub連携またはAmazon S3バケットをコードソースとして接続し、必要に応じてAWS環境のコンテキストを収集するコレクターを設定する。
実務への影響と注意点
開発チームのワークフローに与える変化
手作業の検証が減ることで、セキュリティ担当者とアプリ開発者の調整コストが下がる。大量のアラートに圧倒される状況から、検証済みのissueに集中できるようになるのは実務上の大きな利点だ。特に複数のアプリケーションを抱える組織では、日々数千件のアラートをどう処理するかが常に課題になっている。
その一方で、このサービスはスキャナーを置き換えるものではない。既存のスキャナーが生のfindingを供給し、Continuumがそれらを検証・優先順位付け・修正提案するという補完関係にある。導入時には既存のスキャン環境と合わせて運用設計を考える必要がある。
導入時に考慮すべき点
現時点では提供リージョンが米国東部（バージニア北部）と米国西部（オレゴン）の2つに限られる。日本国内でAWSを利用している組織は、リージョン制約への対応が必要になる。また、サンドボックス検証にはコードや環境情報の収集が必要で、IAMロールやコレクターの設定が求められる。
完全自動化は将来の対応とされており、現段階ではガードレールを定義した上で自動適用を選べるようになる見通しだ。テストカバレッジやスコープ境界、過去の成功率といった条件をクリアした修正だけを自動適用する仕組みが示唆されているが、具体的な時期はまだ案内されていない。
筆者の見方として、このサービスの本質は「AIによる攻撃の自動化」に対する「AIによる防御の自動化」という構図にある。攻撃者が脆弱性情報から数分でエクスプロイトを作る時代には、防御側も検証から修正までの時間を短縮しなければ追いつかない。AWS Continuumはその競争をサービスとして提供する最初の一歩だ。
自動化領域と承認領域の境界が明確な点は、セキュリティ自動化ツールの導入を検討する現場にとって安心材料になる。
この記事のポイント
- AWS Continuum for code vulnerabilitiesは検証、優先順位付け、修正提案を一貫して自動化する
- コンテキストグラフで攻撃経路とビジネス影響を評価し、実害のある脆弱性だけを浮かび上がらせる
- 修正はプルリクエストとして生成され、現時点では必ず人間の承認が必要
- 提供リージョンは米国東部（バージニア北部）と米国西部（オレゴン）の2つ
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験