CI/CD パイプラインで OTA アップデートを保護する方法

安全なOTAアップデートを CI/CDパイプラインために必要な知識をまとめました：

• 安全な通信プロトコルを使用する： TLS 1.3、HTTPS、SSL pinningを実装し、アップデート中の改ざんや傍受を防止します。
• 暗号鍵でアップデートに署名する： 公開鍵基盤（PKI）とセキュアブートローダーを使用して、アップデートの整合性を検証します。
• エンドツーエンドで暗号化： エンドツーエンド暗号化（E2EE）により、アップデートの全工程を保護します。
• CI/CDパイプラインを保護する： シークレット管理ツールで認証情報を管理し、ビルド環境を分離して、ロールベースのアクセス制御（RBAC）を適用します。
• セキュリティテストを自動化する： デプロイ前スキャン（SAST、SCA、DAST）を実行し、脆弱性を早期に発見します。
• 監視とロールバックの準備： アップデートのパフォーマンスを追跡し、A/Bパーティショニングなどのロールバックメカニズムを実装します。
• コンプライアンスを維持する： 監査ログを保持し、アプリストアのガイドラインに従い、重要なアップデートの承認ワークフローを設定します。

CI/CDパイプラインをセキュアにする実践ステップ | セキュアなソフトウェアデリバリー | OpsMx Delivery Shield

OTAアップデートの基本セキュリティ設定

OTAアップデートのセキュリティ確保には、セキュアな通信プロトコル、暗号署名、エンドツーエンド暗号化といった多層的な防御が必要です。各レイヤーが特定ののリスクに対処し、連携することで強固な防御システムを構築します。

安全な通信プロトコルの利用

デバイスとアップデートサーバー間の通信を保護するには、信頼性が高く安全なチャネルが必要です。 トランスポート層セキュリティ (TLS) が最適なプロトコルであり、現在はデータ転送時の保護においてTLS 1.3が標準となっています。 [1].

TLSを実装する際、デバイスはサーバーの身元を認証する必要があります。これは、OSが提供する認証局（CA）による検証、または自己署名証明書のような事前配布された鍵を使用して行われます [1]。このステップにより、攻撃者が正当なアップデートサーバーになりすますことを防ぎます。

HTTPS暗号化 は、中間者攻撃（man-in-the-middle attacks）を阻止するために、クライアントとサーバー間のすべてのやり取りにおいて必須とすべきです [2]。さらに、 SSLピニング は、たとえ認証局（CA）が侵害されたとしても、アプリケーションが特定のSSL証明書のみを信頼するように強制します [2].

通信プロトコルは、アップデートへのアクセス接続の認証、インベントリデータの交換の保護、そしてステータス情報の配信保護という、3つの重要な役割を果たす必要があります [1]。これらの領域のいずれも、セキュリティが確保されていない場合は脆弱性となる可能性があります。

通信の安全性が確保されたら、次のステップは暗号署名によってアップデートの整合性を保証することです。

暗号鍵によるアップデートの署名

暗号署名により、アップデートパッケージが改ざんされておらず、かつ信頼できるソースからのものであることが保証されます。 公開鍵基盤（PKI） は、この目的において最も信頼性の高いフレームワークです [3].

仕組みは以下の通りです。開発者はデプロイ前にプライベートキーでアップデートパッケージに署名します。デバイスはアップデート中に、対応するパブリックキーを使用して署名を検証します。この検証に失敗したパッケージはすべて拒否されます [3].

セキュアブートローダーは、さらなる保護レイヤーを追加します。起動時に、ハッシュ関数やデジタル署名などの暗号技術を使用して、ソフトウェアの真正性と整合性をチェックします [3]。これにより、たとえインストールされていたとしても、悪意のある code が実行されるのを防ぎます

長期的なセキュリティを維持するには、適切な鍵管理が不可欠です。以下に、脅威レベルごとの対応リファレンスをまとめました。

アップデートの整合性を確認した後の最終ステップは、エンドツーエンド暗号化によって機密性を保護することです。

エンドツーエンド暗号化の設定

エンドツーエンド暗号化（E2EE）は、ビルドシステムからユーザーデバイスまでの全経路を保護します。この手法により、アップデートを配信するプラットフォーム側であっても、コンテンツへのアクセスや改ざんが不可能になります。これにより、改ざん、code の注入、および配信中のデータ漏洩を防ぎます。

E2EEを実装するには、開発環境から離れる前にアップデートパッケージを暗号化します。セキュアな鍵交換プロトコルを使用して暗号鍵を共有し、ターゲットデバイス上でその正当性を検証してください。強力な暗号化手法とセキュアな鍵管理の組み合わせが、このシステムの基盤となります。

次のようなプラットフォームは、 Capgo Capacitor アプリ向けに組み込みのエンドツーエンド暗号化を提供することで、このプロセスを簡素化します。Capgo は、Apple および Android のセキュリティ要件を遵守しながら暗号化プロセスを管理するため、カスタムシステムの構築コストを抑え、潜在的な脆弱性を低減できます。

CLI ツールを通じて暗号化を自動化することで、プロセスをさらに効率化できます。これによりヒューマンエラーを最小限に抑え、すべてのアップデートに対して一貫したセキュリティ対策を適用できます。CI/CD パイプラインに暗号化を組み込むことで、開発スピードや効率を損なうことなく、デプロイ中のパッケージを保護できます。

攻撃からCI/CDパイプラインを守る

CI/CDパイプラインは、OTAアップデートに悪意のあるcodeを注入しようとする攻撃者にとって格好の標的です。万が一侵害されると、有害なcodeを迅速に配布されてしまうため、セキュリティ対策は最優先事項となります。ワークフローを保護するには、認証情報の保護、ビルド環境の分離、および厳格なアクセス制御の徹底に注力してください。これらの対策は、OTAアップデートの配信を安全に保つための既存の戦略と組み合わせて実施することが重要です。

認証情報とAPI鍵の管理

APIキーやデータベースの認証情報、署名証明書などの機密情報をcodeリポジトリに直接保存することは、重大なセキュリティリスクとなります。攻撃者はこうした脆弱性を積極的に探しており、バージョン管理システムに保存されたシークレットは特に危険にさらされやすい状態にあります。 [5].

最新のCI/CDプラットフォームには、認証情報を安全に管理するためのシークレット管理ツールが備わっています。これらのツールは、プロジェクトファイルやログに情報を露出させることなく、ビルド時にのみ認証情報を注入するため、許可されたユーザーのみがアクセスできる環境を確保できます。 [5].

シークレット管理によく使われるオプションをいくつか紹介します：

シークレットを定期的に（理想的には自動プロセスで）ローテーションすることで、脆弱性が悪用されるリスク期間を短縮できます [4]。さらに、シングルサインオン（SSO）と 多要素認証 (MFA) を導入することで、認証情報に基づいた攻撃の可能性を大幅に低減できます。MFAを導入するだけで、このリスクを90%以上削減可能です [5].

ビルド環境の分離

ビルド環境を隔離することも重要なステップです。各ビルドは、残存する設定やキャッシュファイル、未検証の依存関係がない、クリーンで安全な状態から開始する必要があります [5]. これにより、ビルド間の相互汚染のリスクを軽減し、セキュリティ監査を簡素化できます。

一時的なランナーや、以下のようなコンテナ化されたビルドを使用することで、 Docker を利用すれば、すべてのビルドにおいて一貫した隔離環境を確保できます。これらのコンテナは、既知の安全なベースイメージから起動するため、脆弱性への露出を最小限に抑えられます。

さらに、開発、テスト、本番環境を完全に分離するために、パイプラインをセグメント化してください [7]。各ステージに必要な権限のみを付与することで、万が一の侵害が発生した際の潜在的な被害を抑えることができます [8].

ロールベースアクセス制御の設定

ロールベースのアクセス制御（RBAC）は、パイプラインとOTA updatesの整合性を維持するために不可欠です。RBACにより、チームメンバーは自身のロールに必要なパイプラインのステージにのみアクセスできるようになります。このアプローチは、認証情報の保護や環境の隔離に直結します。最小権限の原則に従うことで、開発者、テスター、セキュリティレビュアー、デプロイマネージャーといった明確なロールを定義し、それぞれのタスクに合わせた権限を設定できます [6].

ほとんどのCI/CDプラットフォームには、RBAC機能が組み込まれています。例として：

• Jenkins: マトリックスベースのセキュリティや、ロール戦略プラグインを提供しています。
• GitLab: プロジェクトレベルの権限設定とグループ管理をサポートします。
• GitHub アクション: リポジトリの権限および環境保護ルールを適用します。

ロールと権限を定期的に監査することで、不要なアクセスを特定・削除し、権限が現在の業務内容と一致している状態を維持できます。 [6]. セキュリティをさらに強化するため、本番環境へのデプロイや設定変更などの重要な操作には、多要素認証（MFA）を必須にしてください。

Capgo のようなプラットフォームでは、RBACをアップデート管理システムに直接統合しています。これにより、特定のユーザーセグメントに対して誰がアップデートをデプロイできるかを細かく制御できます。開発者は管理された環境で変更をテストしつつ、権限を持つチームメンバーのみが本番デバイスへアップデートをプッシュできるため、プロセスを厳格にコントロールできます。

OTAアップデートの自動セキュリティテスト

自動化されたセキュリティテストは、ソフトウェアが本番環境に到達する前に脆弱性を特定する上で極めて重要な役割を果たします。2022年にはサプライチェーン攻撃が600%以上も急増しており、CI/CD pipelineに徹底したセキュリティスキャンを組み込むことは不可欠です。これらの自動テストは、最初のコミットからデプロイに至るまでのあらゆる段階でセキュリティを確保し、ユーザーを保護して信頼を維持します。

デプロイ前のセキュリティスキャン実行

安全なアップデートメカニズムは基本ですが、デプロイ前のセキュリティスキャンを追加することで、脆弱性を早期に発見し、さらなる保護レイヤーを追加できます。このプロアクティブなアプローチにより、開発のより早い段階でセキュリティを確保（シフトレフト）し、後続工程でのリスクを最小限に抑えることが可能です。

静的アプリケーションセキュリティテスト (SAST) これらのツールは、code を実行せずに解析することに特化しています。開発段階で潜在的な脆弱性を特定します。例えば、 Spectral などのツールは、誤検知を最小限に抑えつつ、リアルタイムでフィードバックを提供します。 [9].

ソフトウェア構成分析 (SCA) プロジェクトの依存関係を調査し、既知の脆弱性データベースと比較します。例えば、JavaScript プロジェクト向けの npm-Audit や Golang 依存関係向けの Nancy は、依存関係チェーン内の問題を自動的にフラグ立てします。 [10].

動的アプリケーションセキュリティテスト (DAST) 実際の攻撃シナリオをシミュレートすることで、静的ツールが見逃す可能性のある脆弱性を明らかにします。Burp Suite による Dastardly のような無料のオプションは CI/CD パイプライン向けに設計されており、一方で ZAP はプロキシベースのトラフィック分析により、リアルタイムで脆弱性を検出します。 [9] [10].

Infrastructure as Code (IaC) 以下のようなスキャンツールを使用して、 KICS と Prowlerデプロイ設定をレビューし、実装前に不適切な設定がないか確認します。このステップは、設定ミスによる攻撃からOTA updateインフラを保護するために極めて重要です。 [10].

アップデートの監視と問題検知

アップデートの安全なデプロイ後は、継続的なモニタリングにより問題をリアルタイムで検知できます。これには、アップデートの失敗、不正アクセス、セキュリティ侵害の兆候となる異常なネットワークアクティビティの特定が含まれます。

• アップデート成功のモニタリング ダウンロード成功率、インストール完了率、アップデート後のデバイス全体の健全性などのメトリクスを追跡します。これらのメトリクスの急激な低下や異常なエラーパターンは、アップデートファイルの破損やセキュリティ上の懸念を示唆している可能性があります。
• ネットワークアクティビティの分析 アップデート中のトラフィック挙動を監視します。予期しないデータ転送、未承認のサーバーへの接続、異常な帯域幅の使用に注意してください。これらは、アップデートの改ざんや中間者攻撃（man-in-the-middle attacks）の兆候である可能性があります。
• デバイス挙動のモニタリング アップデート後のデバイスパフォーマンスの異常を検知します。例えば、CPU、メモリ、またはネットワーク使用率のスパイクは、悪意のあるアクティビティを示している可能性があります。デバイスフリート全体からテレメトリデータを収集することで、これらのパターンを迅速に特定できます。

Capgo のようなプラットフォームは、リアルタイムのアップデート追跡を CI/CD ワークフローに直接統合することで、モニタリングを簡素化します。このような監視体制により、必要に応じて迅速なロールバックやリカバリ操作が可能になります。

ロールバックとリカバリオプションの設定

アップデートの失敗やセキュリティ問題が発生した際にデバイスの機能を維持するには、自動ロールバックシステムが不可欠です。デュアルバンク（A/B パーティショニング）構成を採用すれば、常にバックアップのファームウェアバージョンを確保できます。システムが新しいアップデートを検証し、チェックに失敗した場合は、自動的に以前の信頼できるバージョンに切り戻します。 [11].

ウォッチドッグタイマーや、その他の対策、および 段階的なロールアウト, リスクをさらに軽減できます。ステージドロールアウトは少数のデバイスから始めて徐々に拡大するため、潜在的な問題の影響を抑え、必要に応じて素早くロールバックできます。

リカバリテスト も同様に重要です。停電、ネットワークの中断、ダウンロードの破損といった障害シナリオをシミュレートすることで、実際の環境でロールバックメカニズムが意図通りに動作することを確認できます。 [11].

現在、DevSecOpsのプラクティスを完全に導入しているセキュリティチームはわずか36%に過ぎませんが、 [10]パイプラインに自動セキュリティテストを組み込むことで、防御力を強化できます。複数のセキュリティアセスメントを集約できるツールを活用すれば、プロセスを効率化し、CI/CDパイプラインが厳格なセキュリティ要件を満たすようにできます。

コンプライアンスと監査要件への対応

OTAアップデートのデプロイにおいて、規制コンプライアンスは単なるチェック項目ではなく、組織とユーザーの両方を守る重要なセーフガードです。堅牢なアップデート配信と安全なCI/CDプラクティスを組み合わせることで、これらの要件を満たす強固な基盤を構築できます。

永続的な監査ログの作成

監査ログは、あらゆる変更やアクセスイベントを追跡するために不可欠です。デプロイのアクティビティをJSONやsyslog形式で記録することで、完全なトレーサビリティを確保できます。 [12][13].

ここで重要な役割を果たすのが、ログの集約です。さまざまなCI/CDコンポーネントのログを1か所に集約することで、イベントの分析や相関関係の把握がより効果的になります。この構成により、不審なアクティビティの特定が容易になり、モニタリングが効率化されます。これらのログを、中央集約型のログ管理システムやSIEM（Security Information and Event Management）プラットフォームに送信することで、潜在的な脅威に対する監視と対応能力が向上します。 [13].

予期しない変更や異常なアクセスパターンなどの異常を検知するには、CI/CDパイプラインのリアルタイム監視が不可欠です。セキュリティ問題が発生した際にチームへ通知するアラート機能を実装しましょう。ただし、誤検知（false positives）が多すぎてチームの負担にならないよう、アラート設定のバランスを考慮することが重要です。 [12][13].

「セキュリティは後付けするものではなく、基盤そのものです。初日からパイプラインに組み込んでおけば、後から脆弱性を修正したり、攻撃者の痕跡を消去したりする苦労を避けられます。」 - SpectralOps [14]

監査ログを定期的にレビューすることで、アクセス権限を真に必要なユーザーのみに限定できます。また、セキュリティ問題の兆候となる不整合の発見にも役立ちます。ログの運用ルールが組織のポリシーに準拠し、コンプライアンス要件を満たしていることを確認してください。 [13].

App Storeのガイドライン遵守

AppleとGoogleは、特定のセキュリティプロトコルやユーザーの同意要件を含む、OTAアップデートに関する厳格なルールを定めています.Capgoのようなツールには、これらのプラットフォームのセキュリティ基準に準拠するように設計された機能が組み込まれています。

セキュリティ以外では、アプリストアのガイドラインはシームレスなユーザー体験を重視しています。アップデートによってコア機能が中断されることがあってはならず、重要な変更についてはユーザーに通知する必要があります。さらに、ポリシー違反を避けるため、OTAソリューションはアップデートの頻度やファイルサイズに関するプラットフォーム固有のルールに従う必要があります。

ドキュメント化も重要な要素です。アップデートの内容、セキュリティ対策、ユーザーへの影響について詳細な記録を残しましょう。これらの記録は、App Storeの審査をサポートするだけでなく、プラットフォームのガイドラインを遵守している姿勢を示すことにもつながります。

承認ワークフローの設定

自動化はセキュリティとコンプライアンスを強化しますが、構造化された承認ワークフローを導入することで、人間による重要な監視の層を追加できます。例えば、Release Activation に複数人によるレビューを必須にすれば、アップデートが公開される前に徹底的な精査が行われることを保証できます。 [15].

ここではロールベースの権限が不可欠です。例えば、次のように具体的な役割を割り当てます。 シニアデベロッパーが code の変更を承認し、 セキュリティスペシャリストが 暗号化とコンプライアンス対策を検証します。この仕組みにより、アップデートは適切な専門家によってレビューされます。

階層化された承認システムを使えば、プロセスをさらに細かく調整できます。例えば：

• 軽微なバグ修正には、承認者が1人だけで済む場合があります。
• 大規模なアップデートやセキュリティパッチには、異なるチームの複数のレビュアーが関与すべきです。

承認ワークフローを既存のプロジェクト管理ツールやコミュニケーションツールと連携させれば、プロセスを効率化できます。自動通知により、レビュアーは自分の判断が必要なときに把握でき、詳細な変更ログが意思決定に必要なコンテキストを提供します。承認にかかる時間をモニタリングしてボトルネックを特定すれば、セキュリティを損なうことなくワークフローを最適化できます。

安全なOTAアップデートのベストプラクティス

CI/CDパイプラインでOTA（over-the-air）アップデートを安全に保つには、自動化と慎重な人による監視の組み合わせが重要です。未パッチのファームウェアが IoTセキュリティ侵害の60%を占めているため [16]、これらのプラクティスは単に役立つだけでなく、ユーザーとビジネスの両方を守るために極めて重要です。

主要なセキュリティ要件

安全なOTAアップデートの基盤となるのは、4つの主要な柱です。1つ目は、 エンドツーエンド暗号化 転送中のアップデートパッケージの改ざん防止です。次に、 暗号署名 によって、検証済みのアップデートのみがユーザーのデバイスに届くことを保証します。

次の保護レイヤーはCI/CDパイプラインです。これには、適切な認証情報の管理、隔離されたビルド環境、アップデートをデプロイできる人を制限するロールベースのアクセス制御が含まれます。

自動バリデーション これも極めて重要なステップです。デプロイ前のセキュリティスキャン、自動テスト、継続的なモニタリングにより、脆弱性を早期に検知できます。これらを監査ログや承認ワークフローと組み合わせることで、強固なセキュリティチェックポイントを構築できます。

これらの対策を組み合わせることで、専用ツールを活用してOTAアップデートプロセスを強化するための強固な基盤が整います。

ツールの活用 Capgo

基本的なセキュリティプラクティスを確立した後は、 Capgo を活用することで実装が容易になります。 750以上のアプリで2,350万件のアップデート実績を持つCapgoは、セキュアなOTAシステムをいかに効果的にスケールできるかを示しています。

Capgoは、 エンドツーエンド暗号化 シームレスなCI/CD統合を提供することでセキュリティを簡素化し、脆弱性の原因となりやすい手動設定を削減します。さらに、AppleやAndroidの要件に準拠しているため、アプリストアのガイドラインを気にすることなくアップデートに集中できます。

また、このプラットフォームは以下も提供しています： ロールバック機能 とバージョン管理は、アップデートに問題が発生した際の不可欠なセーフティネットとなります。不具合のあるアップデートの修正に奔走する代わりに、問題に対処しながら、すぐに安定したバージョンへ戻すことができます。リアルタイム分析と組み合わせることで、問題を即座に特定し、対応できます。

これらのツールとプラクティスを導入することで、OTAアップデートのセキュリティを強化する次のステップに進む準備が整います。

セキュアなOTAアップデートの始め方

まずは、現在のCI/CDパイプラインにセキュリティ上のギャップがないか監査しましょう。特に認証情報の管理には細心の注意を払ってください。APIのキー、署名証明書、その他の機密データが安全に保存され、許可されたプロセスのみがアクセスできるよう徹底してください。

すべての工程を暗号化する アップデートプロセスのすべての工程を暗号化しましょう。これには、アップデートパッケージの暗号化、通信へのHTTPSの利用、ビルド環境の保護が含まれます。また、パイプラインの可視性を完全に維持するために、ロギングとモニタリングツールをセットアップしてください。

導入する 承認ワークフロー 重要なアップデートには承認ワークフローを導入しましょう。ルーチン的なパッチは自動化されていても、重大な変更に対して人のレビュープロセスを設けることで、セキュリティの層を厚くできます。運用しながら、スピードと監視のバランスが最適になるよう、これらのワークフローを洗練させていきましょう。

最後に、ロールバック手順をテストし、四半期ごとにセキュリティレビューを実施して、新たな脅威に備えてください。セキュリティインシデントへの対応において、事前の準備ができているかどうかが決定的な差を生みます。

FAQ

::: FAQ

CI/CDパイプラインにおけるOTAアップデートの主なセキュリティリスクとは？開発者はどう対処すべきか？

CI/CDパイプラインにおけるOver-the-air (OTA) アップデートには、以下のようなリスクが伴います。 データの傍受, code の改ざん、および サーバーへの不正アクセス。これらの脆弱性は、アプリの整合性を損なったり、機密性の高いユーザー情報を漏洩させたり、あるいは不正なアップデートを許してしまう可能性があります。

これらの課題に対処するため、開発者は以下のような主要なセキュリティ対策に注力すべきです。 エンドツーエンド暗号化, code 署名、およびHTTPSなどの安全なプロトコルの使用です。強力な認証方法の導入や定期的なセキュリティ監査の実施により、アップデートプロセスはさらに強化されます.Capgo のようなツールを活用すれば、暗号化されたアップデート、スムーズなCI/CD統合、AppleやAndroidのガイドラインへの準拠といった機能により、これらのプロセスを簡素化できます。

これらの戦略を実装することで、開発者はOTAアップデートの安全性と信頼性を維持し、業界標準を満たしながら、ユーザーにより安全な体験を提供できます。 :::

::: FAQ

暗号署名はOTAアップデートをどのように保護するのか、また公開鍵基盤（PKI）の役割とは何でしょうか？

暗号署名は、OTAアップデートの安全性と信頼性を確保する上で極めて重要な役割を果たします。活用するには、 公開鍵基盤（PKI）を利用して、開発者は秘密鍵を使用してアップデートパッケージに署名します。アップデートを受け取るデバイスは、対応する公開鍵を使用して、アップデートが信頼できるソースから提供されていること、および転送中に改ざんされていないことの2点を確認します。

この手法により、不正または悪意のあるアップデートを効果的にブロックし、デバイスの機能とセキュリティの両方を保護します。CI/CDパイプラインにPKIを統合することは、安全なOTAアップデートを維持するための不可欠な対策です。 :::

::: FAQ

OTAアップデート中のCI/CDパイプラインにおいて、認証情報やAPIキーを安全に管理するためのベストプラクティスは何ですか？

OTAアップデート中のCI/CDパイプラインで認証情報やAPIキーを安全に保つために、従うべき主なステップは以下の通りです：

• シークレットを安全に保存する: 機密データをコードベースに埋め込むのではなく、環境変数やセキュアなVaultを使用してください。このアプローチは、シークレットを保護するだけでなく、環境間の設定管理をはるかに簡単にします。

• 権限を制限する: キーや認証情報には必要最小限のアクセス権のみを割り当ててください。また、潜在的なリスクを最小限に抑えるため、定期的にシークレットをローテーションする習慣をつけましょう。

• 漏洩を自動スキャンする：次のようなツールを使用して git-secrets ことで、不注意による露出を早期に検知できます。これに詳細なログ記録とモニタリングを組み合わせることで、不正アクセスの試行を迅速に特定し、対応することが可能になります。

Capacitor アプリを開発している場合、Capgo のようなプラットフォームを利用すると、エンドツーエンド暗号化やユーザーごとのアップデート割り当てなどの機能により、CI/CD への統合が容易になります。これらのツールを活用することで、OTA アップデートのセキュリティとコンプライアンスを確保できます。 :::

「CI/CD パイプラインにおける OTA アップデートのセキュリティ確保方法」の続きはこちら

以下を使用している場合： CI/CD パイプラインで OTA アップデートを保護する方法 セキュリティとコンプライアンスの計画に使う場合は、以下と連携してください： 暗号化 実装の詳細は「暗号化」を参照： コンプライアンス 実装の詳細は「コンプライアンス」を参照： Capgo セキュリティスキャナー Capgo セキュリティスキャナーの製品ワークフローについては： Capgo セキュリティ Capgo Security でのプロダクトワークフロー向け、および Capgo トラストセンター Capgo Trust Center でのプロダクトワークフロー向け。