AWS Well-Architected フレームワークに基づくソフトウェアサプライチェーンセキュリティのベストプラクティス

本ブログは 2026 年 5 月 26 日に公開された AWS Blog “Well-architected best practices for software supply chain security” を翻訳したものです。

npm Registry を悪用した注目すべきサプライチェーン攻撃が相次いでいます。Shai-Hulud、Chalk/Debug、tea.xyz トークンを悪用した攻撃、そして最近では axios などです。Amazon Inspector チームや Open Source Security Foundation などが参加したコミュニティの取り組みにより、影響を受けたパッケージは迅速に特定され、これらのインシデントの影響を抑えることができました。

Shai-Hulud のようなサプライチェーン攻撃は、2 つの側面の脆弱性を突きます。1 つは、侵害されて悪意のあるパッケージの公開に使われるメンテナーアカウントです。もう 1 つは、それらのパッケージをダウンロードして実行する利用者の環境です。図 1 に示す Shai-Hulud 攻撃が成功したのは、フィッシングによってメンテナーの認証情報が侵害され、脅威アクターが人気パッケージの悪意のあるバージョンを公開できたためです。このようなインシデントは、ソフトウェアサプライチェーンにおける強固なセキュリティプラクティスの必要性を浮き彫りにしています。効果的に防御するには、両方の側面に対処する必要があります。パッケージメンテナーには、アカウントの侵害を防ぎ、認証情報が盗まれた場合でも被害の拡大を抑える保護策が必要です。パッケージ利用者には、悪意のあるパッケージを検出してデプロイを防ぎ、侵害が発生した場合の被害を抑える多層的な防御が必要です。

この記事では、パッケージ利用者向けのベストプラクティスを紹介します。これらのプラクティスは「AWS Well-Architected フレームワーク – セキュリティの柱」に沿ったもので、類似の脅威にさらされるリスクを低減し、万一脅威が発生した場合の影響を抑えるのに役立ちます。

図 1: Shai-Hulud 攻撃の流れを示すアーキテクチャ図

Shai-Hulud は、開発者環境や継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインで実行されると、npm トークン、GitHub トークン、AWS Identity and Access Management (IAM) のアクセスキーなどのシークレットを探索しました。こうして漏えいした長期的な認証情報により、脅威アクターはマルウェアをさらに拡散させ、クラウドリソースにアクセスできるようになりました。最近のインシデントでは、漏えいした IAM 認証情報ペアを複数発見した組織が、他にも認証情報が漏えいしていないか、CI/CD パイプラインが侵害されていないかを懸念する事例も見られました。

開発者環境や CI/CD パイプラインから長期的な認証情報を排除すれば、システムが侵害された場合でも漏えいの範囲を縮小できます。ローカルで作業する開発者は、新しい AWS CLI のログインコマンド (aws login) を使用することで、短期間有効な CLI 認証情報を簡単に取得でき、設定ファイルに長期的な認証情報を保存する必要がなくなります。AWS IAM Identity Center でも、自動的に有効期限が切れる一時的な認証情報を簡単に取得できます。CI/CD パイプラインでは、GitHub Actions や GitLab CI などのプラットフォームとの OpenID Connect (OIDC) フェデレーションを利用することで、長期的なトークンを保存せずに、ジョブごとに一時的な認証情報を取得できます。また、IAM は AWS のアイデンティティを外部サービスにフェデレーションすることもできます。これにより、AWS のワークロードは長期的な認証情報を使用せずに外部サービスへ安全にアクセスできます。一時的な認証情報は自動的に有効期限が切れるため、万一パイプラインが侵害されても、漏えいの影響を受ける期間を限定できます。

一時的な認証情報に対応していないサードパーティのサービスを利用する場合は、AWS Secrets Manager を使用して認証情報を一元的に保管することを検討してください。シークレットへのアクセスを制限し、一時的な認証情報の使用を必須とするとともに、自動ローテーションと監査ログを適用して、これらの認証情報が漏えいするリスクを低減してください。

認証情報の漏えいによるリスクを低減するための対策は次のとおりです。

• 一時的な認証情報を使用する: 一元的な ID プロバイダーから AWS にユーザーをフェデレーションし、IAM ロールを使用してアクセスします。詳細については、「SEC02-BP02: 一時的な認証情報を使用する」を参照してください。
• 最小権限を付与する: 必要最小限の権限のみを割り当て、時折高い権限が必要になる場合は、一時的に昇格した権限を使用します。詳細については、「SEC03-BP02: 最小権限のアクセスを付与する」を参照してください。
• 長期的な認証情報を監査およびローテーションする: 特定のユースケースで長期的な認証情報が必要な場合は、監査とローテーションを行います。詳細については、「SEC02-BP05: 認証情報を定期的に監査およびローテーションする」を参照してください。

認証情報が漏えいした可能性のあるセキュリティインシデントが発生した場合は、影響範囲を限定するために、すべての長期的な認証情報を直ちにローテーションしてください。また、Amazon GuardDuty と AWS CloudTrail を使用して、異常な IAM アクティビティを検出し、侵害された可能性のある認証情報を特定してください。

一時的な認証情報と最小権限を適用していても、アカウントが 1 つ侵害されるだけで、脅威アクターに悪意のあるパッケージを公開されたり、機密性の高いリソースにアクセスされたりするおそれがあります。多層防御では、連携して機能する複数の保護レイヤーを構築することで、最初の侵害後に被害が拡大するのを防ぎます。すべての操作に承認ワークフローを追加するとデプロイの速度が大幅に低下しますが、機密性の高いワークロードに絞って戦略的に導入すれば、スピードとセキュリティのバランスを取ることができます。

重要な原則は、1 つの認証情報やアカウントが侵害されても、追加の制御によって侵害が組織全体に広がらないようにすることです。具体的には、アクセス時の多要素認証 (MFA) と、機密性の高いワークロード用に分けた IAM ロールを組み合わせます。開発者が 1 人だけのオープンソースプロジェクトでは、複数のメンテナーによる職務の分離ができないため、MFA の重要性がさらに高まります。

チームで作業するパッケージメンテナーの場合、本番環境へのパッケージのリリースに複数人による承認を必須とすることで、職務の分離を実現できます。ただし、開発者はデプロイパイプラインを開始するマージリクエストを作成できるため、機密性の高いデプロイでは、パイプライン自体に複数人による承認を組み込む必要があります。こうすることで、開発者の認証情報が侵害されてデプロイがトリガーされても、本番環境へのリリース前にパイプラインが追加の承認を要求します。

パッケージ利用者の場合は、デプロイパイプラインに複数人による承認ワークフローを組み込むことで、悪意のあるパッケージが初期スキャンをすり抜けても、本番環境へのデプロイ前に人によるレビューで不審な変更に気付ける可能性が高まります。アーティファクト署名は、こうしたプロセス上の制御を補完する暗号学的なレイヤーとして機能します。

Shai-Hulud 攻撃が成功したのは、侵害されたメンテナーの認証情報を使って、脅威アクターが悪意のあるパッケージをパブリックな npm レジストリに直接公開できたためです。パッケージ利用者にとっての防御策は、パブリックレジストリから取得したパッケージが検証を経ずに本番環境に到達できないようにすることです。アーティファクト署名は、こうした多層的なアプローチを具体的に実装する手段の 1 つです。署名によって、パッケージやコンテナイメージを、それを生成したアイデンティティに暗号学的に結び付けることで、ビルドのトリガーに使用された認証情報とは独立した検証レイヤーを構築できます。つまり、開発者の認証情報が侵害されただけでは、未検証のアーティファクトをデプロイパイプラインに持ち込むことはできません。

AWS Signer はパッケージに暗号署名を付与し、多層防御戦略の中に追加の検証レイヤーを構築します。署名の認可モデルでは責任を分離し、開発者の認証情報には署名権限を付与しないようにします。signer:SignPayload API を使用して署名する権限は、CI/CD パイプラインのロールにのみ付与します。Signer は、FIPS 140-3 レベル 3 の検証を受けたハードウェアセキュリティモジュール (HSM) に署名キーを保存し、強力な暗号保護を提供します。

図 2 に示すコンテナイメージの署名ワークフローを見ると、署名を既存のプロセスにシームレスに組み込めることがわかります。

• 開発者または CI/CD パイプラインがコンテナイメージをビルドし、Amazon Elastic Container Registry (Amazon ECR) にプッシュします
• 新機能の Amazon ECR マネージド署名を使用すると、イメージのプッシュ時に Amazon ECR が自動的に署名をトリガーします
• Amazon ECR がイメージダイジェストと署名プロファイルを指定して Signer を呼び出します
• Signer が署名プロファイルの権限を検証し、FIPS 140-3 レベル 3 の検証済み HSM に保存されているキーを使用してイメージダイジェストに署名します
• 署名は Open Container Initiative (OCI) アーティファクト形式で、Amazon ECR 内のイメージと一緒に保存されます
• デプロイ時には、アドミッションコントローラー (Amazon Elastic Kubernetes Service (Amazon EKS) の場合は Kyverno) や Amazon Elastic Container Service (Amazon ECS) のライフサイクルフックが、デプロイを許可する前に署名を検証します

図 2: Signer の署名ワークフローを示す図

独自の署名インフラストラクチャを構築する場合と比べた Signer のメリットは次のとおりです。

• フルマネージド: 独自の署名インフラストラクチャの構築や証明書のライフサイクル管理が不要です
• 自動化: Amazon ECR マネージド署名は、イメージのプッシュ時に手動の手順なしで自動的に実行されます
• 一元的なガバナンス: 1 つの署名プロファイルを複数のアカウントやパイプラインで使用できます
• ネイティブ統合: Amazon EKS での署名検証のために、Notation および Kyverno との統合が組み込まれています
• FIPS 140-3 レベル 3 準拠: 暗号操作に関する厳格な規制要件を満たします

すべての署名オペレーションの監査ログを記録しておけば、新しい IP アドレスからの署名、通常とは異なる時間帯の署名、署名ジョブの短時間での連続実行といった異常なパターンを検出できます。システム内のすべての認証情報について、誰が何にアクセスできるのか、どのように本人確認を行うのか、その認証情報が侵害された場合に被害の拡大を防ぐ第 2 のレイヤーは何かを検討してください。アーティファクト署名を一元的なストレージやソフトウェア部品表 (SBOM) と組み合わせることで、改ざんや悪意のあるパッケージに対する多層的な保護を実現できます。

パッケージと依存関係の管理を一元化すると、アプリケーションで使用する前に依存関係を検証、承認できる他、サプライチェーンのセキュリティインシデント発生時に依存関係をすばやく監査できます。最近のインシデントでは、社内のアーティファクトリポジトリで侵害された npm パッケージが見つかり、影響を受けた可能性のあるアプリケーションを迅速に洗い出す必要に迫られた組織もありました。

AWS では、AWS CodeArtifact を使用して組織のソフトウェアパッケージをホストおよび管理できます。パッケージグループ設定を使用すると、承認済みのアップストリームソースのリストを定義し、それ以外へのアクセスをブロックできます。これは、正規のパッケージによく似た名前で悪意のあるパッケージを公開するタイポスクワッティング攻撃に対する直接的な対策となります。インストール時に開発者が不審なパッケージ名を見抜くことに頼るのではなく、パッケージグループ設定によって、承認済みのアップストリームソース以外へのアクセスをリポジトリレベルで制限できます。また、一元化することで、依存関係のバージョンを固定して自動更新による悪意のあるバージョンの取り込みを防げる他、インシデント発生時にはソフトウェアポートフォリオ全体から侵害された依存関係をすばやく削除できます。

コンテナイメージについては、Amazon ECR が、AWS Key Management Service (AWS KMS) による暗号化とライフサイクルポリシーを備えた一元的なイメージストレージを提供します。Amazon ECR と Amazon Inspector のスキャンを組み合わせて、イメージの完全性を継続的に検証してください。

詳細なガイダンスについては、「SEC11-BP05: パッケージと依存関係のサービスを一元化する」を参照してください。

特に npm パッケージについては、来歴証明 (provenance attestation) が利用者側の補完的な制御となります。npm 9.5 以降で利用できる npm の来歴証明は、Sigstore を署名基盤として使用し、公開されたパッケージを、それを生成したソースリポジトリおよび CI/CD ワークフローに関連付けます。パッケージのインストール時に、npm CLI は公開されたアーティファクトが証明されたビルドの来歴と一致することを検証できるため、ビルドから公開までの間にパッケージが改ざんされていないという確信が得られます。オープンソースの npm パッケージを利用する組織にとって、新しい依存関係を追加する前に来歴証明の有無を確認することは、少ない手間でサプライチェーンの完全性を判断できる手がかりになります。npm にパッケージを公開するメンテナーは、GitHub Actions などのサポートされている CI/CD 環境で npm publish --provenance を実行すると、来歴証明を有効にできます。

詳細なガイダンスについては、「SEC11-BP06: ソフトウェアをプログラムでデプロイする」、および AWS Well-Architected フレームワークの DevOps レンズにある「DL.CS.2: Sign code artifacts after each build」を参照してください。

AWS は、開発からデプロイまで依存関係を継続的にスキャンするためのサービスを提供しています。

• 開発時: Kiro は、コードレビュー中にソフトウェア構成分析を実行して、脆弱なサードパーティコードを特定できます。
• コードリポジトリとパイプライン: Amazon Inspector は、ファーストパーティコード、サードパーティの依存関係、Infrastructure as Code の脆弱性をスキャンします。
• コンテナイメージ: Amazon Inspector は、Amazon ECR イメージの脆弱性を継続的にスキャンします。また、Amazon Inspector を CI/CD パイプラインに直接統合すれば、Amazon ECR へのプッシュやデプロイの前にイメージをスキャンできるため、リリースサイクルの早い段階で侵害された依存関係をブロックできます。

従来の脆弱性スキャナーは、既知の CVE (識別子が割り当てられ、公開されている脆弱性) を対象としています。一方、Shai-Hulud のようなサプライチェーン攻撃で使われる悪意のあるパッケージは、ゼロデイとして機能します。これらは脅威アクターが意図的に作成したもので、CVE が割り当てられる前から積極的に悪用されます。CVE データベースに依存する従来の脆弱性スキャナーでは、これらのパッケージが正式に特定されてカタログに登録されるまで検出できず、それまでに数日から数週間かかることもあります。

こうしたパッケージを検出するには、静的なシグネチャマッチングだけでなく、大規模な振る舞い分析とコミュニティの連携が欠かせません。AWS は、その大規模な運用を通じて、MadPot などから得られる脅威インテリジェンスや数百万のお客様にわたるインシデント対応データを活用し、複数の環境で不審なパッケージの振る舞いを同時に検出できます。新しく公開されたパッケージが、公開から数時間以内に複数のお客様のアカウントで認証情報の窃取を試みる振る舞いを示した場合、こうしたアカウント横断のシグナルによって迅速に特定できます。これらの検出結果は、OpenSSF Malicious Packages Repository (github.com/ossf/malicious-packages) などのコミュニティが管理するデータベースに提供されます。このデータベースは正式な識別子 (MAL-ID) を割り当て、セキュリティコミュニティ全体で共有します。tea.xyz のトークンファーミングキャンペーンでは、報告から正式な特定までにかかった時間は平均で約 30 分でした。Amazon Inspector などの AWS サービスはこのコミュニティのサイクルに参加しており、検出結果を提供するとともに、新たに割り当てられた MAL-ID を取り込んで、お客様の環境内の脅威を可視化します。

関連する脅威モデルとして理解しておきたいのが、スリーパーパッケージです。スリーパーパッケージとは、公開時には無害に見え、一定時間の経過後や特定の条件が満たされた後に初めて悪意のある振る舞いを開始するパッケージです。インストール時点では悪意のあるペイロードが存在しないか有効になっていないため、静的分析だけではこうしたパッケージを捕捉できません。Amazon Inspector の振る舞い分析は、特にこの種の脅威の検出を目的として設計されており、静的な脆弱性スキャンを補完します。

SPDX または CycloneDX 形式の SBOM を使用すると、インシデント発生時に影響をすばやく評価できます。サプライチェーンのインシデントに対応する際は、SBOM を使用して侵害されたパッケージを含むアプリケーションを特定し、修復の優先順位を付け、影響範囲を評価します。Shai-Hulud インシデントでは、侵害されたパッケージ (MAL-2025-46974 および CVE-2025-59144) が早期に特定され、お客様が具体的に対処し、すばやく修復できる検出結果が提供されました。一方で、スキャンを有効にしていてもアラート疲れに陥っていた組織では重要なアラートを見逃した可能性があり、アラートの適切なルーティングと優先順位付けの重要性が浮き彫りになりました。

図 3: 悪意のあるパッケージの検出結果を表示している Amazon Inspector コンソールのスクリーンショット

詳細なガイダンスについては、「SEC11-BP02: 開発およびリリースライフサイクル全体でテストを自動化する」を参照してください。

異常な振る舞いを早期に検出するには、アクティビティを可視化することが不可欠です。ログ記録を設定し、分析できるようにログを一元化します。

• アプリケーションとサービスのログ記録を有効にします
• 複数のアカウントにわたるログを一元化してモニタリングします
• GuardDuty を使用して、悪意のあるアクティビティや異常な API コールを継続的にモニタリングします
• AWS Security Hub で検出結果を集約し、AWS Config で設定のベストプラクティスを適用します

CloudTrail のログは、認証情報へのアクセスや API アクティビティの監査証跡となります。サプライチェーンのインシデントに対応する際は、CloudTrail ログを確認し、認証情報の侵害や悪意のあるアクティビティを示す特定のイベントを探してください。具体的には、想定外の IP アドレスやリージョンからの sts:AssumeRole の呼び出し、見慣れないソースからの secretsmanager:GetSecretValue または ssm:GetParameter の呼び出し、CI/CD パイプラインを経由せずに開発者のワークステーションから実行された ecr:PutImage、通常のデプロイ時間帯以外に実行された lambda:UpdateFunctionCode、直後に API アクティビティが続く iam:CreateAccessKey、通常とは異なる IP アドレスからの codecommit:GitPush または codebuild:StartBuild などです。Amazon EventBridge ルールと組み合わせれば、Amazon Inspector が悪意のあるパッケージを検出したときや、こうした通常とは異なる認証情報へのアクセスパターンが発生したときに、自動対応をトリガーできます。

最近のサプライチェーン攻撃の影響を受けた組織は、CloudTrail の分析によって認証情報の漏えい範囲を判断し、侵害された認証情報でアクセスされた可能性のあるリソースを特定しています。このフォレンジック機能は、影響範囲を把握し、修復を漏れなく行うために不可欠です。

詳細なガイダンスについては、「SEC04: 検出」のベストプラクティスを参照してください。

多層防御戦略を構成するこれらの要素が連携して機能することで、最初の侵害後の被害の拡大を防ぎ、イベントの検出と対応を支援します。図 4 に、これらの要素の全体像を示します。

図 4: 防御アーキテクチャを示す図

Well-Architected フレームワークのセキュリティの柱では、組織のあらゆる側面でセキュリティプロセスを改善するのに役立つ、組織的なベストプラクティスも提供しています。関連するベストプラクティスとしては、「SEC11-BP01: アプリケーションセキュリティのためのトレーニングを実施する」、「SEC11-BP08: ワークロードチームにセキュリティオーナーシップを組み込むプログラムを構築する」、および「SEC10: インシデント対応」があります。

Shai-Hulud、Chalk/Debug、tea.xyz などの最近のインシデントは、脅威アクターがアタックサーフェスの拡大と攻撃の拡散を狙い、パッケージレジストリ、CI/CD パイプライン、開発者の認証情報を継続的に標的にしていることを示しています。侵害されたメンテナーアカウントや悪意のあるパッケージが 1 つあるだけで、数千もの利用者の環境に同時に被害が広がる可能性があります。この記事で紹介した制御は、こうした脅威モデルを念頭に置いて設計されています。一時的な認証情報は、盗まれたトークンが攻撃者にとって持つ価値を限定し、依存関係の一元管理とアップストリームのブロックはレジストリレベルでアタックサーフェスを縮小します。アーティファクト署名により、ビルドパイプラインが侵害されても、署名されていないアーティファクトが本番環境に到達することはありません。さらに、ソフトウェアライフサイクル全体で依存関係をスキャンすることで、侵害されたパッケージを影響が出る前に早期に特定できます。レイヤーを重ねるごとに、脅威アクターが付け入る隙は狭まっていきます。

このトピックをさらに詳しく知るには、次のブログとワークショップを参照してください。

• サプライチェーン攻撃への防御策: Chalk/Debug 侵害と Shai-Hulud ワームの対応事例から
• Amazon Inspector がトークンファーミングキャンペーンに関連する 15 万件以上の悪意ある npm パッケージを検出
• 最近の npm サプライチェーン攻撃への対応から AWS Security が学んだこと
• Amazon CodeArtifact パッケージグループ設定を使用してソフトウェアサプライチェーンのセキュリティを強化
• Hands-on Workshop: Enhancing Supply Chain Security

本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。