ソフトウェアサプライチェーン攻撃は、オープンソースライブラリやCI/CDパイプライン、サードパーティサービスなど、開発プロセス全体を標的とする攻撃として増加しています。
本記事では、ソフトウェアサプライチェーンセキュリティの重要性や主要なリスク、構成要素、実践すべき対策について解説します。
ソフトウェアサプライチェーンセキュリティとは
ソフトウェアサプライチェーンセキュリティとは、ソースコード、サードパーティライブラリ、CI/CDパイプライン、デプロイメントインフラなど、ソフトウェアの構築と配布に使用されるすべてのコンポーネントを保護します。これらの実践は、コードとシステムが本番環境に到達する前に安全で改ざんされていない状態を確保するために不可欠です。
セキュリティを優先することが重要な理由は、現代のソフトウェアが外部依存関係やツールの複雑なネットワークに大きく依存しているためです。この複雑さが攻撃者にとっての侵入ポイントが増えます。SolarWindsやMOVEitのような侵害は、サプライチェーンを標的にすることで深刻かつ広範な被害をもたらすことを明確に実証しています。
これらの攻撃の壊滅的な影響を踏まえ、規制当局はより厳格な統制を求めるようになっています。米国では、Executive Order 14028およびNISTのセキュアソフトウェア開発フレームワーク（SSDF）が、連邦政府のサプライヤーに対してソフトウェアサプライチェーンのセキュリティ確保を求める要件を定めています。
高まるセキュリティと規制の要求に対応するには、ソフトウェアサプライチェーン全体の可視性と、リスクを早期に特定・軽減する能力が必要です。これらの機能は、保護とコンプライアンスの両方に不可欠です。
State of SDLC Security 2026 Report
See the latest data on how teams are securing their software development lifecycle across cloud-native environments.
厳格なセキュリティが求められるソフトウェアサプライチェーンの構成要素
現代のソフトウェアサプライチェーンは、多くの相互接続された要素で構成されています。各要素は安全なアプリケーションの配信において重要な役割を果たしますが、それぞれ固有のリスクも導入します。
以下は、開発パイプラインをエンドツーエンドで保護するためにチームがセキュリティを確保すべき主要なコンポーネントです。
ソースコードとバージョン管理
ソースコードはあらゆるアプリケーションの基盤です。開発者は通常、GitHubやGitLabなどのバージョン管理システムを使用して管理します。攻撃者がPersonal Access Token（PAT）の漏洩、保護されていないブランチ、コードレビュー要件の欠如などの弱点を悪用すると、アプリケーションロジックの変更、バックドアの挿入、独自データの漏洩が可能になります。
コードの整合性を保護するために、チームはコミット署名の強制、ブランチ保護ルールの使用、マージ前のレビュー必須化、PATのスコープとアクセスコントロールの厳格な制限を行う必要があります。
依存関係とサードパーティライブラリ
開発を加速するために、チームはオープンソースパッケージや外部ライブラリに大きく依存することが多くあります。これらのコンポーネントは強力な機能を提供しますが、攻撃者がソフトウェアサプライチェーンを汚染した場合にリスクとなります。
最近の例として、Wiz Researchが発見したShai-Hulud 2.0キャンペーンがあります。攻撃者はパブリックリポジトリに悪意のあるパッケージをアップロードし、気付かないうちに開発者がビルドに含めるのを待ちました。これらのバックドア付きパッケージは、認証情報の不正な持ち出し、永続的なアクセスの確立、下流への侵害の引き金となる可能性がありました。検証されていない依存関係がいかに危険であるかを浮き彫りにしています。
この種の脅威に対抗するために、チームは自動化された依存関係の検証、ロックファイルの強制、すべてのパッケージソースにわたる継続的モニタリングを実装する必要があります。
パイプラインとCI/CDツール
CI/CDパイプラインは現代のソフトウェア配信を支えており、コードの統合からデプロイメントまですべてを自動化しています。プロセスの中心に位置するため、シークレット、認証情報、本番環境へのアクセス権を保持する高価値な標的となっています。
Jenkins、Travis CI、GitHub Actionsなどのツールはビルドを効率化しますが、誤構成の場合にリスクを生じさせます。一般的な脆弱性には、ハイジャック可能なピン留めされていないアクション、信頼されていないスクリプトの挿入、ハードコードまたは漏洩したシークレット、安全でないアーティファクトやログのストレージが含まれます。攻撃者がこれらの不備を悪用すると、悪意のあるコードの埋め込み、セキュリティ統制の迂回、他のシステムへのピボットが可能になります。
情報漏えいのリスクを低減するために、チームは最小権限アクセスによるパイプラインのハードニング、アクションのピン留めとチェックサム検証の強制、露出したシークレットのスキャン、ビルド環境の本番環境からの分離を行う必要があります。
アーティファクトレジストリとパッケージ配布
ビルドされたソフトウェアアーティファクトは、Docker Hub、npm、PyPIなどのレジストリを通じて保存・配布されます。これらのシステムはデプロイメントを効率化しますが、高価値な標的にもなります。攻撃者がパッケージを汚染したり信頼されたコンポーネントを偽装した場合、侵害されたソフトウェアが瞬時に数千のシステムに到達する可能性があります。信頼されたアーティファクトのみが環境に入ることを確保するために、安全な公開プラクティスが不可欠です。主要なセキュリティ統制には、パッケージの署名、アクセスコントロールの強制、来歴（プロベナンス）の維持、マルウェアのスキャン、ビルドおよびデプロイメント時の検証が含まれます。
デプロイメントとアップデートメカニズム
チームはDockerやKubernetesなどのコンテナ化およびオーケストレーションプラットフォームを使用して現代のアプリケーションをデプロイしており、配信と拡張性を加速しています。しかし、セキュリティが確保されていない場合、これらのメカニズム自体がアタックベクトルとなり得ます。すべてのアップデートは新しいコードを導入し、攻撃者がイメージ、コンテナレジストリ、アップデートプロセスを侵害した場合、悪意のあるコンポーネントが本番環境に直接挿入される可能性があります。これらの脅威をブロックするために、チームはアップデートソースの検証、イメージ署名の強制、デプロイメント前のコンテナの脆弱性と改ざんのスキャンを行う必要があります。
ベンダーおよびサードパーティサービス
チームは外部ベンダー、API、クラウドサービスに依存してアプリケーションをより迅速に構築・運用しています。しかし、すべてのサードパーティとの統合は攻撃対象領域を拡大します。プロバイダーが侵害されたり誤構成されたりした場合、攻撃者はそのアクセスを利用してシステムやデータを侵害できます。このリスクを管理するために、組織は明確なオーナーシップの割り当て、ベンダーのセキュリティギャップの定期的な評価、データ保護、アクセスコントロール、インシデント対応に関する契約要件の強制を行う必要があります。
ソフトウェアサプライチェーンに対する脅威とリスク
ソフトウェアサプライチェーンは、その複雑さ、規模、相互接続されたコンポーネントのネットワークにより、魅力的な攻撃対象領域を提示します。外部のアクターと内部の弱点の両方が深刻なリスクをもたらす可能性があります。これらの脅威を理解することで、防御の優先順位付けとリスクの低減が可能になります。以下は、マルチクラウド環境で一般的に遭遇する脅威とリスクの種類です。
外部の脅威とリスク
外部の脅威は、ソフトウェア開発パイプラインの公開されているまたはサードパーティの要素を標的とします。これらの脅威には、汚染されたアップデート、悪意のある依存関係、検証やトランスポートセキュリティのギャップを悪用する中間者攻撃（Man-in-the-Middle攻撃）が含まれます。
| 外部の脅威とリスク | 説明 | 実際の事例 |
|---|---|---|
| 悪意のあるコードの挿入と侵害された依存関係 | 攻撃者がサードパーティライブラリに悪意のあるコードを挿入したり、信頼された依存関係を改ざんしたりします | SolarWinds攻撃では、定期アップデートにマルウェアが挿入され、グローバルな侵害が引き起こされました |
| 中間者攻撃（Man-in-the-Middle攻撃） | 攻撃者がソフトウェアの配布中にインターセプトし、ユーザーに届く前に改変します | Operation ShadowHammerではASUSのLive Updateユーティリティが侵害され、悪意のあるプッシュに利用されました |
| データ伝送における暗号化の欠如 | 暗号化されていないアップデートにより、傍受と改変が可能になります | Ivanti Connect Secure VPN攻撃では、既知の脆弱性と暗号化されていない転送が悪用されました |
内部の脅威とリスク
内部の脅威は組織内部または信頼されたシステムを通じて発生し、内部者リスク、誤構成、認証情報の不正利用が含まれます。1つの侵害された開発者アカウントがパイプライン全体を危険にさらす可能性があります。
| 内部の脅威とリスク | 説明 | 実際の事例 |
|---|---|---|
| 内部者の脅威または侵害された開発者アカウント | 盗まれた認証情報または悪意のある内部者が、直接的なパイプライン改ざんのために機密システムへのアクセスを獲得します | Codecovの侵害では、CIスクリプトの変更が悪用され、侵害されたDockerイメージを通じてシークレットの不正な持ち出しが行われました |
| 既知の脆弱性を持つ古いコンポーネント | パッチが適用されていないソフトウェアの使用により、既知のエクスプロイトに環境がさらされます | Equifaxの侵害は、パッチ未適用のApache Strutsに起因し、1億4,000万件以上のレコードが侵害されました |
| 安全でないAPI | セキュリティが不十分なAPIにより、アプリケーションが不正アクセスや権限昇格にさらされます | WhatsAppの2024年「View Once」機能の欠陥により、消えるメディア機能への不正なAPIアクセスが可能になりました |
ソフトウェアサプライチェーン攻撃の実例
Hugging Faceと研究者が悪意のあるAIモデルを発見
2024年、Wiz ResearchはHugging Faceと協力し、同社のInference APIにおける重大なセキュリティリスクを発見しました。攻撃者はこの欠陥を悪用して、リモートコード実行（RCE）やクロステナントアクセスが可能な悪意のあるAIモデルをアップロードすることができました。
失敗した点： テナント間の不十分な分離とコンテナ検証の欠如
悪用方法： 悪意のあるモデルのアップロードがRCEとクロステナントアクセスを引き起こしました
防止策： 厳格なテナント境界、堅牢なコンテナスキャン、実行前のモデル検証セキュリティ統制
Wiz研究者はまた、基盤となるKubernetesインフラにおける弱いテナント分離を特定し、権限昇格とラテラルムーブメント（横方向の侵害拡大）を可能にしていることを明らかにしました。Spacesサービスにはコンテナレジストリセキュリティに不備があり、大規模なインフラ操作を可能にしていました。
Hugging Faceはテナント分離の強化、脆弱性スキャンの拡大、コンテナ環境のハードニングにより対応しました。
Wizが#IngressNightmareを発見
Wiz Researchは、Kubernetes用Ingress NGINXコントローラーにおける深刻な未認証のリモートコード実行（RCE）脆弱性を発見し、#IngressNightmareとして知られるようになりました。アドミッションコントローラーのWebhookにおける安全でないロジックにより、攻撃者は認証をバイパスしてKubernetesクラスターにアクセスすることが可能でした。
影響： クラウド環境の約43%および6,500以上のインターネットに公開されたクラスターに影響
悪用方法： 攻撃者は認証なしでRCEを引き起こす細工されたリクエストを送信しました
失敗した点：アドミッションコントローラーにおける安全でない入力検証と、制限されていないWebhookエンドポイントアクセス
有効だった対策： ネットワークポリシーによるWebhookのセキュリティ確保、露出の制限、厳格なアドミッション制御の適用
Wizは、公開されたクラスターを特定しリアルタイムアラートを発行するための検出機能を提供しました。組織はNGINXの更新、Webhookアクセスの制限、より厳格なKubernetesネットワークポリシーの適用により問題を軽減しました。
Shai-Hulud 2.0サプライチェーン攻撃
この大規模なnpmベースの侵害は、数百のユーザーにわたる約700のパッケージと25,000以上のGitHubリポジトリに影響を与えました。
攻撃手法： 脅威アクターがnpmパッケージをトロイの木馬化し、インストール前（preinstall）フェーズ中にCI/CDパイプラインと開発者マシンからシークレットを不正に持ち出しました
範囲： 大規模な認証情報の窃取とバックドアの永続化を可能にし、GitHubワークフローを利用して検出を回避し、AWS、Azure、GCPのシークレットを標的としたクロス被害者データ露出を促進しました
失敗した点： 侵害されたメンテナーの認証情報により、悪意のあるインストール前スクリプトを含むトロイの木馬化されたパッケージの公開が可能になりました
悪用方法： パッケージのインストールが認証情報の窃取、シークレットの不正な持ち出しや、GitHub Actionsベースの永続化を引き起こしました
有効だった対策： ライフサイクルスクリプトのデフォルトでのブロック、スコープ付きトークンの強制、インストール前のパッケージの厳格な検証
このキャンペーンは、自動化された依存関係の検証、ハードニングされたビルドシステム、リアルタイム監視の必要性が高まっていることを強調しています。
サプライチェーンリスクを軽減するためのベストプラクティス
１．セキュリティを考慮したソフトウェア部品表を作成する
可視性がすべての基盤です。完全かつ最新のソフトウェア部品表（SBOM）は、直接的および推移的な依存関係、オープンソースパッケージ、プロプライエタリモジュールを含む、コードベースのすべてのコンポーネントに対する詳細な洞察を提供します。
相互運用性とコンプライアンスのために、SPDXやCycloneDXなどの標準化されたフォーマットを使用してSBOMを生成します。各コンポーネントのバージョン、オリジン、ライセンスなどのメタデータを含めます。コードの変更に合わせて継続的に更新します。
Wizのようなプラットフォームは、エージェントレススキャンを使用してクラウドネイティブ環境全体でSBOM生成を自動化し、インベントリの精度を維持しながら手動のオーバーヘッドを削減します。
重要な理由： 開発者がデリバリーに集中できる環境を維持しながら、進化する標準（Executive Order 14028、NISTのSSDF）との整合性を確保します。
２．DevOpsとDevSecOpsを活用する
開発プロセスの早い段階でセキュリティ対策（シフトレフト）を実施し、開発パイプラインに直接セキュリティを組み込みます。異なるアプローチを使用して、プロプライエタリコードとサードパーティの依存関係の両方をスキャンします。
SASTツール（SonarQube、Checkmarx）：ロジックの欠陥、安全でないパターン、誤構成のコード分析
ソフトウェア構成解析（SCA）ツール：既知の脆弱性、古いバージョン、ライセンスリスクのパッケージおよびライブラリの検査
DevSecOpsは両方のアプローチをCI/CDワークフローに統合し、セキュリティ、開発、運用チームを結集して、速度を低下させることなく早期の問題検出と迅速な修復を実現します。
重要な理由： 問題を早期に発見することで、リスクを低減し、手戻りを減らし、本番環境の脆弱性を防止し、時間とコストを節約しながら評判を保護します。
３．定期的な監査を実施する
監査は自動化が見逃すものを捕捉します。コードの依存関係、クラウド構成、インフラの定期的な評価をスケジュールします。
| 監査対象 | ツール | 主なメリット |
|---|---|---|
| 依存関係 | OWASP Dependency-Check、Snyk | 既知の脆弱性の検出と優先順位付け |
| クラウド構成 | Wiz、AWS Config、Azure Security Center | リスクのある誤構成の検出 |
| ネットワーク動作 | Wiz、ELK Stack | トラフィックパターンの異常検出 |
重要な理由： 定期的な監査により、自動化ツールが見落とす盲点が明らかになり、進化する脅威、インフラの変更、コンプライアンス要件に対してセキュリティが追いつくことを確保します。
４．多要素認証（MFA）を実装し、最小権限の原則に基づくアクセスを強制する
すべての開発者ツールとクラウドサービスでMFAを有効にします。リポジトリとCI/CDシステム全体で最小権限を強制し、ユーザーが役割に必要な正確な権限のみを持つようにします。
重要な理由： MFAと最小権限により、攻撃者が侵害されたアカウントを使用してアクセスをエスカレートすることを防止します。
５．ソフトウェア構成解析（SCA）を実施する
SCAツールはサードパーティライブラリの既知の問題をスキャンします。パイプラインに統合して、古いまたは脆弱なパッケージを自動的に検出します。コードベースがオープンソースコンポーネントに大きく依存するクラウドネイティブ環境では、これは極めて重要です。
重要な理由：SCAは依存関係に起因する外部リスクから先見的（プロアクティブ）に保護します。
６．継続的モニタリングソリューションを選択する
セキュリティはデプロイメントで終わりません。AWS CloudWatch、Azure Sentinel、Wizなどのツールを使用して、クラウド環境全体のワークロード、構成、アクティビティをリアルタイムで追跡し、エスカレーション前の迅速な検出と対応を可能にします。
重要な理由： 見えないものは、守れない。継続的モニタリングにより、脅威が見逃されることを防ぎます。
７．コード署名と改ざん検知を強制する
すべてのビルドとアーティファクトに暗号化キーで署名します。デプロイメント時に署名を検証し、チェックサムを使用して予期しない変更を検出し、信頼され検証されたコードのみが本番環境に到達するようにします。
重要な理由： これらの強制策により、デプロイメント前に不正な変更を防止し、改ざんされたまたは悪意のあるコードから環境を保護します。
８．ビルドインフラとCI/CDシステムのセキュリティを確保する
パイプラインは高価値な標的です。厳格なアクセスポリシー、シークレット管理、ネットワークセグメンテーションによりビルド環境をハードニングします。侵害を示す異常を監視します。
重要な理由： 侵害されたCI/CDシステムにより、攻撃者は本番環境への直接アクセスを獲得します。
９．ベンダーリスクを管理する
すべてのベンダーのセキュリティ態勢、インシデント対応の準備状況、過去の実績を評価します。コンプライアンスと信頼を維持するために、定期的に評価を見直し更新します。
重要な理由： セキュリティの強度は、サプライチェーンの最も弱いリンクと同等です。
１０．インシデント対応計画を作成する
サプライチェーンの侵害は信頼されたコンポーネントが関与することが多く、検出が遅れ封じ込めが困難になります。インシデント対応計画にサプライチェーンの脅威に特化したプレイブックを含めるようにしてください。
以下の手順を定義します。
改ざんされたアーティファクトの検出
侵害されたレジストリへの対応
悪意のある依存関係の処理
ビルドシステム侵入の管理
計画には、侵害されたパッケージの取り消し、ベンダー通知の調整、SBOMの更新、環境全体でのビルド整合性の検証を含める必要があります。サプライチェーン侵害シナリオのシミュレーションを実施し、セキュリティ、エンジニアリング、サードパーティの連絡先間のチーム連携をテストします。
重要な理由： 従来のインシデントとは異なり、サプライチェーン攻撃はダウンストリームシステムにサイレントに伝播します。専用のインシデント対応計画により、迅速な封じ込めと信頼の回復を確保します。
１１．ネットワークセグメンテーションを使用する
開発、ステージング、本番環境などの環境を分離してリスクを軽減し、脅威のラテラルムーブメント（横方向の侵害拡大）を制限します。マイクロセグメンテーションとゼロトラストの原則を実装して、きめ細かなアクセスコントロールを実現します。
重要な理由： 封じ込めにより、攻撃者や誤構成がシステムの一部を侵害した場合の影響範囲を縮小します。
１２．定期的なバックアップをスケジュールする
ソフトウェアアーティファクト、構成、メタデータをバックアップします。AWS BackupやAzure Backupなどのクラウドネイティブソリューションを使用し、事業継続のためにリカバリ手順を定期的にテストします。
重要な理由： 迅速なリカバリにより、インシデント発生時のダウンタイムと運用への影響を最小化します。
Watch 5-min demo
See how Wiz Code secures your software supply chain from build to deployment.
ソフトウェアサプライチェーンを保護し続ける方法
確立されたフレームワークを活用する
業界で確立されたフレームワークの採用は、強固なサプライチェーンセキュリティ戦略の基盤です。これらの標準は、リスクの特定、軽減、ガバナンスを体系化します。
| フレームワーク | 目的 |
|---|---|
| ISO/IEC 27001（情報セキュリティマネジメントシステム） | 情報セキュリティマネジメントシステムとセキュリティ統制の要件を定義 |
| NISTサイバーセキュリティフレームワーク | 柔軟でリスクベースのインフラおよびサプライチェーンセキュリティアプローチを提供 |
| NIST セキュアソフトウェア開発フレームワーク（SSDF） | 悪用可能な欠陥を減らすセキュリティ・バイ・デザインのコーディングおよびライフサイクルの実践をガイド |
| ソフトウェア成果物向けサプライチェーンレベル（SLSA） | 段階的なソフトウェア整合性と来歴のセキュリティ統制を導入 |
| Cloud Security Alliance クラウド統制マトリクス（CCM） | サプライチェーンへの影響を含むクラウド固有のリスクにセキュリティ統制を対応付け |
これらのフレームワークの実装により、リスク態勢が改善され、コンプライアンスが簡素化され、ステークホルダーの信頼が強化されます。Wizなどのツールと組み合わせることで、ポリシー主導のセキュリティ統制、サプライチェーンの整合性検証、新たな脅威の監視が可能になります。
高まるガバナンスと保証の期待に対応する
各国政府と業界は、新たな規制、法律、大統領令を通じてサプライチェーンの監視を強化しています。高まる期待により、ソフトウェアのアテステーション、サードパーティ保証、文書化されたSBOMは、規制対象企業や公的セクターの企業にとって最低要件となっています。
NTIAのSBOM最小要素やExecutive Order 14028などの新しい標準は進化し続けています。規制圧力により、保険会社や規制当局は以下の文書化された証拠をますます求めるようになっています。
包括的なSBOMカバレッジ
安全なビルドパイプラインと改ざん防止されたリリース
厳格なサードパーティベンダー評価
ハードウェアの出所追跡
Wizは、エージェントやパイプラインの速度低下を必要とせずに、SBOMの自動生成、不備の検出、NISTのSSDFおよびSLSA標準へのコンプライアンス強制をチームに提供します。
新たな脅威に備える
組織が生成AI（GenAI）を採用するにつれ、攻撃者も同様に迅速に適応しています。脅威アクターはすでにAIを使用してサプライチェーン攻撃を加速し、パブリックレジストリで露出したシークレットをスキャンし、説得力のある悪意のあるパッケージを作成しています。
先進的なセキュリティプログラムは以下の取り組みを行っています。
ビルドシステムへのゼロトラストの強制： すべてのビルドステップ（誰がトリガーしたか、どのコードが変更されたか、アーティファクトの保存先）を検証し、セキュリティを強化
サプライチェーン保険の検討： 更新されたSBOM、厳格なベンダー評価、安全なCI/CDなどの強固なセキュリティ衛生の証拠に基づく保険オプションの評価
サードパーティのアテステーション要求： ベンダーがセキュリティ・バイ・デザインの開発手法に従い、サプライチェーンの脅威に迅速に対応できることの文書化された証拠の要求
NISTガイダンスに基づくサプライヤーへの質問
サードパーティソフトウェアを評価する際に、ベンダーのセキュリティ基準を確認するためのNIST SSDFおよびソーシング指針に基づく質問を行います。
サプライヤーは外国政府との関係がありますか？
ハードウェアおよびソフトウェアコンポーネントの完全なソーシングリストを提供できますか？
不正アクセスまたは転送から機密データを保護していますか？
明確な安全なメンテナンスおよびアップデートプロセスがありますか？
製品ライフサイクルのリスク軽減を実証できますか？
広く認知されたセキュリティ・バイ・デザインの開発フレームワークに従っていますか？
強固なフレームワーク、プロアクティブなセキュリティ統制、ベンダーの説明責任を組み合わせることで、組織はソフトウェアサプライチェーンを潜在的な負債から戦略的優位性へと転換することができます。
Wizでソフトウェアサプライチェーンのすべてのコンポーネントを保護する
WizのCNAPPは、CI/CD、DevSecOps、クラウド環境に統合することで、コードからクラウドまでソフトウェアサプライチェーンを保護します。エージェントレスのデプロイメントと深い可視性により、開発速度を低下させることなくリスクを軽減します。
| リスク領域 | Wizの機能 |
|---|---|
| SBOMの整合性 | SBOMの自動生成と署名、変更と構成ドリフトの検出 |
| アーティファクトの信頼性 | パイプライン全体でのビルドアーティファクトの出所追跡と検証 |
| CI/CDの可視性 | 露出したシークレットと不正な変更のパイプライン監視 |
| 依存関係のリスク | CVSSではなく実際の露出に基づくサードパーティコンポーネントのスコアリング |
| ランタイムリンケージ | 迅速なトリアージのための脆弱性とアクティブなワークロードの接続 |
| ベンダーおよびサービスリスク | サードパーティ接続の可視化とセキュリティ態勢の追跡 |
| リアルタイムアラート | コンテキストリッチなアラートの送信と修復ワークフローの統合 |
Wizは、AWS、Azure、GCP、GitHub、GitLab、Jenkinsなどの既存ツールにシームレスに統合し、共有されたリスク主導型のクラウドおよびソフトウェアサプライチェーンビューを中心にチームを結集させ、脅威が本番環境に到達する前に阻止します。
See Wiz in Action
Explore how Wiz unifies supply chain visibility, dependency risk scoring, and runtime context in a single platform.