CI/CDパイプラインでOTAアップデートをセキュアにする方法

あなたのCI/CDパイプラインでセキュアなOTAアップデートを実現したい場合は、以下のことを知っておく必要があります。 セキュアな通信プロトコルを使用する__CAPGO_KEEP_0__

• __CAPGO_KEEP_1__ 更新を保護するために、TLS 1.3、HTTPS、および SSL ピニングを実装します。
• 署名を暗号化キーで署名します: パブリック キー インフラストラクチャ (PKI) とセキュア ブートローダーを使用して、更新の整合性を検証します。
• 端末間で暗号化してください。 更新の全体的な安全性を確保するために、エンドツーエンド暗号化 (E2EE) を使用して、更新を保護します。
• CI/CD パイプラインをセキュア化する シークレット マネージャー ツールを使用して資格情報を管理し、ビルド環境を分離し、ロールベースのアクセス制御 (RBAC) を強制してください。
• セキュリティテストを自動化する デプロイ前に脆弱性を検出するためのスキャン (SAST、SCA、DAST) を実行してください。
• ロールバックの準備と監視 更新のパフォーマンスを追跡し、A/B 分割などのロールバックメカニズムを実装してください。
• 法的要件に準拠する Maintenance audit logs, app store guidelines, and approval workflows for critical updates to be followed.

CI/CD Pipelinesのセキュリティ対策 | Secure Software Delivery | OpsMx Delivery Shield

OTA更新の基本的なセキュリティ設定

OTA更新のセキュリティは、複数の保護層で構成されています: 安全な通信プロトコル、暗号化署名、端末間のエンドツーエンド暗号化。各層は特定のリスクに対処し、堅固な防御システムを構築します。

安全な通信プロトコルを使用する

デバイスと更新サーバー間の通信を保護するには、信頼性の高い安全なチャネルが必要です。 Transport Layer Security (TLS) ここでは、TLS 1.3が現在の標準です。データの送信中にデータを保護するために使用されます。 [1].

TLSを実装する際、デバイスはサーバーのアイデンティティを認証する必要があります。これは、オペレーティングシステムによって提供される証明書認証局の検証または事前配布されたキーを使用した自己署名証明書の検証で行うことができます。 [1]これにより、攻撃者が正当な更新サーバーを偽装することができなくなります。

HTTPS暗号化 __CAPGO_KEEP_0__は、クライアントとサーバー間のすべてのインタラクションで必須である必要があります。これにより、第三者攻撃を防ぐことができます [2]。 さらに、__CAPGO_KEEP_0__を使用すると、 SSLピンニング は、証明書の認可機関が不正に利用された場合でも、特定のSSL証明書のみを信頼するようにアプリケーションを確実にします [2].

通信プロトコルは、更新アクセスに接続する認証、インベントリデータの交換の保護、ステータス情報の配信の保護という3つの重要な役割を果たす必要があります [1]。 これらの各エリアは、適切に保護されていないと潜在的な脆弱性を表します

通信が確保されたら、次のステップは、暗号署名を使用して更新の整合性を保証することです

暗号署名による更新の署名

暗号署名により、更新パッケージは、改ざんされていないかつ信頼できるソースから得られていることを保証します 公開鍵基盤 (PKI) は、この目的の最も信頼できるフレームワークです [3].

ここでは、どのように機能するかを説明します。開発者は、更新パッケージをプライベートキーで署名し、デプロイメント前に署名します。デバイスは、署名を検証するために対応するパブリックキーを使用します。検証に失敗したパッケージは、拒否されます [3].

セキュアなブートローダーは、さらに保護の層を追加します。起動時には、ハッシュ関数やデジタル署名などの暗号化技術を使用して、ソフトウェアの有効性と完全性を確認します。 [3] code が正常に動作するように、悪意のあるものは実行されません。

長期的なセキュリティを維持するには、鍵の管理が不可欠です。以下は、異なる脅威レベルの取り扱いに関する簡単な参照表です。

更新の完全性を確保した後、最終ステップは、端末間の暗号化を実施することです。

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

エンドツーエンド暗号化(E2EE)は、ビルドシステムとユーザー端末間の全パスを暗号化することで、更新を安全に配信するための方法です。このアプローチにより、更新を配信するプラットフォームがコンテンツにアクセスまたは変更することができなくなります。データの改ざん、code インジェクション、配信中のデータ漏洩に対する保護が可能になります。

E2EEを実装するには、開発環境を離れる前に更新パッケージを暗号化する必要があります。暗号化キーを共有し、その有効性をターゲットデバイスで検証するための安全な鍵交換プロトコルを使用してください。強力な暗号化方法と安全な鍵管理がこのシステムの基盤となります。

プラットフォームとして Capgo このプロセスを簡素化するために、Capacitor アプリに組み込まれたエンドツーエンド暗号化を提供します。Capgo は暗号化プロセスを管理し、Apple と Android のセキュリティ要件に準拠しながら、カスタムシステムを構築する必要性を排除し、潜在的な脆弱性を軽減します。

CLI ツールを使用した暗号化の自動化は、さらにプロセスを簡素化できます。この手法は、人間のエラーを最小限に抑え、セキュリティ対策の適用をすべてのアップデートで一貫して行うことを保証します。CLI を CI/CD Pipelines に統合することで、開発速度や効率を損なうことなく、パッケージをデプロイ中にセキュア化できます。

CI/CD Pipelines に対する攻撃

CI/CD Pipelines は、OTA アップデートに悪意のある code を注入する攻撃者にとって魅力的な標的です。CI/CD Pipelines が侵害された場合、有害な code を迅速に配布することになります。このため、CI/CD Pipelines のセキュリティは最優先事項です。CI/CD Pipelines を保護するには、資格情報を保護し、ビルド環境を分離し、厳格なアクセス制御を実施する必要があります。これらの対策は、OTA アップデート配信のセキュリティを確保するための前提策と共に機能します。

資格情報と API キーの管理

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

現代のCI/CDプラットフォームでは、機密情報を安全に保管するためのツールが提供されています。これらのツールはビルド時に機密情報をインジェクトし、プロジェクトファイルやログに表示しないようにして、機密情報へのアクセスを許可されたユーザーだけに制限しています。 [5].

機密情報を管理するためのいくつかの人気のあるオプションはこちらです。

__CAPGO_KEEP_0__ [4]また、シングル サインオン (SSO) と マルチ ファクター アUTHENTICATION (MFA) を実装すると、資格情報ベースの攻撃のリスクが大幅に減ります。MFA alone はこのリスクを 90% 以上削減します。 [5].

ビルド エンドポイントの分離

ビルド エンドポイントを分離することはもう 1 つの重要なステップです。各ビルドは、残りの構成、キャッシュ ファイル、または未検証の依存関係のない、クリーンで安全な状態から始まる必要があります。 [5]これにより、ビルド間のクロス コンテナミーを減らし、セキュリティ上の目的でアウディットを簡素化します。

一時的なランナーまたはコンテナ化されたビルド、たとえば Dockerを使用すると、各ビルドに一貫したおよび分離された環境が確保されます。これらのコンテナは、既知の安全なベース イメージから始まり、脆弱性への露出を最小限に抑えることができます。

さらに、パイプラインを開発、テスト、生産環境に分割して、開発、テスト、生産環境を完全に分離することができます。 [7]。各ステージに必要な権限のみを付与することで、単一の侵害から生じる可能性のある損害を制限できます。 [8].

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

ロールベースのアクセス制御（RBAC）は、パイプラインとOTA更新の完全性を維持するために不可欠です。RBACは、チームメンバーが必要なロールに基づいてパイプラインのステージにアクセスできるようにします。このアプローチは、資格情報の保護と環境の分離に直接つながります。最小限の特権原則に従うことで、開発者、テスター、セキュリティレビュアー、デプロイメントマネージャーなどの明確なロールを定義できます。各ロールには、タスクに合わせた権限が割り当てられます。 [6].

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

• Jenkins: マトリックスベースのセキュリティとロール戦略プラグインを提供します。
• GitLab: プロジェクトレベルの権限とグループ管理をサポートします。
• GitHub Actions: リポジトリの権限と環境保護ルールを強制します。

ロールと権限を定期的に監査することで、不要なアクセスを特定し、現在の責任と一致する権限を保証できます。 [6]. センシティブなオペレーション、例えばプロダクション デプロイメントや構成変更に、多要素認証を必須にします。

一部のプラットフォーム、例えば Capgo、RBACを直接更新管理システムに統合します。これにより、特定のユーザーセグメントにアップデートをデプロイすることができるのは、管理者だけになります。開発者は、制御された環境で変更をテストすることができ、しかも、管理者以外のチームメンバーだけが、プロダクション デバイスにアップデートをプッシュすることができます。これにより、プロセスの制御が厳密になります。

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

自動セキュリティテストは、ソフトウェアがプロダクションに到達する前に、脆弱性を特定する上で重要な役割を果たします。2022年に、供給-chain攻撃が600%以上増加したため、CI/CDパイプラインに徹底的なセキュリティスキャンを組み込むことは不可欠です。これらの自動テストは、ユーザーを保護し、信頼を維持するために、ソースコードからデプロイメントまでの各段階でセキュリティを確保します。

デプロイメント前に実行するセキュリティスキャン

安全なアップデートメカニズムは基本的なものですが、デプロイメント前に実行するセキュリティスキャンは、脆弱性を早期に捕捉することで、さらに保護の層を追加します。このプロアクティブなアプローチは、開発の早い段階にセキュリティをシフトし、リスクを下流に最小限に抑えることで、リスクを最小限に抑えることができます。

静的アプリケーションセキュリティテスト (SAST) ツールは、ソース code を実行せずに分析します。開発中の潜在的な脆弱性を特定します。例えば、 Spectral はリアルタイムのフィードバックを提供し、偽陽性を最小限に抑えます。 [9].

ソフトウェア構成分析 (SCA) ツールはプロジェクトの依存関係を調べ、知られている脆弱性データベースと比較します。たとえば、npm-AuditはJavaScriptプロジェクト用のもので、NancyはGolangの依存関係用のもので、自動的に依存関係チェーン内で問題をマークします。 [10].

Dynamic Application Security Testing (DAST) ツールは静的ツールが見逃す可能性のある脆弱性を発見するために、実世界の攻撃シナリオをシミュレートします。無料のオプションとしては、Burp SuiteのDastardlyがCI/CDパイプライン向けに設計されています。 ZAP プロキシベースのトラフィック分析を提供して、リアルタイムで脆弱性を検出します。 [9] [10].

インフラストラクチャとしてCode (IaC) スキャニングツール、KICSやProwlerなどを使用して デプロイ設定を確認し、不正な設定が実装される前に、不正な設定を検出する OTA更新インフラストラクチャを不正な設定から保護するために、このステップは非常に重要です。 監視と問題の検出更新が安全にデプロイされた後、継続的な監視により、リアルタイムで問題が検出されます。このステップでは、更新が失敗した、未承認のアクセス試行、またはセキュリティ侵害の兆候となる不通常のネットワークアクティビティを検出します。 [10].

更新成功監視

ダウンロード成功率、インストール完了率、更新後のデバイスの健康状態などのメトリックを追跡します。突然のメトリックの低下や不正なエラーのパターンが、不正な更新またはセキュリティ上の懸念を示す可能性があります。

• ネットワークアクティビティ分析 更新中のトラフィックの動作を監視します。不正なデータ転送、未承認サーバーへの接続、不通常の帯域幅使用など、不正な更新または中間者攻撃の兆候となる不明なデータ転送を検出します。
• デバイス動作監視 __CAPGO_KEEP_0__
• __CAPGO_KEEP_0__ アップデート後、デバイスのパフォーマンスに異常が見つかる。たとえば、CPU、メモリ、またはネットワーク使用量のスパイクは、悪意のある活動の兆候となる可能性があります。デバイスのファリットでテレメトリー データを収集することで、これらのパターンをより迅速に特定できます。

プラットフォームのCapgoは、CI/CD ワークフローにリアルタイムのアップデート追跡を統合することで、監視を簡素化します。このような監視は、必要な場合に迅速なロールバックと回復アクションを可能にします。

ロールバックと回復オプションの設定

自動ロールバックシステムは、更新が失敗したり、セキュリティ上の問題を引き起こしたりした場合に、デバイスの機能性を維持するために不可欠です。デュアルバンク (A/B 分割) セットアップにより、常にバックアップのファームウェア バージョンが利用可能になります。システムは新しいアップデートを検証し、検証が失敗した場合には、前の信頼されたバージョンに自動的に戻ります。 [11].

その他の対策として、ウォッチドッグ タイマーや「ステージド ロールアウト」があります。ステージド ロールアウトは、潜在的な問題の影響を制限し、必要な場合に迅速なロールバックを可能にするために、デバイスの小さなグループから始まり、徐々に拡大します。 回復テストも同様に重要です。実際の状況下で、ロールバック機構が機能することを確認するために、電源の喪失、ネットワークの切断、またはダウンロードの不正化などの失敗シナリオをシミュレートします。ただし、セキュリティ チームのうち現在、DevSecOpsの完全な実践を採用しているのは36％のみです

Platforms like __CAPGO_KEEP_0__ simplify monitoring by integrating real-time update tracking directly into your CI/CD workflows. This kind of oversight enables swift rollback and recovery actions when needed. Automated rollback systems are essential to maintaining device functionality when updates fail or introduce security issues. A dual-bank (A/B partitioning) setup ensures there’s always a backup firmware version available. The system validates new updates, and if any checks fail, it reverts to the previous trusted version automatically [11].

Other measures, such as watchdog timers and "staged rollouts", further reduce risks. Staged rollouts begin with a small group of devices and gradually expand, limiting the impact of potential issues and enabling quick rollbacks when necessary. [10]自動セキュリティテストをパイプラインに統合することで、防御力を強化できます。複数のセキュリティアセスメントを統合するツールを使用すると、プロセスを簡素化し、CI/CD パイプラインが厳格なセキュリティ要件を満たすことができます。

法的要件と監査要件の対応

OTA更新を実行する場合、規制遵守は単にチェックボックスをチェックすることだけではありません。組織とユーザーの両方の安全を確保するための重要な防御機関です。強力な更新配信とセキュアなCI/CD実践を組み合わせると、法的要件を満たすための強固な基盤を構築できます。

永久的な監査ログの作成

監査ログは、すべての変更とアクセスイベントを追跡するために不可欠です。JSONまたはsyslog形式でデプロイメントアクティビティをキャプチャする場合、ログは完全なトレースを保証します。 [12][13].

中央集権化されたログ管理はここで重要な役割を果たします。CI/CDコンポーネントからログを単一の場所に集約すると、イベントを分析および関連付けし、不正活動を検出し、監視を簡素化することができます。セキュリティ情報とイベント管理 (SIEM) プラットフォームまたは中央集権化されたログ管理システムにログを送信すると、潜在的な脅威に対する監視と対応能力が向上します。 [13].

CI/CD Pipelinesのリアルタイムモニタリングは、不正な変更や不審なアクセスパターンなどの異常を発見するために不可欠です。セキュリティ問題が発生したときにチームに通知するための警告機構を実装するようにしてください。ただし、チームを誤検知で圧倒しないように、警告を適切に設定するようにしてください。 [12][13].

「セキュリティは後から追加するものではない、基盤です。最初からパイプラインに組み込んでください。後で補完することなく、攻撃者から清掃することなく、ギャップを修正する痛みを避けます。」 - SpectralOps [14]

監査ログの定期的なレビューにより、実際に必要な人だけにアクセスを制限し、セキュリティ上の問題を示唆する不一致を発見できます。ログの実践は、組織のポリシーと規制の要件に準拠していることを確認し、監査ログの実践を組織のポリシーと規制の要件に合わせるようにしてください。 [13].

App Storeガイドラインに従う

AppleとGoogleは、OTA更新を含む厳格なセキュリティプロトコルとユーザーの同意要件を含む厳格な規則を強制しています。 Capgoのようなツールは、これらのプラットフォームセキュリティ基準に沿った機能を組み込んでいます。

セキュリティの他に、ユーザー体験の平滑性を強調するApp Storeガイドラインがあります。更新はコア機能に影響を与えないようにし、ユーザーに重大な変更について通知する必要があります。また、更新頻度とファイルサイズに関するプラットフォーム固有の規則に従う必要があります。これにより、ポリシー違反を避けることができます。

ドキュメントはもう一つの重要な要素です。更新内容、セキュリティ対策、その影響をユーザーに伝えるための詳細な記録を維持する必要があります。これらの記録は、App Storeのレビューをサポートするだけでなく、プラットフォームガイドラインへの取り組みを示すものです。

承認ワークフローの設定

自動化はセキュリティとコンプライアンスを強化しますが、構造化された承認ワークフローは、人間の監視の重要な層を追加します。たとえば、リリースアクティベーションに複数人のレビューを必要とすることで、更新が徹底的な検査を受けるようにします。 [15].

役割ベースのパーミッションはここで不可欠です。特定の責任を割り当てる必要があります。たとえば、 senior developers codeの変更を承認し セキュリティスペシャリスト 暗号化とコンプライアンス対策を検証する必要があります。このアプローチにより、更新が適切な専門家によってレビューされるようになります。

階層型の承認システムはプロセスをさらに細分化できます。たとえば:

• Minor bug fixes might require only a single approver.
• Major updates or security patches should involve multiple reviewers from different teams.

Integrating approval workflows with your existing project management and communication tools can streamline the process. Automated notifications keep reviewers informed when their input is needed, while detailed change logs provide the context necessary for informed decisions. Monitoring approval times and identifying bottlenecks can help optimize the workflow without compromising security.

CapgoのセキュアなOTAアップデートのベストプラクティス

セキュアなオーバー・ザ・エア（OTA）アップデートのCI/CDパイプラインは、自動化と細心の注意を必要とする混合です。未修正のファームウェアはIoTセキュリティの 60%の脆弱性 [16]を引き起こします。

これらのベストプラクティスは、ユーザーとビジネスを守るために必須です。

CapgoのセキュアなOTAアップデートの4つの重要な要素 ファームウェアのアップデートパッケージを送信中の改ざんを防ぐために end-to-end encryption を使用します。2つ目は、 __CAPGO_KEEP_0__をユーザーのデバイスに到達するように検証された更新のみを保証します。

CI/CD パイプラインの次のレイヤーは、適切な資格情報管理、分離されたビルド環境、およびロールベースのアクセス制御を使用して、誰もが更新を展開できないようにすることです。

自動検証 は別の重要なステップです。デプロイメント前のセキュリティスキャン、自動テスト、継続的な監視は、脆弱性を早期に検出できます。検査ログと承認ワークフローを組み合わせると、強力なセキュリティチェックポイントを確立できます。

これらの機能を組み合わせると、OTA更新プロセスを高度化するために使用する専門ツールを使用するための堅固な基盤が作成されます。

使用するツールとして Capgo

コアセキュリティ慣行を確立した後、 Capgo のようなプラットフォームは実装を容易にします。 750アプリで23.5万回の更新を実行したCapgo

Capgo simplifies security by offering end-to-end encryption と

CI/CD統合のためのシームレスな実行、手動の設定が多く脆弱性につながることが多いことを減らす。さらに、AppleとAndroidの要件に準拠しているため、更新に焦点を当てることができる。アプリストアのガイドラインに気にする必要がない。 The platform also provides ロールバック機能

と

バージョン管理機能、更新が問題を引き起こすときの重要な安全装置として機能する。更新が不正に機能している場合、問題を解決するのではなく、安定したバージョンに戻り、問題を解決することができる。リアルタイムの分析機能と組み合わせると、問題が発生するたびにそれに応じて問題に応えることができる。

Start by auditing your current CI/CD pipeline for security gaps. Pay close attention to credential management - ensure that API keys, signing certificates, and other sensitive data are stored securely and accessed only by authorized processes.

セキュアなOTA更新のための準備 を始めるには、現在のCI/CDパイプラインをセキュリティのギャップで検査する。資格情報の管理に注意してください - __CAPGO_KEEP_0__ キー、署名証明書、他の敏感なデータは安全に保存され、承認されたプロセスによってのみアクセスされることを確認する。

Encrypt every step of the update process. This includes encrypting update packages, using HTTPS for communications, and securing your build environment. Set up logging and monitoring tools to maintain full visibility into your pipeline. すべてのステップを暗号化する。更新パッケージの暗号化、HTTPS通信の使用、ビルド環境の保護を含む。ログと監視ツールを設定して、パイプライン全体の完全な視野を維持する。 重要な更新のために、即時パッチは自動化されても、主な変更に対する人間のレビュープロセスを追加することで、セキュリティの追加レイヤーを実現します。時間の経過とともに、これらのワークフローをスピードと監視のバランスをとるように改良してください。

最終的には、ロールバック手順のテストと、季節ごとのセキュリティレビューを実施して、出現する脅威に先んじてください。対応に備えることで、セキュリティインシデントに際しては、すべての差がつきます。

FAQs

::: faq

CI/CD PipelinesにおけるOTA更新の主なセキュリティリスクとは何か、開発者はどのように対処するか?

CI/CD PipelinesにおけるOTA更新には、以下のようなリスクが伴います。 データの盗聴, code の改ざんサーバーブレーチ これらの脆弱性は、アプリの完全性を損なう、敏感なユーザー情報を露呈する、または未承認の更新を通過させることを許す可能性があります。これらの課題に対処するには、開発者は、以下のようなセキュリティ対策に焦点を当てる必要があります。

FAQs end-to-end encryption, code signing, および HTTPS などの安全なプロトコルを使用することで、更新プロセスを強化します。 強力な認証方法を追加し、定期的なセキュリティアウディットを実施することで、更新プロセスをさらに強化します。 Capgo のようなツールは、このプロセスを簡素化する機能を提供することができ、暗号化された更新、Smooth CI/CD統合、AppleおよびAndroidのガイドラインへの準拠などが含まれます。

開発者がユーザーに安全な体験を提供し、業界標準を満たすことができるように、 OTA更新をセキュアかつ信頼できるようにするには、以下の戦略を実施する必要があります。 :::

::: faq

OTA更新を暗号化署名することでどのように保護されるか、および Public Key Infrastructure (PKI) の役割は何ですか?

暗号署名は、OTA更新が安全かつ信頼できるものであることを保証する上で重要な役割を果たします。 Public Key Infrastructure (PKI) を利用することで、開発者は更新パッケージを署名するためにプライベートキーを使用します。 受信側のデバイスは、対応するパブリックキーを使用して、2 つのことを確認します: 更新は信頼できるソースから来ていること、そして、送信中の更新が改ざんされていないこと。 この方法は、未承認または有害な更新をブロックすることで、デバイスの機能とセキュリティを保護します。 CI/CD パイプラインに PKI を統合することは、セキュアな OTA 更新を維持する上で不可欠な措置です。 :::::: faq

CI/CD パイプライン内で OTA 更新の際に、資格情報と __CAPGO_KEEP_0__ キーをセキュアに保つためのベストプラクティスは何ですか?

__CAPGO_KEEP_0__

API

To keep credentials and API keys safe in a CI/CD pipeline during OTA updates, here are some key steps to follow:

• 機密情報を安全に保管する: CI/CD pipeline内でのOTA更新で機密情報を安全に保管するために、環境変数やセキュアなボールトを使用する。コードベースに機密情報を埋め込むのではなく、機密情報を保護し、環境間で設定を管理することが容易になる。

• 権限を制限する: __CAPGO_KEEP_0__ キーとクレデンシャルに必要な最小限のアクセス権を割り当てる。機密情報を定期的にローテーションする習慣を身につけ、潜在的なリスクを最小限に抑える。

• 自動で漏洩を検出する: __CAPGO_KEEP_2__ のようなツールを使用して、不意に漏洩した情報を早期に検出する。詳細なログと監視を組み合わせて、不正アクセス試行を迅速に検出して対応する。 git-secrets __CAPGO_KEEP_0__ アプリとプラットフォームを使用している場合は、__CAPGO_KEEP_1__ などのツールを使用すると、CI/CD統合が簡単になります。エンドツーエンド暗号化やユーザー固有の更新割り当てなどの機能が提供されます。これらのツールを使用すると、OTA更新が安全かつ法的かつ確実に実行できます。 :::

For those working with Capacitor apps, platforms like Capgo simplify CI/CD integration by offering features such as end-to-end encryption and user-specific update assignments. These tools help ensure your OTA updates are both secure and compliant. :::

Capacitorを使用している場合は、CI/CD pipeline内でのOTA更新のセキュリティについては、次の記事を参照してください。

If you are using __CAPGO_KEEP_1__ Capacitorを使用している場合は、CI/CD pipeline内でのOTA更新のセキュリティについては、次の記事を参照してください。 セキュリティとコンプライアンスの計画に役立つように 暗号化 __CAPGO_KEEP_0__ セキュリティ スキャナの実装詳細 コンプライアンス __CAPGO_KEEP_0__ セキュリティ スキャナの製品ワークフロー Capgo セキュリティ Capgo トラスト センターの製品ワークフロー Capgo Security for the product workflow in Capgo Security, and Capgo Trust Center Capgo セキュリティ スキャナ