衛星制御ソフトウェアの取得: ソース コード、アクセス、サプライ チェーン デリジェンス

導入

ソフトウェアは、衛星、地上ネットワーク、通信事業者、顧客、規制当局の間に位置します。ミッションコントロールシステムは、連絡の計画、コマンドの検証と送信、テレメトリの受信と処理、宇宙船の状態の監視、軌道の計算、ペイロードスケジュールの管理、運用記録の保存を行います。欠陥、利用できない依存関係、またはアクセスできない署名キーは、基盤となる宇宙船が技術的に正常な場合でも、収益を中断し、コマンドの権限を弱める可能性があります。

したがって、買収には従来のソフトウェア製品のレビュー以上のものが必要になります。購入者は、ミッションシステムが操作されることを理解する必要があります。そのシステムには、ソース リポジトリ、ビルド パイプライン、構成データ、展開環境、暗号化マテリアル、グラウンド インターフェイス、ランブック、サプライヤー サービス、エンジニアリング上の判断、および契約上の権利が含まれます。これらの要素のいくつかは、ターゲットの法人の外に存在するか、指定された個人に依存している可能性があります。

この文書では、その問題に対するトランザクションのフレームワークを説明します。これは、ソフトウェア主導の宇宙取引を評価する戦略的買収者、インフラ投資家、民間資本会社、衛星運用者、貸し手および取締役会向けに設計されています。制御、継続性、価格、条件、統合設計を変更する証拠に焦点を当てます。

1 獲得した能力を定義する

The buyer should begin with a capability statement. The statement identifies which missions, spacecraft, payloads, ground sites, customer services and operational decisions the software supports. It records service windows, availability expectations, safety consequences, regulatory obligations and revenue dependencies. 1 つのブランドのプラットフォームが個別の飛行力学、計画、ID、データベース、監視、および地上局サービスに依存している可能性があるため、製品名だけでは信頼性の低い境界を提供します。

能力記述では、飛行ソフトウェアと地上ソフトウェアを区別する必要があります。衛星制御による捕捉は通常地上セグメントに焦点を当てますが、運用上の価値は組み込みの飛行インターフェースと宇宙船固有のコマンド データベースに依存する場合があります。購入者は、ターゲットが継続的な運用に必要なすべてのインターフェイスを使用、変更、転送できるという証拠を必要とします。

境界では、除外されたサービスも特定する必要があります。共有の企業アイデンティティ、クラウド サブスクリプション、通信リンク、キー管理サービス、データ センター、または親会社のスタッフが初日から不可欠になる場合があります。それぞれの除外は移行要件となり、依存関係または値の調整が継続されます。

2 所有権、アクセス、制御を分離する

法的所有権は管理の 1 つの要素です。購入者には、物理​​的または論理的なアクセス、変更と展開のための十分な権限、操作のための知識、資格情報とリリースの決定に対する権限も必要です。これらの要素は分岐する可能性があります。 A target may own custom source code while relying on a non-transferable library.運用ビルドはコンサルタントのプライベート ツールチェーンに依存しますが、リポジトリを所有する場合があります。政府の顧客が展開の承認を管理している間、広範なライセンスを保持している可能性があります。

ディリジェンスモデルでは、所有権、所有権、アクセス権、変更権、頒布権、運用権限、終了権を個別に記録する必要があります。各項目には証拠書類が必要です。関連する証拠には、割り当て、雇用条件、請負契約、ライセンス スケジュール、リポジトリの許可、展開記録、顧客契約、サプライヤーの確認が含まれます。

制御には時間の側面もあります。ディリジェンス中に存在したアクセスは、終了時に期限切れになる場合があります。購入者は、リポジトリへのアクセス、クラウドのテナント、署名権限、管理者の資格情報、監視履歴、および取引境界を通じたサプライヤーのサポートを保持するために必要な正確なアクションを特定する必要があります。

3 ソフトウェアと依存関係のインベントリを作成する

インベントリでは、アプリケーション、サービス、リポジトリ、ブランチ、ビルド システム、展開パッケージ、データベース、インターフェイス、商用製品、オープンソース コンポーネント、暗号化ライブラリ、および操作スクリプトを識別する必要があります。各コンポーネントを、それがサポートするミッション機能とそれが実行される環境に接続する必要があります。

SBOM により、コンポーネントの検出を加速できます。営業在庫を置き換えるものではありません。有用な取得インベントリは、コンポーネント名とバージョンをソース、ライセンス、メンテナー、脆弱性ステータス、ビルド アーティファクト、デプロイされた構成、データの依存関係、および置換パスにリンクします。コンテナ、ファームウェア、またはベンダー アプライアンスに組み込まれたコンポーネントは、従来のアプリケーション リストに含まれていない可能性があるため、注意が必要です。

購入者は、エンジニアリングが存在するとしているもの、リポジトリに含まれるもの、本番テレメトリが実行を示しているものという 3 つの観点を調整する必要があります。違いは勤勉な結果です。記録されていないサービスは重要である可能性があります。リストされているリポジトリは廃止されている可能性があります。実稼働バイナリは、承認されたソース コミットまで追跡できない場合があります。

4 ソースコードの完全性をテストする

Repository access should cover the full product and its history.購入者は、ソース、構成、インフラストラクチャ定義、データベース スキーマ、テスト資産、ビルド スクリプト、展開の自動化、ドキュメント、および問題履歴を検査する必要があります。選択したファイルのスナップショットでは完全性を示すことはできません。

Completeness testing starts from deployed artefacts.チームは代表的な運用バイナリまたはコンテナを特定し、それらをソース リビジョン、依存関係バージョン、ビルド パラメータ、承認記録まで追跡します。 It then builds the software in a controlled environment and compares the result with the deployed artefact or its documented provenance.違いについては説明が必要です。

生成されたコードは個別に処理する必要があります。 NASA のガイダンスでは、長期的なメンテナンスにはモデル、シミュレーション、データ定義、ジェネレーター、ビルド データ、テスト スクリプト、および期待される結果へのアクセスが必要になる可能性があることを認識しています。ジェネレーター、モデル、または認定された構成が欠落している場合、生成されたソースの所有が不十分になる可能性があります。

5 ビルドを再現する

再現可能なビルドは、価値の高い勤勉なテストです。目的は、承認されたチームが文書化されていない介入なしで、制御された入力から展開可能なリリースを作成できることを示すことです。テストではクリーンな環境とターゲットの文書化された手順を使用する必要があります。購入者の観察者は、前提条件、外部ダウンロード、資格情報、手動手順、ツールのバージョン、警告および逸脱を記録する必要があります。

既存のプロセスが確定的コンパイルをサポートしていない場合、結果はビットごとに同一である必要はありません。合意されたテストの下で追跡可能であり、機能的に同等である必要があります。購入者は、なぜ違いが生じるのか、そのプロセスで整合性が保たれるのかを理解する必要があります。

ビルドに失敗すると、ライセンスの不足、証明書の期限切れ、利用できないパッケージ リポジトリ、文書化されていないパッチ、または指定されたエンジニアへの依存が明らかになる可能性があります。これらの調査結果は、移行コストと継続性リスクに直接関係します。購入契約では、クロージング前にクリーンビルドが成功することを要求したり、条件が満たされるまでエスクローに検討を置いたりすることができます。

6 リリースおよび展開権限のトレース

Source access does not establish the ability to operate production. The buyer should trace authority from code approval through build, signing, release, deployment and rollback.トレースは、変更を承認できる人、署名資格情報を保持している人、パッケージの保存場所、環境の昇格方法、および緊急リリースの制御方法を識別します。

Satellite-control changes can have mission-safety consequences.リリースの証拠には、検証結果、運用準備レビュー、構成の承認、該当する場合は顧客または当局の同意、およびテストされた回復ルートが含まれている必要があります。購入者は、定期的なアプリケーションのリリースと、コマンドの検証、飛行力学、テレメトリの解釈、または暗号の信頼性に対する変更を区別する必要があります。

資格情報の転送には、設計されたプロセスが必要です。秘密キーと特権資格情報は、終了中に不用意にコピーしないでください。当事者は、ローテーション、取り消し、再登録、二重管理、監査の保存、およびロールバックについて合意する必要があります。 The closing plan should state when operational authority changes and how ambiguous responsibility is avoided.

7 ミッション構成データの調査

ミッションコントロール ソフトウェアは、ソース コードと同じくらい価値のある構成に依存しています。コマンド辞書、テレメトリ定義、制限、校正データ、宇宙船モデル、接触計画、軌道パラメータ、自動化ルール、顧客ルーティングによって、汎用ソフトウェアが実際のフリートとどのように相互作用するかが決まります。

購入者は、各構成クラスの信頼できるソース、その承認プロセス、バージョン履歴、および回復方法を特定する必要があります。管理されたレコードから新しい環境を設定できるかどうかをテストする必要があります。スプレッドシートベースの構成やローカルに保存された構成では、レビュー、リネージュ、バックアップが不足しているとリスクが生じます。

構成権限も重要です。顧客、宇宙船メーカー、またはシステム インテグレーターは、データの一部を所有または制限する場合があります。買収契約では、譲渡、継続使用、機密保持、輸出制限、削除義務について言及する必要があります。 Missing configuration can make otherwise complete software unusable for a specific mission.

8 ソフトウェア保証の証拠を評価する

ソフトウェア保証の証拠は、製品が管理された実践を通じて開発および保守されたかどうかを示します。 NIST の SSDF は、組織の準備、ソフトウェアの保護、安全性の高いソフトウェアの作成、脆弱性への対応を中心に安全な開発を組織しています。 NASA ソフトウェア保証ガイダンスは、安全性とミッションの状況に関する客観的な証拠を追加します。

購入者は、要件のトレーサビリティ、アーキテクチャの決定、コード レビュー、静的分析、依存関係のスキャン、テスト カバレッジ、リリースの承認、欠陥履歴、脆弱性への対応を確認する必要があります。証拠は本番環境のバージョンに対応している必要があります。実行された記録のないポリシー文書では、限定的な保証が提供されます。

デリジェンス チームは、コマンド生成、認証、権限管理、軌道決定、回復などのクリティカル パスをサンプリングする必要があります。テストが不利な条件や境界条件をカバーしているかどうかを検討する必要があります。 Open findings should be classified by mission consequence, exploitability, recoverability and remediation dependency.

9 ソフトウェアサプライチェーンの地図を作成する

サプライ チェーンには、商用ベンダー、オープンソース プロジェクト、クラウド プロバイダー、ビルド サービス、パッケージ リポジトリ、ハードウェア サプライヤー、コンサルタント、専門オペレーターが含まれます。購入者は、どの当事者が製品を変更、中断、アクセス、または制限できるかをマッピングする必要があります。

重要なサプライヤーごとに、契約上のサポート、財務上の回復力、セキュリティ慣行、アクセス権限、インシデント通知、変更管理、サポート終了ポリシー、データの場所、および代替のリードタイムを含めたデリジェンスを行う必要があります。 A supplier that supports several mission-critical components creates concentration even when annual spend is small.

NIST SP 800-161 は、サプライチェーンのリスクを調達チェックリストではなく組織ガバナンスの問題として扱います。取引チームは、サプライヤーの証拠をシステムの重要性と計画された所有権に結び付ける必要があります。材料サプライヤーは、クロージングの前に同意、更改、または直接合意を必要とする場合があります。

10 オープンソースの暴露を分析する

オープンソース コンポーネントにより、機能が向上し、開発時間が短縮されます。 They also create licence, maintenance and security obligations. The buyer should reconcile declared components with code scanning and build manifests.ライセンス条項、変更、通知、配布方法、既知の脆弱性を特定する必要があります。

コピーレフトの暴露には、実際の使用と配布に基づいた法的分析が必要です。ライセンスラベルだけでは義務は確立されません。 The team should document how components are linked, deployed, modified and provided to customers. Remediation can involve notice correction, source offers, component replacement or customer communication.

メンテナンス状況が価値に影響します。アクティブなメンテナやサポートされているリリースが存在しない重要なライブラリには、内部所有権が必要になる場合があります。購入者は、フォーク戦略、テスト範囲、パッチ機能、コミュニティへの依存性を評価する必要があります。ソフトウェア部品表は、クロージング後も静的なディリジェンス成果物になるのではなく、最新の状態を維持する必要があります。

11 知的財産の出所を確認する

すべての重要なコードの貢献には、防御可能な出所パスが必要です。職務発明は、適切な雇用条件内に収まる必要があります。請負業者の作業は十分な範囲で割り当てられる必要があります。 Acquired or contributed code should carry the necessary rights. University, government or customer-funded development can include restrictions that require detailed review.

The team should sample commit history against contributor records and contracts. Unrecognised authors, personal accounts or unexplained bulk imports deserve investigation.貴重な知的財産はソース ファイル以外にも及ぶため、レビューにはドキュメント、モデル、テスト データ、ユーザー インターフェイス、アルゴリズムが含まれる必要があります。

特許および営業秘密の分析は、実際の製品と商業計画に焦点を当てる必要があります。買い手は、防御登録、操作の自由、秘密保持管理、および営業秘密の保護を弱める可能性のある開示について理解する必要があります。 Transaction documents can allocate specific provenance risks through warranties, indemnities, escrows or contingent consideration.

12 特権アクセスと分離のテスト

ミッションコントロール環境には強力な権限が集中します。管理者は、コマンド、ID、データベース、クラウド リソース、署名キー、監視を制御できます。購入者は、開発、テスト、実稼働、およびリカバリ環境にわたる人間、サービス、および緊急アカウントをカバーする特権インベントリを取得する必要があります。

The review should test joiner, mover and leaver controls;多要素認証。承認;セッションログ;資格情報のローテーション。ガラス破りによるアクセス。開発と運用の分離。共有アカウントまたは休眠アカウントは説明責任を軽減します。サービス アカウントには所有権とライフサイクル制御が必要です。

閉鎖するとアクセスリスクが高まります。 Departing personnel may retain credentials or knowledge of recovery paths.移行計画では、機密の資格情報をローテーションし、古いアクセスを取り消し、証拠を保存し、二重の運用範囲を維持する必要があります。アクセスの喪失が実際のミッションに影響を与える可能性がある場合、これらのアクションをリハーサルする必要があります。

13 脆弱性管理の見直し

購入者は、脆弱性がどのように発見され、優先順位付けされ、修復され、伝達されるのかを理解する必要があります。ソースには、静的分析、依存関係スキャン、侵入テスト、顧客レポート、サプライヤー勧告、運用監視が含まれます。 The programme should define severity, mission consequence, remediation timing, exception approval and retesting.

Backlog analysis can reveal hidden maintenance requirements.購入者は、経過期間、再発、影響を受けるバージョン、およびクロージャの品質を調査する必要があります。カウントが低い場合は、検出が弱いことを反映している可能性があります。カウントが高い場合は、アクティブな検出を反映している可能性があります。有用な尺度は、関連するエクスポージャを特定し、リスクベースの時間枠内でそれを削減する組織の能力です。

Flight and ground systems may have limited patch windows.ターゲットは、補償制御をどのように適用し、安全なリリースを計画するかを示す必要があります。アクセスできないコンポーネントや耐用年数が終了したコンポーネントの既知の脆弱性は、特定の価格控除や資金による修復準備金を正当化する可能性があります。

14 インターフェースと相互運用性の評価

衛星制御ソフトウェアは、宇宙船、地上局、ネットワーク、ID システム、顧客プラットフォーム、気象データ、軌道データ、規制サービスとのインターフェースに依存します。購入者は、プロトコル、バージョン、所有者、パフォーマンス要件、セキュリティ制御、テスト環境、および各インターフェイスの変更プロセスを棚卸しする必要があります。

インターフェイスのドキュメントは、観察されたトラフィックと現在の構成に対してテストする必要があります。 Proprietary or undocumented interfaces create lock-in.標準プロトコルには、置き換えを複雑にする顧客固有の拡張機能が含まれている場合があります。

チームは故障モードをテストする必要があります。データの遅延、メッセージの重複、クロック エラー、入力の破損、ネットワークの中断、サービスの部分的な損失が観察されるはずです。回復動作は運用上の価値に影響します。統合計画では、インターフェイスの可観測性を維持し、複数の重要な依存関係を一度に変更することを避ける必要があります。

15 データの権利と記録を評価する

運用データは、モニタリング、異常分析、モデルの改善、顧客レポート、および規制上の証拠をサポートします。購入者は、テレメトリ、コマンド、派生製品、ログ、顧客情報、およびトレーニング データの所有権、保管権、許可された使用、保持、および輸出の権利を区別する必要があります。

トランザクション境界には、システムの運用と改善に必要な履歴データを含める必要があります。購入者は、アラートを調整したり異常を調査したりするための十分な操作履歴がないソフトウェアを受け取る可能性があります。データ移行では、タイムスタンプ、出所、アクセス制御、証拠の完全性を保持する必要があります。

プライバシーとローカリゼーションの義務は、担当者と顧客のデータに適用される場合があります。輸出規制や国家安全保障上の制限は、技術データや外国人によるアクセスに影響を与える可能性があります。法的分析では、義務を実際のデータセットと運営場所にマッピングする必要があります。

16 運用上の回復力と回復性を検討する

回復力テストでは、インフラストラクチャ、ソフトウェア、サプライヤー、人的障害が発生してもサービスがどのように継続するかを示す必要があります。購入者は、冗長性、バックアップ、回復環境、通信の代替手段、手動手順、回復目標、および実行結果を確認する必要があります。

A backup is useful only when it can be restored within the mission's tolerance.デリジェンス チームは、代表的な復元を観察し、構成、認証情報、依存関係、データの整合性を検証する必要があります。 Recovery should include the ability to rebuild systems when the primary environment or supplier is unavailable.

買収自体は回復力イベントとして扱われる必要があります。企業システム、ドメイン、クラウド アカウント、サポート契約は変更される場合があります。詳細なカットオーバー計画、ロールバック基準、指揮権限、共同インシデントプロセスにより、移行リスクが軽減されます。

17 人材と知識の集中を評価する

ソフトウェアの継続性は、アーキテクチャ、ミッション、異常、顧客、運用上の判断を理解している人々に依存します。購入者は役割を重要なプロセスにマッピングし、単一の知識点を特定する必要があります。組織図から得られる証拠は限られています。マップには、誰が実際にインシデントを解決し、リリースを承認するかを反映する必要があります。

保持の決定は、技術的な重要性と独立性の両方を考慮する必要があります。集中した知識は、ペアリング、文書化、リハーサル、継承を通じて削減できます。知識移転のマイルストーンを設けずに維持費を支払うと、依存度が軽減されるのではなく、依存度が維持される可能性があります。

取引モデルには、採用、維持、請負業者の転換、およびトレーニングのコストを含める必要があります。移行期間内に能力を移転できない場合、キーパーソンのリスクが評価に影響を及ぼす可能性があります。管理者は、指定された知識移転証拠に基づいて進捗状況を報告する必要があります。

18 顧客と規制当局の受け入れを確認する

顧客契約では、ソフトウェアのパフォーマンス、セキュリティ、監査、承認、および変更の義務を定義できます。購入者は、同意、通知、再認定、または指定された担当者を必要とする契約を特定する必要があります。自動的に移転される収益と、顧客の受け入れに依存する収益を区別する必要があります。

政府および重要インフラの顧客は、技術データ、セキュリティ許可、ホスティングまたはサプライチェーンの制限を課す場合があります。買い手は、その所有権、資金調達、人材、運営モデルが引き続き適格であるかどうかを評価する必要があります。規制上のライセンスと周波数帯の権利は、サービスの提供に不可欠なままでありながら、ソフトウェア エンティティの外部に存在する場合があります。

商用モデルでは、不確実な更新と同意を確率的に重み付けする必要があります。 Consideration can be contingent on verified transfer or retained revenue. The buyer should avoid paying full value for contracts whose operating prerequisites do not transfer.

19 勤勉さを評価に結びつける

ソフトウェア ディリジェンスは、キャッシュ フロー、タイミング、リスク、オプションの寿命を通じて価値を変化させます。修復するとコストが増加します。権利が失われると、対応可能な収益が減少する可能性があります。運用上の脆弱性により、停止の可能性が高まる可能性があります。ビルドコントロールが弱いと、製品開発が遅れる可能性があります。強力な証拠は、統合準備金の削減と更新に対するより高い信頼性を裏付けることができます。

評価ブリッジでは調整の重複を避ける必要があります。経常的なサポート費用は、予測キャッシュ フローに含まれます。 1 回限りの再構築は、トランザクションまたは統合の使用に属します。二項権利の欠陥には、割引率プレミアムではなく、除外、エスクロー、または条件が必要になる場合があります。

The buyer should show base, downside and severe cases.それぞれのケースでは、運用上の前提条件、証拠、および管理アクションを特定する必要があります。 Terminal value should reflect ongoing maintenance, component obsolescence, supplier concentration and the ability to refresh the product.

20 調査結果をトランザクションの仕組みに変換する

Material findings should have an owner and a transaction response.考えられる応答には、価格引き下げ、ホールドバック、エスクロー、アーンアウト、補償、クロージング条件、規約、移行サービス、ライセンスの刷新、キーパーソンの取り決め、または資産の除外などが含まれます。

条件は客観的にテスト可能である必要があります。完全なソースを提供するという要件は、定義されたリポジトリ、ブランチ、成果物、受け入れテストがなければ弱いものです。ビルド条件では、環境、入力、成功したテスト スイート、および展開パッケージを指定できます。 An access condition can specify identities, privileges, keys and verified login.

The disclosure process should preserve versioned evidence.購入者は、どのアーティファクトが各表現をサポートしているか、および誰が例外を受け入れたかを記録する必要があります。 Technical schedules need review by engineering and counsel so that legal language corresponds to operational reality.

21 閉鎖制御室の設計

Closing should be managed as an operational change.コントロール ルームは、法的手続きの完了、資格情報の移転、サプライヤーの刷新、クラウド テナント、コード リポジトリ、署名機関、顧客への通知、監視、およびインシデントの対応を調整します。

計画では、明示的なゴー、ホールド、ロールバック基準を使用する必要があります。各ステップでは、証拠、タイミング、責任者、フォールバックを特定します。重要なアクセスは、取り消し不能なアクションが発生する前にテストする必要があります。当事者は、最もリスクが高い期間中、共同補償を維持する必要があります。

購入者はログと構成スナップショットを保存する必要があります。これらの記録は転送時の状態を確立し、後の調査をサポートします。クローズ後の最初のリリースは、即席の統合テストになるのではなく、合意された保証プロセスに従う必要があります。

22 最初の 100 日間を確立する

The first 100 days should stabilise control, close priority evidence gaps and reduce concentration.初期のアクションには、アクセスの再認証、資格情報のローテーション、クリーン ビルド、依存関係の確認、重要なバックログの修復、回復テスト、スタッフの維持、サプライヤーのガバナンスが含まれます。

アーキテクチャの変更は証拠に従う必要があります。 An immediate platform migration can combine ownership transition with technical change and create avoidable risk. The integration team should sequence changes around mission windows, customer commitments and recovery capacity.

取締役会は、ビルドの再現性、重大な脆弱性、キーアクセス、サプライヤーの刷新、顧客の同意、回復テスト、知識の伝達と支出をカバーする簡潔なダッシュボードを受け取る必要があります。 Reported completion should require objective evidence.

23 継続的なソフトウェア価値の管理

閉鎖後のガバナンスは、ソフトウェアの健全性を商業的および財務的成果に結び付ける必要があります。エンジニアリング対策には、展開の信頼性、欠陥の回避、脆弱性の経過時間、ビルドの整合性、リカバリのパフォーマンス、依存関係のステータスが含まれます。商業的な尺度には、サービスの可用性、更新、配信の待ち時間、サポート コストが含まれます。

製品ロードマップでは、必須のメンテナンス、顧客との約束、セキュリティ修復、成長への投資を区別する必要があります。メンテナンスを延期すると、短期的な収益が膨らむ一方で、将来のキャッシュ生成が弱まる可能性があります。投資委員会はその違いを理解する必要があります。

購入者は、重要な権利、構成、サプライヤーに関する証拠登録を維持する必要があります。所有権、ライセンス、サポート、アーキテクチャが変更されると、取得理論が変更される可能性があります。年次保証と定期的な取引準備状況レビューにより、借り換えまたは撤退のオプションが維持されます。

24 仮想取引事例

仮想のターゲットは、通信、地球観測、およびホストペイロードミッション全体にわたって 18 機の衛星をサポートします。そのプラットフォームには、ミッション計画、コマンド検証、遠隔測定処理、飛行力学、自動化、顧客への配送が含まれます。収益は、年間のソフトウェアおよび運用契約を通じて得られます。

Diligence confirms strong customer retention and capable engineering.また、5 つの取引エクスポージャも特定されています。 Production builds require an undocumented commercial tool. Two libraries are licensed to the seller's parent and cannot transfer automatically. One administrator controls key production and signing processes. Critical vulnerability remediation has been deferred around mission windows. A customer-specific adapter contains contributions with incomplete assignment evidence.

買い手は、USD 84 million ヘッドライン値からの USD 25 million 合計控除を通じて、これらの調査結果の価格を決定します。定義された証拠ゲートが満たされた場合、さらに USD 6 million の獲得が可能です。この構造により、クロージング時に買い手の現金を保護しながら、売り手の修復への参加が維持されます。

25 意思決定原則

まず、獲得したミッション能力とその運用範囲を定義します。次に、デプロイされたすべての重要なアーティファクトを、管理されたソース、構築、および承認の証拠まで追跡します。 Third, separate ownership, access, rights and operational authority.第 4 に、地図のサプライヤーと人々が継続性のために集中します。 5 番目は、テストのリカバリとトランザクションのカットオーバーです。第六に、未解決の依存関係をそれぞれ現金、条件、または契約上の保護に変換します。

これらの原則は、エンジニアリング、財務、運用、法務チームの共通言語を作成します。また、証拠の要求と受け入れテストが具体的になるため、トランザクション速度も向上します。

購入者の目的は、ミッションの結果を明確にコントロールすることです。 That control supports continuity, customer confidence, integration and defensible valuation.

26 アーキテクチャと技術的負債を確認する

アーキテクチャのディリジェンスでは、システムがミッション計画、飛行力学、コマンド検証、テレメトリ、自動化、ID、データ ストア、外部インターフェイスをどのように分離するかを説明する必要があります。購入者は、変更がいくつかのミッションに影響を与える可能性がある信頼境界、障害ドメイン、共有サービスおよびコンポーネントを特定する必要があります。アーキテクチャ図は、デプロイされたトポロジ、ネットワーク フロー、リポジトリの所有権と調和している必要があります。

技術的負債は結果を通じて表現されるべきです。専門知識、テスト、ツールチェーンが利用可能であれば、古いプログラミング言語でも管理しやすくなります。最新のサービスは、所有権、可観測性、または回復性が欠けている場合、脆弱になる可能性があります。デリジェンスチームは、重要な債務項目ごとにコスト、順序、運用リスクを見積もる必要があります。

債務分類では、保守性、セキュリティ、パフォーマンス、拡張性、陳腐化、コンプライアンスを区別する必要があります。商業モデルは、成長や顧客維持を制約するカテゴリーを反映する必要があります。修復計画では、未分化のバックログを提示するのではなく、依存関係とミッション ウィンドウを特定する必要があります。

27 可観測性とインシデントの証拠を評価する

ミッションコントロールの価値は、異常な動作を検出し説明する能力に依存します。購入者は、ログ、メトリクス、トレース、アラート、ダッシュボード、保持、クロック同期、およびインシデント記録を確認する必要があります。データがどこで生成されるか、誰がデータにアクセスできるか、システムやサプライヤーの障害後も記録が存続するかどうかを識別する必要があります。

アラートの品質はサンプリングに値します。対処できないアラートが大量に発生すると、重大なイベントが隠蔽される可能性があります。まばらなアラートは、限定された範囲を反映している可能性があります。チームは、選択したインシデントを、記録されたテレメトリ、対応アクション、根本原因分析、修正作業と比較する必要があります。永続的な修復が行われないままインシデントが繰り返される場合は、管理が脆弱であることを示しています。

トランザクション計画では、監視の継続性を維持する必要があります。アカウントの移行、クラウドの分離、またはツールの置き換えにより、ブラインド期間が発生する可能性があります。終了計画では、どのアラートがアクティブのままであるか、誰がアラートを受信するか、移行中に統合チームがイベントをどのように処理するかを定義する必要があります。安定したモニタリングの証拠は、移行サービス期間の短縮をサポートします。

28 テストの拡張性とフリートの拡張

過去のパフォーマンスは、プラットフォームが購入者の計画したフリートをサポートできることを証明するものではありません。チームは、衛星、連絡先、遠隔測定量、コマンド負荷、顧客インターフェイス、同時オペレーター、地上サイトなどのスケールドライバーを特定する必要があります。観察されたピーク使用率と容量マージンを確認する必要があります。

Load tests should use representative message patterns and failure conditions. Space operations can create short periods of intense activity around launch, commissioning, anomalies and contact windows.平均使用率により、これらの期間中のキューイング、データベース競合、またはオペレーターの過負荷が隠れる可能性があります。

The growth case should include infrastructure, licence, support and staffing costs.技術的に拡張するプラットフォームは、衛星ごとのベンダーの価格設定や専門家の不足による商業的な制限に直面する可能性があります。評価モデルは、成長収益と、それを実現するために必要な資本および運営コストを調整する必要があります。

29 人工知能の機能を慎重に評価する

ターゲットは、異常検出、スケジューリング、画像処理、予知保全、またはオペレーター支援のために機械学習を使用する場合があります。勤勉さは、サポートされている正確な意思決定、モデル所有者、トレーニング データの権利、検証、モニタリング、人間による監視、および障害への対応を特定する必要があります。マーケティングの説明は、運用上の価値の限定的な証拠を提供します。

購入者は、主張されるパフォーマンスを、定義されたベースラインおよび代表的なミッション データと比較する必要があります。偽陽性、偽陰性、ドリフト、再トレーニング、バージョン管理、およびエッジケースを調査する必要があります。平均検出を改善するモデルであっても、故障モードが不透明な場合には、コマンドの決定には依然として適さない可能性があります。

エンジニアリングや運用で使用される生成ツールには、機密データ、コードの出所、出力レビューに対するガバナンスが必要です。製品ロードマップでは、実証された顧客価値と実験的機能を区別する必要があります。評価では、権利、パフォーマンス、展開、および換金が証明された場合にのみ、AI 関連の収益を認識する必要があります。

30 輸出管理と主権アクセス制約の見直し

衛星ソフトウェア、技術データ、およびサービスは、輸出規制、制裁、安全保障分類、および主権アクセス要件の対象となる場合があります。購入者は、規制対象品目、ライセンス、国籍、場所、クラウド領域、顧客制限をマッピングする必要があります。専門弁護士は、適用される法制度を解釈する必要があります。

所有権が移転した場合でも、操作アクセスが制限される場合があります。特定の顧客は、資格のある担当者、国内ホスティング、または個別のサポートを必要とする場合があります。購入者の所有権と資金調達構造によって、レビューまたは同意が引き起こされる可能性があります。これらの要因は、統合設計と運用を一元化する能力に影響を与えます。

取引モデルには、コンプライアンス担当者配置、隔離された環境、ライセンスのタイミング、および考えられる収益制限を含める必要があります。終了条件では、継続に必要な承認に対処する必要があります。経営者は広範な保証を避け、各権限がカバーする正確な範囲を特定する必要があります。

31 投資委員会の証拠パックを作成する

投資委員会は、技術的な発見と経済的な決定を簡潔に結び付ける必要があります。パックは、獲得した機能、収益依存性、および重要な制御ポイントから始める必要があります。情報源と構築された証拠、権利の立場、サプライヤーの地図、運用の回復力、顧客の同意、および従業員の集中を提示する必要があります。

それぞれの重要な所見は、証拠の状態、現金への影響、提案された整備方法、責任のある所有者、および残留リスクを示す必要があります。委員会は、経営陣の見積もりと将来の改善の約束から検証されたギャップを区別できる必要があります。シナリオ分析では、遅延と複合的な障害の影響を示す必要があります。

承認には、条件、委任された権限、および終了後の報告を明記する必要があります。証拠パックは統合ガバナンスのベースラインになります。この継続性により、デリジェンスの調査結果がクロージング後に消失するリスクが軽減され、価値創造に対する後の説明責任がサポートされます。

32 売主からの分離計画

カーブアウトには、アプリケーション、インフラストラクチャ、アイデンティティ、ネットワーク、契約、データ、人材をカバーする分離モデルが必要です。買い手は、売り手に残るサービス、移転するサービス、再構築する必要があるサービスを特定する必要があります。各行には、暫定的な操作方法、目標状態、コスト、依存関係、および終了基準が必要です。

移行サービス契約では、測定可能なサービスと運用上の責任について説明する必要があります。サービス レベル、セキュリティ義務、インシデントの調整、アクセス、変更管理、データの返却、監査の権利、価格設定および終了を特定する必要があります。合理的な支援を提供するという広範な取り組みにより、重要な任務のニーズが未解決のままになる可能性があります。

分離スケジュールはミッションの制約に従う必要があります。 ID またはネットワークの変更は、監視およびコマンド パスに影響を与える可能性があります。データ移行は履歴や監査証拠に影響を与える可能性があります。サプライヤーの革新により、サポート権利が変更される場合があります。当事者はリスクの高い変更を段階的に実行し、受け入れ基準が満たされるまでロールバックを保持する必要があります。

移行サービスが終了する前に、終了の準備状況をテストする必要があります。購入者は、独立したアクセス、構築、導入、監視、サポート、リカバリを実証する必要があります。また、サービスを中断することなく販売者のアカウントとデータを削除できることも確認する必要があります。どの拡張機能にも、理由、価格、修復所有者が定義されている必要があります。

分離コストはトランザクション モデルに属します。これには、インフラストラクチャの重複、一時ライセンス、移行エンジニアリング、セキュリティ テスト、顧客検証、運用の重複が含まれます。見積りでは、確約された見積りと経営陣の仮定を区別する必要があります。資金提供および管理された分離計画により、継続性が保護され、取引が売主に無期限に依存することが防止されます。

すべてのミッションクリティカルなサービスが独立して運用されるまで、取締役会は毎週分離ダッシュボードを受け取る必要があります。ダッシュボードでは、期限を過ぎた依存関係、テストされた終了、未解決の顧客義務、予測コスト、および次の取り消し不能なアクションを特定する必要があります。閉鎖には、エンジニアリング、運用、セキュリティ、財務、および関連するサービス所有者からの証拠が必要です。

付録 A 勤勉証拠登録簿

証拠記録では、質問、要求された成果物、ソース所有者、バージョン、レビュー結果、例外、財務上の影響、およびトランザクションの応答を特定する必要があります。結論を再現できるように、仮想データ ルームへのリンクを維持する必要があります。

優先度の高い証拠には、実稼働インベントリ、リポジトリ マップ、クリーン ビルドの結果、展開トレース、権限インベントリ、ライセンス スケジュール、SBOM、脆弱性バックログ、リカバリ テスト、顧客同意マップ、およびキーマン プランが含まれます。各項目は、対象となる正確なシステムと構成を特定する必要があります。

サンプリングはリスクに基づいて行う必要があります。チームは、代表的な重要なミッション、重要なインターフェイス、最近のリリース、緊急の変更、古いコンポーネントを選択する必要があります。サンプルでは、​​制御設計と実際の実行の両方をテストする必要があります。

付録B 評価方法

例示的な方法は、買い手の商業モデルから導き出される企業価値から始まる。次に、定期的なメンテナンスとサプライヤーのコストに応じて予測キャッシュ フローを調整します。 1 回限りの修復、分離、移行のコストは使用量に含まれます。顧客の同意を条件とする収益は確率で重み付けされます。権利の瑕疵および運用条件は、控除、エスクロー、または条件付き対価を通じて対処されます。

シナリオ分析では、関連するリスクを組み合わせる必要があります。サプライヤーの遅延により、修復や顧客の受け入れも遅れる可能性があります。キーパーソンの退職は継続性と知識の伝達の両方を弱める可能性があります。相関関係のあるマイナス面は明確に扱う価値があります。

この文書では、特定されたトランザクションを表す仮想的な数字はありません。この事例は、証拠がどのように評価と取引構造に結び付けられるかを示しています。

付録 C 受け入れテストの終了

受け入れテストでは、リポジトリ アクセス、クリーン ビルド、テストの実行、パッケージの署名、非運用展開、構成の復元、モニタリング、特権アクセス、サプライヤーのサポートとリカバリをカバーする必要があります。当事者は、署名する前に、テストデータ、環境、合格基準および証拠に同意する必要があります。

テストでは実際の運用の中断を避ける必要があります。生産変更にはミッションの承認と個別の制御が必要です。非運用テストでも、管理されたソースからデプロイ可能なアーティファクトまでのチェーンを検証できます。

テストが失敗した場合は、事前に定義された結果が生じる必要があります。これらには、資産のキュア、エスクロー、クロージングの遅延、対価の減額、または資産の除外が含まれる場合があります。対応は、障害の運用上および財務上の重要性に見合ったものでなければなりません。

付録 D 決定の図と表

提案された取引証拠要件。

法的および運用上の依存関係の分類案。

完全に仮説です。 USD百万。

提案されたコントロール。実際の順序はミッションの制約によって異なります。

提案された証拠マイルストーン。

完全に仮説上の現金効果。 USD百万。

提案された決定閾値。

情報源

1. 米国国立標準技術研究所、SP 800-218 セキュア ソフトウェア開発フレームワーク バージョン 1.1、2022。 一次ソースを読む
2. 米国国立標準技術研究所、SP 800-161 改訂 1、システムと組織のためのサイバーセキュリティ サプライ チェーンのリスク管理実践、2022 年。 一次ソースを読む
3. 米国国立標準技術研究所、サプライ チェーンにおけるソフトウェア セキュリティ ガイダンス、2024 年更新。 一次ソースを読む
4. 米国国立標準技術研究所、サイバーセキュリティ フレームワーク 2.0、2024 年。 一次ソースを読む
5. 米国国立標準技術研究所、NISTIR 8401 衛星地上セグメント、衛星指揮制御へのサイバーセキュリティ フレームワークの適用、2022 年。 一次ソースを読む
6. 米国国立標準技術研究所、SP 800-53 リビジョン 5 情報システムおよび組織のセキュリティとプライバシーの管理。 一次ソースを読む
7. 米国航空宇宙局、NASA ソフトウェア エンジニアリングおよび保証ハンドブック NASA-HDBK-2203。 一次ソースを読む
8. アメリカ航空宇宙局、SWE-042 ソース コード電子アクセス。 一次ソースを読む
9. 米国航空宇宙局、SWE-158 ソフトウェアのセキュリティ脆弱性を評価します。 一次ソースを読む
10. アメリカ航空宇宙局、SWE-206 自動生成ソフトウェア入力。 一次ソースを読む
11. 米国航空宇宙局、NPR 7150.2 NASA ソフトウェア エンジニアリング要件。 一次ソースを読む
12. 米国航空宇宙局、NASA-STD-8739.8 ソフトウェア アシュアランスおよびソフトウェア安全規格。 一次ソースを読む
13. 米国航空宇宙局、NASA-STD-1006A 宇宙システム保護規格。 一次ソースを読む
14. 米国航空宇宙局、宇宙セキュリティのベスト プラクティス ガイド。 一次ソースを読む
15. サイバーセキュリティ・インフラストラクチャ・セキュリティ庁、ソフトウェア・サプライ・チェーンの保護、開発者向けの推奨プラクティス、2023 年。 一次ソースを読む
16. サイバーセキュリティ・インフラストラクチャセキュリティ庁、ソフトウェア部品表。 一次ソースを読む
17. サイバーセキュリティおよびインフラストラクチャセキュリティ庁、安全な設計。 一次ソースを読む
18. サイバーセキュリティおよびインフラストラクチャセキュリティ庁、連邦政府のサイバーセキュリティインシデントおよび脆弱性対応ハンドブック。 一次ソースを読む
19. 欧州宇宙機関、ミッション運用用ソフトウェア製品。 一次ソースを読む
20. 欧州宇宙機関、スペースシールドの悪意のあるサプライチェーンの機能とソフトウェアの脆弱性。 一次ソースを読む
21. 欧州連合サイバーセキュリティ庁、ENISA の 2025 年の宇宙脅威状況。 一次ソースを読む
22. 宇宙データ システム、ミッション運用および情報管理サービスに関する諮問委員会。 一次ソースを読む
23. 宇宙データ システム諮問委員会、セキュリティ ワーキング グループの出版物。 一次ソースを読む
24. 米国宇宙商務局、宇宙政策指令 5 宇宙システムのためのサイバーセキュリティ原則。 一次ソースを読む
25. 英国国家サイバー セキュリティ センター、理事会用サイバー セキュリティ ツールキット。 一次ソースを読む
26. オープンワールドワイドアプリケーションセキュリティプロジェクト、ソフトウェアコンポーネント検証標準。 一次ソースを読む
27. オープンワールドワイドアプリケーションセキュリティプロジェクト、ソフトウェアアシュアランス成熟度モデル。 一次ソースを読む
28. Linux Foundation、SPDX ソフトウェア パッケージ データ交換。 一次ソースを読む
29. 国際標準化機構、ISO IEC 27001 情報セキュリティ管理システム。 一次ソースを読む
30. 欧州宇宙標準化協力、ECSS ソフトウェアエンジニアリング標準。 一次ソースを読む