サプライチェーン侵害に対する緩和策

執筆者: Kelli Vanderlee, Stuart Carrera

これまで長年にわたり、サイバーセキュリティ業界におけるソフトウェアサプライチェーン侵害への理解は、いくつかの画期的な事件によって形作られてきました。その代表例が、ロシアのサイバースパイ攻撃者ICE RELIC(旧称APT29)による2020年のSolarWinds侵害と、北朝鮮のサイバースパイ攻撃者UNC4736による2023年の3CX侵害です。しかしGoogle Threat Intelligence Group(GTIG)は、過去数年にわたり、オープンソースソフトウェアリポジトリを標的としたサプライチェーン侵害の脅威活動が増加していることを追跡してきました。2025年から2026年上半期にかけて発生した一連の大規模なオープンソースソフトウェアサプライチェーン侵害キャンペーンは、この攻撃ベクトルに直接対応する防御戦略を組織が導入することの重要性を改めて浮き彫りにしています。

本ブログ記事では、GTIGとMandiantが観測した脅威アクターによるソフトウェアサプライチェーン侵害の利用傾向について論じるとともに、攻撃者がオープンソースパッケージを操作した最近のキャンペーンで顧客を支援した経験から得られた知見を踏まえ、緩和策および堅牢化のための推奨事項を提示します。

2025年から2026年初頭にかけて拡大するオープンソースサプライチェーン侵害の規模と影響

GTIGが2025年から2026年初頭にかけて追跡した、最も影響が大きく波及範囲の広いサプライチェーン侵害インシデントの大半は、コードリポジトリ、ソフトウェア依存関係、開発者ツールの侵害(T1195.001)に関わるものでした。オープンソースサプライチェーン侵害は、従来型のサプライチェーン侵害と同様の効率性、規模、初期段階でのステルス性を攻撃者にもたらす一方、実行に必要な計画や資源は概して大幅に少なくて済みます。もっとも、いったん実行されればオープンソースサプライチェーン侵害は「騒がしい」ものにもなります。悪意あるオープンソースパッケージは、従来型のサプライチェーン侵害に比べてはるかに早く発見され、公表される傾向があるためです。

GTIGは、2025年から2026年初頭にかけて確認されたワームの利用や反復的な侵害を含む、極めて大規模なオープンソースサプライチェーン侵害キャンペーンの拡大は、過去数年と比較してこの手口の利用が大幅に広がったことを示すものであると高い確度で評価しています。今後、脅威アクターがこれらのキャンペーンの手口を模倣し、2026年の残りの期間およびそれ以降もオープンソースサプライチェーン侵害の増加に拍車をかけると予想されます。GTIGは、規模や影響の観点から見て、こうした特に大規模なキャンペーンの傾向を象徴する事例として、2025年から2026年初頭にかけて注目すべき複数のサプライチェーン侵害を確認しています(図1)。

例えば2026年2月から5月にかけて、UNC6780(通称「TeamPCP」)は、PyPI、npm、Docker Hubといったエコシステムを標的とした大規模なオープンソースサプライチェーン侵害を展開しました。初期侵入経路はインシデントごとに異なりましたが、その中にはpull_request_target GitHub Actionsトリガーを悪用し、ベースリポジトリのシークレットや書き込み権限を取得する手口も含まれていました。この脅威アクターは、侵害したパッケージを利用して、SANDCLOCKを含む認証情報窃取ツールを展開し、価値の高いシークレット情報を取得することが一般的でした。インシデント対応の現場では、UNC6780が侵害した人工知能(AI)ソフトウェアを足がかりに、より広範なネットワーク環境への侵入を試みる様子も確認されています。UNC6780は、窃取した認証情報を直接売却するか、ランサムウェアやデータ窃取・恐喝グループとの提携を通じて現金化してきました。

2026年3月、GTIGは正規のaxiosパッケージに悪意ある依存関係が組み込まれた事案を確認しました。GTIGの分析および開発者による事後検証によれば、メンテナーのアカウントがソーシャルエンジニアリングによって侵害され、そのアカウントを使って更新版が公開されたと見られています。GTIGはこの悪意ある依存関係を、WAVESHAPER.V2バックドアを展開するドロッパーであると特定し、この活動を北朝鮮の攻撃者MIDNIGHT NEPTUNE(旧称UNC1069)によるものと帰属評価しています。悪意あるバージョンのaxiosは公開から3時間以内にnpmレジストリから削除されましたが、このパッケージは週間ダウンロード数が1億件を超えることから、侵害の規模は広範囲に及んだと推定されます。GTIGは、この事案の影響を受けた少なくとも15の業種、13の国の顧客を支援しました。さらに、axiosは数万に及ぶ他のパッケージの依存関係にもなっており、オープンソースの情報筋は、悪意あるaxiosの更新版がそのうちの複数のパッケージに波及したと報告しています。

AIがオープンソースサプライチェーン侵害を加速させる可能性

GTIGは、AIがオープンソースソフトウェアサプライチェーン侵害の拡大を加速させると予測しています。「バイブコーディング」を含め、オープンソースソフトウェア開発の実践にAIが組み込まれることで、攻撃者にはAI機能そのものを操作する機会と、自らの作戦計画をAIによって高速化・大規模化する機会の双方が生まれています。オープンソースの情報筋は、脅威アクターがオープンソースAIコミュニティに悪意あるリソースを仕込んだ事例を複数報告しているほか、オープンソースのモデルコンテキストプロトコル(MCP)パッケージへの悪意あるコードの挿入も報告されています。MCPは、AIがツールやデータと連携するための標準化されたプロトコルです。悪意あるパッケージはAIコーディングエージェントを欺くケースもあり、エージェントが意図せずそれをプロジェクトに組み込んでしまう事態も起きています。北朝鮮の脅威アクターは、暗号資産をテーマとした悪意あるパッケージをアップロードし、その後AIコーディングエージェントが、正規の暗号資産取引プロジェクトへの依存関係として当該パッケージを組み込むコミットを共同作成したと報じられています。

検出された悪意あるオープンソースパッケージは数千件規模に

GTIGの調査結果を裏付けるように、Linux Foundation傘下の業界横断的な非営利団体であるOpenSSFが集計した統計によると、確認された悪意あるオープンソースソフトウェアパッケージの件数は、2024年から2025年にかけて1,444%という飛躍的な伸びを見せています(図2)。

依然として稀な従来型サプライチェーン侵害

オープンソースエコシステムで観測された状況とは対照的に、GTIGは、ソースコードや更新・配布メカニズムを操作する従来型のソフトウェアサプライチェーン侵害(T1195.002)は依然として稀であると高い確度で評価しています。2025年から2026年初頭にかけて確認された数少ない事例は、そのほとんどが意図的に標的範囲を限定したサイバースパイ活動によるものでした。

最も重大な事例では、北朝鮮の脅威アクターUNC4899が、ソーシャルエンジニアリングを用いてWeb3組織の開発者マシンを侵害したと報じられています。この脅威アクターはこのアクセス権限を利用し、フロントエンドシステムに悪意あるコードを注入しました。具体的には、標的組織とマルチシグウォレットを共有する第三者組織が開始した取引を改ざんするため、スマートコントラクトの機能を狙い撃ちしました。この侵害は単一の被害者に的を絞ったもので、標的組織自身のインフラには直接手を出していません。それでもこの侵害は最終的に、推定14億米ドル相当の暗号資産の窃取につながりました。

その他の事例としては、2025年6月から12月にかけて発生したNotepad++の更新を配信するホスティングインフラへの侵害があり、GTIGはこの活動をUNC6688に帰属評価しています。GTIGは、この活動の影響を受けた組織を韓国とフランスで確認しました。また、GTIGは2026年初頭に発生したDAEMON Toolsインストーラーへの侵害も追跡しています。このキャンペーンでは、UNC6863がSLICKDEMONを展開して広範な偵察を行い、戦略的に価値の高い標的を絞り込みました。この選別段階に続き、同グループは選択的にシェルコード化されたローダーBADFALLを配信してハンズオンキーボード活動を行い、高度なQUIC RATの展開へとつなげました。このキャンペーンはロシア、ブラジル、トルコを標的とし、その後ベラルーシとタイの政府機関・科学機関に対する追加の攻撃活動へと発展しました。

サイバースパイ活動と見られる事案に加え、より広範な配布を伴う、金銭目的と疑われる侵害も確認されました。2件の別々のインシデントでは、脅威アクターが消費者向けウェブサイトの基盤となるソフトウェアを侵害しています。一方の事例では、自動車ディーラーのウェブサイトがClickFixの誘導手口を配信し、SHADOWLADDER(別名SectopRAT)のインストールにつなげました。もう一方の事例では、複数のeコマースサイトがウェブスキマーに感染していました。

緩和策の推奨事項

ソフトウェアサプライチェーン侵害を効果的に緩和し、対策を強化するには、組織はリスク露出を最小化し、潜在的な侵害に対する耐性を高めるよう設計された多層防御戦略を採用すべきです。

管理面での監督とリスクガバナンス

• 資産と依存関係のカタログ化: 単一障害点やセキュリティリスクを検出できるよう、業務上の重要度に基づき、すべてのアプリケーション、サードパーティベンダー、サービスの継続的な階層別インベントリを維持する。

• ソフトウェア部品表(SBOM): すべての社内・サードパーティ製ソフトウェアパッケージについて自動化されたSBOMを導入し、セキュリティチームが稼働中のコードインベントリを新たに公表された脆弱性と継続的に照合できるようにする。

• アクション部品表(ABOM): 利用中のサードパーティ製パイプラインベンダーおよび開発ユーティリティをすべて洗い出す専用のABOMを維持し、コンテナイメージのインベントリと紐付けることで、どの外部アクションが本番イメージをビルドしているかを正確に追跡できるようにする。

• ソフトウェア開発ライフサイクル(SDLC)の脅威モデリングと攻撃チェーンのマッピング(Wiz SITF): Wiz SDLC Infrastructure Threat Framework(SITF)のようなフレームワークとソフトウェアサプライチェーンのリスク管理を連携させ、セキュリティを孤立した管理策のチェックリストとして扱うのではなく、包括的な脅威モデルへと移行させる。この無償で利用可能なフレームワークを用いれば、組織は最近のインシデント、脅威アクターのキャンペーン、レッドチーム演習を、バージョン管理システム(VCS)、継続的インテグレーション/継続的デリバリー(CI/CD)パイプライン、パッケージレジストリ、本番インフラといった各リスクのライフサイクル段階を示すWiz SITFリファレンスIDに直接マッピングできる。この手法により、セキュリティチームは、些細で孤立した弱点(例えばロックファイルのバイパスと過剰な権限を持つパイプライントークンの組み合わせ)が高度な脅威アクターによって連結され、重大かつ影響の大きい侵害の実行につながる「攻撃チェーン」を複雑な形でモデル化できる。

• 積極的なリスク監視: 専用のサプライチェーンリスク登録簿と一元管理された是正対応トラッカーを維持し、開発ライフサイクル(SDLC)の脅威を「ガバナンス」「アイデンティティ」「パイプラインロジック」「サプライチェーン衛生」という明確な運用領域に体系的に分類する。Wiz SITFを利用する場合、各脆弱性は固有のWiz SITFリファレンスIDにより、それが該当する正確なパイプライン段階にマッピングされていなければならない。脆弱性を孤立したバグとして扱うのではなく、侵害リスクが最も高い複雑な「攻撃チェーン」(例えば、漏洩したトークンとブランチ保護の欠如、過剰な権限を持つOIDC信頼関係の組み合わせなど)の遮断を優先する。記録された各項目には担当者、目標完了日を設定し、技術的な依存関係を明確に追跡できるようにする。

• 標準化された構成管理と変更管理: すべての企業向けソフトウェアおよびハードウェアの展開を管理する変更諮問委員会(CAB)を設置する。あらゆる変更に、展開前のリスクレビュー、展開後の監視、そして検証済みの復旧・切り戻し計画を含めるようにする。

• 従業員向けセキュリティ教育: サプライチェーンの危険性、ソーシャルエンジニアリングの手口、インシデント報告に関する社内手順を中心とした継続的な研修プログラムを実施する。

• Node.js(npm/pnpm): minimumReleaseAge設定を用いてクールダウン制御を強制する。この値を少なくとも24時間(1440分)に設定することで、公開されたばかりの、汚染されている可能性のあるパッケージが、より広範なセキュリティコミュニティによって特定・削除されるまでの間、隔離状態に置かれる。旧式でサポート対象外のパッケージマネージャーのバージョン(旧版のYarnやpnpmなど)は、こうしたクールダウン制限を黙って無視してしまうため、必ず最新版へ更新する。

• Python(pip): Pythonのプロジェクト環境が、内部のリリース年齢ポリシーやゲート制御を迂回してしまう公開のPyPIレジストリから直接依存関係を取得しないようにする。すべての設定ファイルにおいて、上流パッケージの一貫した隔離・審査を確実にするため、安全性が検証済みのプライベートな--index-url を指定する。

ベンダーライフサイクル管理

• ベンダーのセキュリティ審査: 調達に先立ち、ISO 27001やSOC 2といった業界標準に照らしてサードパーティのセキュリティ体制を評価する、厳格なデューデリジェンスを実施する。

• 契約書へのサイバーセキュリティ条項の盛り込み: インシデント通知の厳格な期限、継続的な監査権、明確な責任条項など、具体的なセキュリティ要件をベンダー契約に組み込む。

• ハードウェアの来歴確認と検証: サプライチェーントレーシングを用いて部品の完全性を確認し、模造品を検出する手法を確立するとともに、修理・交換に伴う物流を保護する。

セキュリティアーキテクチャおよびエンジニアリング管理

アイデンティティ・アクセス管理

• 自動化されたシステム・ワークロードのアイデンティティ: サードパーティとの連携やビルドシステムの処理において、静的で長期間有効な管理者権限を持つパーソナルアクセストークン(PAT)からの脱却を進める。代わりに、自動化されたマシン間連携では、専用のGitHub Appsや、フェデレーテッドOpenID Connect(OIDC)経由の短命なシステムトークンの利用を義務付ける。これにより、システム間ワークフローで使用される認証情報は数分単位で失効するようになり、自動化パイプラインが侵害された場合でも、継続的な侵害のリスクを無力化できる。

• 開発者・ユーザーのアイデンティティ管理(コマンドラインインターフェース(CLI)およびリポジトリアクセス): プログラム的な開発者セッションに対して厳格なアクセス制御境界を適用する。Oktaと連携したSAML SSOは、パーソナルトークンやキーの初回発行・認可時にしか本人確認を行えないため、プログラムによるCLI接続では継続的なセッション状態の検証ができない。したがって、セッションのセキュリティは、認証情報の有効期限とハードウェアに裏付けられた管理策によって担保する必要がある。

• 厳格なトークン有効期限の強制: すべてのパーソナルアクセストークン(PAT)およびプログラム的なアプリケーションプログラミングインターフェース(API)キーの許容有効期間を最小限のしきい値(例えば最長7日間)に厳しく制限する。これにより認証情報が定期的に失効し、開発者は主要なSSOゲートウェイ経由での再認証を強制される。

• パーソナルアクセストークンの制限によるGit-over-HTTPSの無力化とFIDO2セキュアシェル(SSH)の義務化の検討: 認証情報の窃取から開発環境を保護するため、組織はGitHub Enterprise Cloud全体でパーソナルアクセストークン(PAT)をグローバルに制限することを検討すべきである。GHECにはプロトコルを直接無効化するスイッチが存在しないため、管理者はクラシックPATの無効化と短いトークン有効期限の強制を検討し、権限のないプログラム的なHTTPS接続を効果的に遮断すべきである。このプロトコルの封じ込めにより、開発者がSSH認証へ完全に移行することを促進できる。このトランスポート層を保護するため、コマンドラインからのすべてのリポジトリ操作について、物理的なトークンの所持を暗号学的に検証するハードウェア裏付けのFIDO2セキュリティキーの利用を義務付けることを検討する。

インフラの保護

• ゼロトラストと最小権限の原則: ロールベースアクセス制御(RBAC)、多要素認証(MFA)、アクセス権の定期的な監査を強制することで、マネージドサービスプロバイダー(MSP)やサードパーティベンダーに対する厳格な統制を維持する。

• ネットワークのマイクロセグメンテーション: 重要なハードウェアおよびソフトウェアを企業ネットワークの他の部分から分離する。許可リスト方式のファイアウォールルールのみを用いて権限のない送信トラフィックを遮断し、コマンド&コントロール(C2)活動を妨害する。

安全な開発エコシステム

• パイプラインとサンドボックスの分離: テスト環境、CI/CDパイプライン、非公式なスクリプト用サンドボックスが、物理的または論理的に本番資産から分離されていることを確認する。

• アーティファクト管理: サプライチェーンを保護するため、組織はGoogleのAssured Open Source Softwareを社内ワークフローに組み込み、依存関係の混同や悪意ある乗っ取りに対抗できる。このプロセスは、コードが改ざんされておらず検証済みのソースに由来することを暗号的に署名して証明する「来歴」を提供し、サードパーティ依存関係に対するより高い水準の信頼を確立する。

• 隔離ゲート: すべてのバイナリ、パッケージ、コンテナイメージを、監視下にある社内リポジトリでホストすることを義務付ける。ゼロデイの依存関係乗っ取りに対抗するため、新たに公開されたサードパーティ資産に冷却期間を設ける、ローカルな「隔離ゲート」を導入する。

• ライフサイクルスクリプトのサンドボックス化(ignore-scripts): パッケージのインストールスクリプトの自動実行を無効化することで、任意コード実行という重大な脅威を緩和する。攻撃者は依存関係を乗っ取り、通常のインストール処理の中で開発環境やランナーから認証情報を窃取する悪意あるインストール後実行スクリプトを追加することが一般的である。組織は、リポジトリ単位の.npmrcファイルにignore-scripts=trueの設定を義務付けるとともに、pnpmのonlyBuiltDependenciesのようなネイティブな許可リストを設定し、実行を検証済みの必須ツールのみに限定すべきである。

• Google OSV-Scannerによるソフトウェア構成分析(SCA): GoogleのオープンソースツールであるOSV-ScannerをCI/CDビルドパイプラインに組み込み、プロジェクトの依存関係を既知のセキュリティ上の欠陥について継続的にスキャンする。このツールは、プロジェクトの依存関係リストと、それらに影響を及ぼす特定の脆弱性をマッピングするOSV.devデータベースに対する公式サポートのフロントエンドを提供する。

• 高精度な脆弱性検出: 不正確な名前照合に依存する従来型のスキャナーとは異なり、OSVスキーマは脆弱性データを機械可読な形式で保持し、バージョン範囲やコミットハッシュに明確に対応付ける。これにより誤検知が減少し、実行可能性の高い是正通知が生成されるため、開発チームによるトリアージの負担を大幅に軽減できる。

• 依存関係ツリー全体を監査する自動スキャンツールを導入し、すべてのメンテナーのメールドメインのドメインネームシステム(DNS)解決状況および登録状況を検証する。

• 多層防御の観点から、パイプラインではパッケージ実行スクリプトを無効化し、冷却期間を設ける必要がある。

• 侵害されたパッケージが永続的なビルド環境にアクセスすることを防ぐため、デフォルトで使い捨ての単発利用ランナーを使用する。

• アクティブな悪用が発生した場合でも外部ドメインへの権限のない接続を確実に遮断できるよう、厳格な送信フィルタリングを備えた制限付きネットワークセグメントにランナーを隔離する。

ネイティブなエコシステムガードレールとの統合    

• これらの組織主導の隔離ポリシーは、多層防御の体制を実現するため、ネイティブなプラットフォームレベルのセキュリティ更新と連携して運用されなければならない。クライアント側の設定や自動更新ツールのみに単独で依存すると、単一障害点が生じてしまう。以下のネイティブなプラットフォーム管理策は、標準的な管理策と併せて調整・運用されなければならない。

• Dependabotのネイティブクールダウン(2026年7月): Dependabotは現在、バージョン更新に対しデフォルトで3日間のクールダウンを強制するようになっており、自動プルリクエストが生成される前に、(過去のchalkやdebugの乗っ取り事例のような)上流の侵害が公に発見される時間的猶予を確保している。

• PyPIのサーバー側イミュータビリティ(2026年7月): PyPIは現在、14日を超えて経過したリリースへの新規ファイルアップロードをネイティブに拒否するようになっている。これにより、侵害されたトークンを保有する攻撃者が、(LiteLLMやTelnyxの侵害事例で見られたように)固定バージョンで指定された既存の依存関係を遡って汚染することを防止できる。

• npm v12のインストール時デフォルト設定(2026年7月): npm v12はデフォルトですべてのライフサイクルスクリプトを無効化し(allowScripts: off)、手動でワークフローレベルに設定するignoreフラグに代えて、コミットで検証済みの明示的なパッケージ許可リストを採用している。

.npmrcやpip.confのレジストリ固定、npm ciによる不変のインストールプロトコル、ランナーの分離といったベースライン設定を、これらのネイティブなプラットフォームレベルのガードレールと明確に整合させ、さらに公開される上流のセキュリティ機能を継続的に評価・採用していくことで、組織はソフトウェアサプライチェーン全体にわたる強靭で多層的なセキュリティ境界を確立できます。

継続的な検証、監視、対応

自動化された取り込みと検証

• SBOM管理の自動化: すべてのサードパーティ製および社内製ソフトウェアについてソフトウェア部品表(SBOM)を導入する。これにより、Log4jのような新たな脆弱性を自動照合を通じて継続的に監視できるようになる。SBOMを中央の脆弱性管理プラットフォームに取り込むことでこのプロセスを自動化・スケール化し、展開済みのインベントリを新たに公表された悪用手法と継続的に照合する。

• セキュリティ分析の統合: 開発パイプライン内に自動化された動的アプリケーションセキュリティテスト(DAST)および静的アプリケーションセキュリティテスト(SAST)ツールを組み込み、侵害されたサードパーティ製コードがコンパイルされる前に特定・遮断する。

• 暗号学的な完全性の検証: 更新プログラムをインストールする前に、自動化システムを用いてベンダーが提供する仕様に照らしデジタル署名やハッシュ値を検証する。

• 自律的なセキュリティ検証の導入: 組織は、高度なセキュリティワークフローをCI/CDパイプラインに直接組み込むことを検討すべきである。こうしたシステムは、隔離されたサンドボックス内でシミュレーションを実行することで脅威を挙動面から評価し、そのフラグをクラウドコンテキストと照合して欠陥の実際の影響範囲を判定し、検証済みのリスクを大規模かつ迅速に是正するテスト済みのコードパッチを自動生成できる。

能動的な脅威ハンティングと監視

• 送信トラフィックとプロキシの分析: ネットワークトラフィックのベースラインを確立し、外部リポジトリや未認識のインターネットプロトコル(IP)アドレスへの不審な送信フローを特定する。

• 包括的なエンドポイントセキュリティ: インフラおよび開発者用ワークステーション全体でエンドポイント検知・対応(EDR)ツールを活用し、サプライチェーン侵害による実行後の悪意ある活動を検出する。

• ログの集約とアラート: 統合されたログ管理システムでは、以下のような異常についてアラートを発するべきである。

• 開発システム: 権限のないコード変更、ビルドパラメータの調整、不審なユーザー活動を監視する。

• CI/CDの完全性: 標準的なコードレビューの関門を回避する、権限のないワークフロー変更や異常なトリガー(repository_dispatchなど)についてアラートを発する。

• インジェクション検知: 信頼できない入力変数の中に含まれるシェルエスケープ文字やコマンド置換のパターンをログで監視する。

• 認証情報の不正利用: 未認識のIPアドレスや地域から、長期間有効な静的なキーへの認証アクセスを追跡する。

• 物理資産: インストール状況やソース情報を含む、すべてのファームウェア変更を記録する。

インシデント対応戦略

• サプライチェーン特化型のプレイブック: 以下について机上演習を実施し、対応計画を文書化する。

  • 上流パッケージの乗っ取り: 公開レジストリにおけるメンテナーアカウントの乗っ取り(ATO)が、実行時のアプリケーションコードの直接的な改ざんにつながるケース。

  • 依存関係混同攻撃: 期限切れの管理者用リカバリドメインや、スコープが未指定の社内ネームスペースを公開レジストリに悪意を持って登録し、ローカルの開発者環境やビルドランナーのインストールを乗っ取るケース。

  • 自動化パイプラインからの収集: ランナーの悪用を通じてCI/CD環境を汚染し、認証情報を収集して権限のないパッケージ公開を行うパイプライン汚染。

  • 開発者用ワークステーションおよびIDEの侵害: 秘密鍵、APIトークン、ローカルセッションの認証情報の窃取を狙った、標的型ソーシャルエンジニアリング、悪意あるIDE拡張機能、タイポスクワッティングによるローカル依存関係。

• 運用面での再評価: 業界全体を揺るがすセキュリティ事案が発生した際に、ベンダーの再マッピングとセキュリティ再評価を即座に行うプロセスを構築する。

緩和戦略に関する推奨事項は、以下からも公開情報として入手できます。

• GoogleのSupply-chain Levels for Software Artifacts(SLSA)

• 米国国立標準技術研究所(NIST)によるCybersecurity Supply Chain Risk Management Practices for Systems and Organizations(NIST SP 800-161 Rev. 1)

• 米国国家安全保障局(NSA)によるSecuring the Software Supply Chain: Recommended Practices Guide for Developers

• WIZ SDLC Infrastructure Threat Framework(SITF)SDLC Infrastructure Threat Framework

謝辞

本分析は、Matthew McWhirt氏とMichael Veal氏の協力なしには実現しませんでした。