获取卫星控制软件：源代码、访问权限和供应链尽职调查

介绍

软件位于卫星、地面网络、运营商、客户和监管机构之间。任务控制系统计划联系、验证和传输命令、接收和处理遥测、监控航天器健康状况、计算轨道、管理有效载荷计划并保存操作记录。即使底层航天器在技术上保持健康，缺陷、不可用的依赖项或无法访问的签名密钥也可能会中断收入并削弱指挥权。

因此，收购不仅仅涉及传统的软件产品审查。买方必须了解所操作的任务系统。该系统包括源存储库、构建管道、配置数据、部署环境、加密材料、地面接口、操作手册、供应商服务、工程判断和合同权利。其中一些要素可能位于目标的法律实体之外或依赖于指定的个人。

本文针对该问题提出了一个交易框架。它专为战略收购方、基础设施投资者、私人资本公司、卫星运营商、贷方和评估软件主导的太空交易的董事会而设计。它侧重于改变控制、连续性、价格、条件和集成设计的证据。

1 定义获得的能力

买方应从能力声明开始。该声明确定了该软件支持哪些任务、航天器、有效载荷、地面站点、客户服务和运营决策。它记录服务窗口、可用性预期、安全后果、监管义务和收入依赖性。产品名称本身就提供了一个不可靠的范围，因为一个品牌平台可能依赖于单独的飞行动力、规划、身份、数据库、监控和地面站服务。

能力声明应区分飞行软件和地面软件。卫星控制获取通常集中在地面部分，而操作价值可能取决于嵌入式飞行接口和航天器特定的命令数据库。买方需要证据证明目标公司可以使用、修改和转让持续运营所需的每个接口。

周边还应标识排除的服务。共享企业身份、云订阅、通信链接、密钥管理服务、数据中心或母公司员工可能在第一天就至关重要。每个排除都成为过渡要求、持续依赖或价值调整。

2 独立的所有权、访问权和控制权

合法所有权是控制的要素之一。买方还需要物理或逻辑访问、足够的修改和部署权限、操作知识以及凭证和发布决策的权限。这些元素可能会有所不同。目标可能拥有自定义源代码，同时依赖于不可转移的库。它可能拥有一个存储库，而生产构建取决于顾问的私有工具链。它可能拥有广泛的许可证，而政府客户则控制着部署批准。

尽职调查模型应分别记录所有权、占有权、访问权、修改权、分发权、操作权和终止权。每一项都需要书面证据。相关证据包括任务、雇佣条款、承包商协议、许可计划、存储库权限、部署记录、客户合同和供应商确认。

控制也有时间维度。尽职调查期间存在的访问权限可能会在交易结束时到期。买方应确定通过交易边界保留存储库访问、云租赁、签名权限、管理员凭据、监控历史记录和供应商支持所需的确切操作。

3 构建软件和依赖项清单

清单应识别应用程序、服务、存储库、分支、构建系统、部署包、数据库、接口、商业产品、开源组件、加密库和操作脚本。它应该将每个组件连接到它支持的任务功能及其运行的环境。

SBOM 可以加速组件发现。它不会取代运营库存。有用的采购清单将组件名称和版本链接到源、许可证、维护者、漏洞状态、构建工件、部署配置、数据依赖性和替换路径。容器、固件或供应商设备中嵌入的组件需要引起注意，因为它们可能不存在于传统应用程序列表中。

买方应该协调三个观点：工程认为存在什么、存储库包含什么以及生产遥测显示什么正在运行。差异是勤奋发现的结果。未记录的服务可能至关重要。列出的存储库可能已过时。生产二进制文件可能无法追踪到已批准的源提交。

4 测试源代码完整性

存储库访问应涵盖完整的产品及其历史记录。买方应检查源、配置、基础设施定义、数据库模式、测试资产、构建脚本、部署自动化、文档和问题历史记录。所选文件的快照无法证明完整性。

完整性测试从部署的工件开始。该团队识别具有代表性的生产二进制文件或容器，并将其追溯到源修订、依赖版本、构建参数和批准记录。然后，它在受控环境中构建软件，并将结果与​​已部署的工件或其记录的出处进行比较。差异需要解释。

生成的代码值得单独处理。 NASA 指南认识到，长期维护可能需要访问模型、模拟、数据定义、生成器、构建数据、测试脚本和预期结果。当生成器、模型或合格配置丢失时，拥有生成源可能是不够的。

5 重现构建

可重复的构建是一项高价值的尽职测试。目的是表明授权团队可以根据受控输入创建可部署的版本，而无需无证干预。测试应使用干净的环境和目标的记录程序。买家观察员应记录先决条件、外部下载、凭据、手动步骤、工具版本、警告和偏差。

当现有进程不支持确定性编译时，结果不必是逐位相同的。在商定的测试下，它应该是可追溯的并且功能等效。买方应该了解为什么会出现任何差异以及该过程是否保持完整性。

构建失败可能会导致许可证丢失、证书过期、软件包存储库不可用、补丁未记录或对指定工程师的依赖。这些发现与转型成本和连续性风险直接相关。购买协议可能要求在交割前成功进行干净建设，或者将对价托管直至满足条件。

6 Trace发布和部署权限

来源访问并不建立操作生产的能力。买方应跟踪从代码批准到构建、签名、发布、部署和回滚的权限。该跟踪标识了谁可以批准更改、谁持有签名凭据、包存储在哪里、如何升级环境以及如何控制紧急发布。

卫星控制的变化可能会对任务安全产生影响。发布证据应包括验证结果、操作准备情况审查、配置批准、客户或机构同意（如果适用）以及经过测试的恢复路线。买方应将常规应用程序发布与命令验证、飞行动态、遥测解释或加密信任的更改区分开来。

凭证传输需要设计流程。私钥和特权凭证不应在关闭过程中随意复制。各方应就轮换、撤销、重新注册、双重控制、审计保存和回滚达成一致。结束计划应说明运营权限何时发生变化以及如何避免责任模糊。

7 检查任务配置数据

任务控制软件依赖于与源代码一样有价值的配置。命令词典、遥测定义、限制、校准数据、航天器模型、联系计划、轨道参数、自动化规则和客户路由决定通用软件如何与真实舰队交互。

买方应确定每个配置类的权威来源、其审批流程、版本历史记录和恢复方法。它应该测试是否可以从受控记录填充新环境。基于电子表格或本地存储的配置在缺乏审查、沿袭和备份时会产生风险。

配置权也很重要。客户、航天器制造商或系统集成商可能拥有或限制部分数据。收购协议应规定转让、继续使用、保密、出口限制和删除义务。缺少配置可能会使原本完整的软件无法用于特定任务。

8 评估软件保证证据

软件保证证据表明产品是否是通过受控实践开发和维护的。 NIST 的 SSDF 围绕组织准备、保护软件、生产安全良好的软件和应对漏洞来组织安全开发。 NASA 软件保障指南增加了安全和任务环境的客观证据。

买方应审查需求可追溯性、架构决策、代码审查、静态分析、依赖性扫描、测试覆盖率、发布批准、缺陷历史记录和漏洞响应。证据应与生产中的版本相对应。没有执行记录的保单文件只能提供有限的保证。

尽职调查团队应对命令生成、身份验证、权限管理、轨道确定和恢复等关键路径进行采样。应检查测试是否涵盖不利条件和边界条件。开放调查结果应按任务后果、可利用性、可恢复性和补救依赖性进行分类。

9 绘制软件供应链图

供应链包括商业供应商、开源项目、云提供商、构建服务、软件包存储库、硬件供应商、顾问和专业运营商。买方应明确哪些方可以更改、中断、访问或限制产品。

对于每个关键供应商，尽职调查应涵盖合同支持、财务弹性、安全实践、访问权限、事件通知、变更控制、报废政策、数据位置和替代交付时间。即使年度支出很小，支持多个关键任务组件的供应商也能集中精力。

NIST SP 800-161 将供应链风险视为组织治理问题，而不是采购清单。交易团队应将供应商证据与系统关键性和计划所有权联系起来。材料供应商在成交前可能需要同意、更新或直接同意。

10 分析开源暴露情况

开源组件可以提高功能并减少开发时间。他们还规定了许可、维护和安全义务。买方应将声明的组件与代码扫描和构建清单进行协调。它应该标识许可条款、修改、通知、分发实践和已知漏洞。

Copyleft 曝光需要根据实际使用和分发进行法律分析。许可标签本身并不能确定该义务。团队应记录组件如何链接、部署、修改和提供给客户。补救措施可能涉及通知更正、来源报价、组件更换或客户沟通。

维护状态影响价值。没有活跃维护者或支持版本的关键库可能需要内部所有权。买方应评估分叉策略、测试覆盖率、补丁能力和社区依赖性。软件物料清单在关闭后应保持最新状态，而不是成为静态的尽职调查工件。

11 审查知识产权来源

每个材料代码贡献都应该有一个可防御的出处路径。员工发明应符合适当的雇佣条款。承包商的工作应分配足够的范围。获得或贡献的代码应具有必要的权利。大学、政府或客户资助的开发可能包含需要详细审查的限制。

团队应该根据贡献者记录和合同对提交历史进行采样。未经认可的作者、个人账户或不明原因的批量进口都值得调查。审查应包括文档、模型、测试数据、用户界面和算法，因为有价值的知识产权超出了源文件的范围。

专利和商业秘密分析应侧重于实际产品和商业计划。买方应了解防御性注册、自由操作工作、保密控制以及任何可能削弱商业秘密保护的披露。交易文件可以通过保证、赔偿、托管或或有对价来分配特定的来源风险。

12 测试特权访问和隔离

任务控制环境集中了强大的特权。管理员可以控制命令、身份、数据库、云资源、签名密钥和监控。买方应获得一份特​​权清单，涵盖开发、测试、生产和恢复环境中的人员、服务和紧急帐户。

审查应测试加入者、移动者和离开者控制；多因素身份验证；赞同;会话记录；凭证轮换；打破玻璃通道；以及开发和生产之间的分离。共享或休眠帐户减少了责任。服务帐户需要所有权和生命周期控制。

关闭会增加访问风险。离职人员可以保留恢复路径的凭证或知识。过渡计划应轮换敏感凭证、撤销旧的访问权限、保存证据并维持双重运营覆盖。如果无法访问可能会影响实时任务，则应排练这些操作。

13 审查漏洞管理

买方应了解如何发现、分类、修复和传达漏洞。来源包括静态分析、依赖性扫描、渗透测试、客户报告、供应商咨询和运营监控。该计划应定义严重性、任务后果、补救时间、异常批准和重新测试。

待办事项分析可以揭示隐藏的维护需求。买家应检查年龄、复发情况、受影响的版本和封闭质量。计数低可能反映出检测较弱。高计数可以反映主动发现。有用的衡量标准是组织识别相关风险并在基于风险的时间范围内减少风险的能力。

飞行和地面系统的补丁窗口可能有限。目标应显示它如何应用补偿控制并计划安全释放。无法访问或报废组件中的已知漏洞可以证明特定的价格扣除或资助的修复储备是合理的。

14 评估接口和互操作性

卫星控制软件取决于与航天器、地面站、网络、身份系统、客户平台、天气数据、轨道数据和监管服务的接口。买方应清点每个接口的协议、版本、所有者、性能要求、安全控制、测试环境和变更流程。

接口文档应根据观察到的流量和当前配置进行测试。专有或未记录的接口会造成锁定。标准协议仍可能包含客户特定的扩展，从而使替换变得复杂。

团队应该测试故障模式。它应该观察延迟数据、重复消息、时钟错误、输入损坏、网络中断和部分服务丢失。恢复行为影响运营价值。集成计划应保留接口的可观察性，并避免同时更改多个关键依赖项。

15 评估数据权利和记录

运营数据支持监控、异常分析、模型改进、客户报告和监管证据。买方应区分遥测、命令、衍生产品、日志、客户信息和培训数据的所有权、保管权、允许使用权、保留权和出口权。

交易范围应包括操作和改进系统所需的历史数据。买家收到的软件可能没有足够的操作历史记录来调整警报或调查异常情况。数据迁移应保留时间戳、来源、访问控制和证据完整性。

隐私和本地化义务适用于人员和客户数据。出口管制和国家安全限制可能会影响技术数据和外国人的访问。法律分析应将义务映射到实际数据集和运营地点。

16 检查运营弹性和恢复

弹性测试应显示服务如何在基础设施、软件、供应商和人为故障中继续运行。买方应审查冗余、备份、恢复环境、通信替代方案、手动程序、恢复目标和演习结果。

仅当备份可以在任务允许的范围内恢复时，备份才有用。尽职调查团队应观察代表性恢复并验证配置、凭据、依赖性和数据完整性。恢复应包括在主要环境或供应商不可用时重建系统的能力。

收购本身应被视为弹性事件。公司系统、域、云帐户和支持合同可能会发生变化。详细的切换计划、回滚标准、指挥权限和联合事件流程可降低过渡风险。

17 评估人员和知识集中度

软件连续性取决于了解架构、任务、异常、客户和操作判断的人员。买方应将角色映射到关键流程并识别单点知识。组织结构图提供的证据有限；该地图应反映谁实际解决事件并批准发布。

保留决策应考虑技术重要性和独立性。通过配对、记录、排练和连续可以减少集中的知识。没有知识转移里程碑的保留金只能维持而不是减少依赖。

交易模式应包括招聘、保留、承包商转换和培训成本。当能力无法在过渡期内转移时，关键人物风险可能会影响估值。管理层应根据指定的知识转移证据报告进展情况。

18 审查客户和监管机构的接受程度

客户合同可以定义软件性能、安全、审计、批准和变更义务。买方应确定需要同意、通知、重新认证或指定人员的合同。它应该将自动转移的收入与取决于客户接受程度的收入分开。

政府和关键基础设施客户可能会施加技术数据、安全许可、托管或供应链限制。买方应评估其所有权、融资、人员和运营模式是否仍然合格。监管许可和频谱权利可能位于软件实体之外，但对于服务交付仍然至关重要。

商业模式应对不确定的续约和同意进行概率加权。对价可能取决于经核实的转让或保留收入。买方应避免为经营先决条件未转移的合同支付全部价值。

19 将尽职调查与估值联系起来

软件尽职调查通过现金流、时机、风险和期权寿命改变价值。修复会增加成本。缺失权利会减少可寻址收入。运营脆弱性会增加停电概率。构建控制薄弱可能会延迟产品开发。强有力的证据可以支持较低的整合储备和更大的更新信心。

估值桥梁应避免重复调整。经常性支持成本属于预测现金流量。一次性重建属于事务或集成用途。二元权利缺陷可能需要排除、托管或附加条件，而不是贴现率溢价。

买家应展示基本情况、不利情况和严重情况。每个案例都应确定运营假设、证据和管理行动。最终价值应反映持续维护、组件陈旧、供应商集中度以及更新产品的能力。

20 将发现转化为交易机制

重大发现应有所有者和交易回应。可能的反应包括降价、保留、托管、盈利、赔偿、成交条件、契约、过渡服务、许可证更新、关键人物安排或排除资产。

条件应该是客观可测试的。如果没有定义的存储库、分支、工件和验收测试，那么提供完整源代码的要求就很弱。构建条件可以指定环境、输入、成功的测试套件和部署包。访问条件可以指定身份、权限、密钥和验证登录。

披露过程应保留版本化的证据。买家应记录哪些文物支持每种陈述以及哪些人接受例外。技术时间表需要由工程人员和顾问审查，以便法律语言符合实际操作情况。

21 设计合闸控制室

关闭应作为运营变更进行管理。控制室协调法律完成、凭证传输、供应商更新、云租赁、代码存储库、签名权限、客户通知、监控和事件覆盖。

该计划应使用明确的执行、保留和回滚标准。每个步骤都会确定证据、时间、责任人和后备措施。应在发生不可逆转的操作之前测试关键访问。各方应在风险最高的窗口期保持联合承保。

买方应保留日志和配置快照。这些记录确定传输时的状态并支持以后的调查。第一次交割后发布应遵循商定的保证流程，而不是成为临时集成测试。

22 建立前 100 天

前 100 天应该稳定控制、缩小优先证据差距并降低注意力。早期行动包括访问重新认证、凭证轮换、干净构建、依赖性确认、关键积压修复、恢复测试、员工保留和供应商治理。

架构变更应遵循证据。立即进行平台迁移可以将所有权转移与技术变革结合起来，并产生可避免的风险。集成团队应围绕任务窗口、客户承诺和恢复能力对变更进行排序。

董事会应该收到一个简洁的仪表板，涵盖构建可重复性、关键漏洞、密钥访问、供应商更新、客户同意、恢复测试、知识转移和支出。报告的完成情况应需要客观证据。

23 管理持续的软件价值

交割后治理应将软件健康与商业和财务成果联系起来。工程测量包括部署可靠性、缺陷逃逸、漏洞寿命、构建完整性、恢复性能和依赖性状态。商业衡量标准包括服务可用性、更新、交付延迟和支持成本。

产品路线图应区分强制维护、客户承诺、安全修复和增长投资。推迟维护可能会增加短期收益，同时削弱未来的现金生成能力。投资委员会应该理解这种区别。

买方应保留关键权利、配置和供应商的证据登记册。所有权、许可、支持或架构的变化可能会改变收购主题。年度保证和定期交易准备审查保留了再融资或退出的选择权。

24 假设交易案例

假设目标支持 18 颗卫星，涵盖通信、地球观测和托管有效负载任务。其平台包括任务规划、命令验证、遥测处理、飞行动力学、自动化和客户交付。收入通过年度软件和运营合同产生。

勤奋证实了强大的客户保留率和强大的工程能力。它还确定了五种交易风险。生产构建需要未记录的商业工具。两个库已授权给卖方的母公司，并且不能自动转让。一名管理员控制关键的制作和签名流程。关键漏洞修复已在任务窗口期间推迟。客户特定的适配器包含具有不完整分配证据的贡献。

买方通过从 USD 84 million 总体价值中扣除 USD 25 million 来对这些结果进行定价。当满足定义的证据门时，可以进一步获得 USD 6 million 收益。该结构保留了卖方参与补救的同时保护买方在成交时的现金。

25 决策原则

首先，定义获得的任务能力及其作战范围。其次，追踪每个关键的部署工件以控制来源、构建和批准证据。第三，所有权、访问权、权利和操作权分开。第四，地图供应商和人员集中度的连续性。五是测试恢复和交易割接。第六，将每一个未解决的依赖转化为现金、条件或合同保护。

这些原则为工程、财务、运营和法律团队创建了通用语言。它们还提高了交易速度，因为证据请求和验收测试变得具体。

买方的目标是对任务结果的明显控制。这种控制支持连续性、客户信心、整合和合理的估值。

26 审查架构和技术债务

架构尽职调查应解释系统如何分离任务规划、飞行动力学、命令验证、遥测、自动化、身份、数据存储和外部接口。买方应确定信任边界、故障域、共享服务和组件，这些组件的更改可能会影响多个任务。架构图应与已部署的拓扑、网络流程和存储库所有权保持一致。

技术债务应该通过后果来表达。当专业知识、测试和工具链可用时，旧的编程语言可以保持易于管理。当现代服务缺乏所有权、可观察性或恢复性时，它可能会变得脆弱。尽职调查团队应估计每个重大债务项目的成本、顺序和运营风险。

债务分类应区分可维护性、安全性、性能、可扩展性、过时性和合规性。商业模式应反映限制增长或客户保留的类别。补救计划应确定依赖性和任务窗口，而不是呈现无差别的积压工作。

27 评估可观察性和事件证据

任务控制的价值取决于检测和解释异常行为的能力。买方应查看日志、指标、跟踪、警报、仪表板、保留、时钟同步和事件记录。它应该确定数据在哪里生成、谁可以访问数据以及记录是否在系统或供应商故障时幸存下来。

警报质量值得采样。大量不可操作的警报可能会隐藏重大事件。稀疏警报可能反映出覆盖范围有限。团队应将选定的事件与记录的遥测、响应行动、根本原因分析和纠正工作进行比较。没有持久补救措施的重复事件表明控制薄弱。

事务规划应保持监控的连续性。帐户迁移、云分离或工具更换可能会产生盲期。结束计划应定义哪些警报保持活动状态、谁接收警报以及联合团队如何在过渡期间处理事件。稳定监测的证据可以支持更短的过渡服务期。

28 测试可扩展性和机队扩展

历史表现并不能证明该平台可以支持买方计划的车队。团队应确定规模驱动因素，例如卫星、联系人、遥测量、命令负载、客户界面、并发操作员和地面站点。它应该审查观察到的峰值利用率和容量裕度。

负载测试应使用有代表性的消息模式和故障条件。太空作战可能会在发射、调试、异常和联络窗口等方面产生短期的密集活动。平均利用率可以隐藏这些期间的排队、数据库争用或操作员过载。

增长案例应包括基础设施、许可证、支持和人员成本。技术上可扩展的平台可能会面临来自每卫星供应商定价或稀缺专家的商业限制。估值模型应使增长收入与实现增长所需的资本和运营成本保持一致。

29 仔细评估人工智能特征

目标可以使用机器学习进行异常检测、调度、图像处理、预测性维护或操作员协助。尽职调查应确定支持的确切决策、模型所有者、培训数据权利、验证、监控、人工监督和故障响应。营销描述提供的运营价值证据有限。

买方应将声称的性能与定义的基线和代表性任务数据进行比较。它应该检查误报、漏报、漂移、再训练、版本控制和边缘情况。当其故障模式不透明时，改进平均检测的模型仍然不适合命令决策。

工程或运营中使用的生成工具需要对敏感数据、代码来源和输出审查进行治理。产品路线图应将展示的客户价值与实验能力分开。仅当权利、绩效、部署和现金转换得到证实时，估值才应确认与AI相关的收入。

30 审查出口管制和主权准入限制

卫星软件、技术数据和服务可能受到出口管制、制裁、安全分类和主权准入要求的约束。买方应绘制受控项目、许可证、国籍、位置、云区域和客户限制的地图。专业顾问应解释适用的法律制度。

即使所有权转移，操作访问也可能受到限制。某些客户可能需要清理人员、国内托管或隔离支持。买方的所有权和融资结构可能会引发审查或同意。这些因素影响集成设计和集中运营的能力。

交易模型应包括合规人员配置、隔离环境、许可时间和可能的收入限制。成交条件应涉及连续性所需的批准。管理层应避免宽泛的保证，并确定每项授权所涵盖的准确范围。

31 创建投资委员会证据包

投资委员会需要在技术发现和经济决策之间建立简洁的联系。该包应从获得的能力、收入依赖性和关键控制点开始。它应该展示来源并建立证据、权利定位、供应商地图、运营弹性、客户同意和人员集中度。

每项重大发现均应显示证据状态、现金后果、建议的机械师、责任所有者和剩余风险。委员会应该能够区分已验证的差距与管理层的估计和未来的补救承诺。情景分析应显示延误和组合故障的影响。

批准应说明条件、授权和交割后报告。然后，证据包将成为集成治理的基线。这种连续性降低了尽职调查结果在交易结束后消失的风险，并支持以后对价值创造的问责。

32 计划与卖方分离

剥离需要一个涵盖应用程序、基础设施、身份、网络、合同、数据和人员的分离模型。买方应确定卖方保留的服务、转让的服务以及必须重建的服务。每条生产线都应该有一个临时的运营方法、目标状态、成本、依赖性和退出标准。

过渡服务协议应描述可衡量的服务和运营责任。他们应确定服务级别、安全义务、事件协调、访问、变更控制、数据返回、审计权利、定价和终止。提供合理援助的广泛承诺可能会导致关键任务需求得不到解决。

分离时间表应遵循任务限制。身份或网络更改可能会影响监控和命令路径。数据迁移可能会影响历史记录和审计证据。供应商更新可以改变支持权利。各方应进行高风险变更并保留回滚，直到满足验收标准。

应在过渡服务结束之前测试退出准备情况。买方应展示独立的访问、构建、部署、监控、支持和恢复能力。它还应确认可以在不中断服务的情况下删除卖家帐户和数据。任何延期都应该有明确的原因、价格和补救措施所有者。

分离成本属于交易模式。它包括重复的基础设施、临时许可证、迁移工程、安全测试、客户验证和运营重叠。估算应将承诺报价与管理层假设区分开来。受资助和管理的分离计划可以保护连续性并防止交易对卖方产生无限期的依赖。

董事会应每周收到一次分离仪表板，直到所有关键任务服务独立运行。仪表板应识别过期的依赖项、测试的退出、未解决的客户义务、预测成本和下一个不可逆转的操作。关闭应需要来自工程、运营、安全、财务和相关服务所有者的证据。

附录 A 勤勉证据登记册

证据登记册应标识问题、请求的工件、来源所有者、版本、审查结果、例外情况、财务后果和交易响应。它应保持与虚拟数据室的链接，以便可以重现结论。

高优先级证据包括生产清单、存储库图、全新构建结果、部署跟踪、权限清单、许可证计划、SBOM、漏洞积压、恢复测试、客户同意图和关键人员计划。每个项目都应确定所涵盖的确切系统和配置。

抽样应基于风险。团队应选择具有代表性的高后果任务、关键接口、最新版本、紧急变更和旧组件。样本应该测试控制设计和实际执行。

附录B 计价方法

说明性方法从从买方的商业模式中得出的企业价值开始。然后，它会调整经常性维护和供应商成本的预测现金流。一次性修复、分离和过渡成本包含在使用中。经客户同意的收入是概率加权的。权利缺陷和运营条件通过扣除、托管或或有对价来解决。

情景分析应结合相关风险。供应商的延迟也可能会延迟补救和客户接受。关键人物的离开可能会削弱连续性和知识转移。相关的缺点值得明确处理。

本文中没有假设的数字代表已确定的交易。该案例展示了证据如何与估值和交易结构联系起来。

附录 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. 欧洲航天局、SPACE-SHIELD 恶意供应链功能和软件漏洞。 阅读主要来源
21. 欧盟网络安全局，ENISA 2025 年太空威胁形势。 阅读主要来源
22. 空间数据系统、任务运行和信息管理服务咨询委员会。 阅读主要来源
23. 空间数据系统咨询委员会、安全工作组出版物。 阅读主要来源
24. 美国太空商务办公室，太空政策指令 5 太空系统网络安全原则。 阅读主要来源
25. 英国国家网络安全中心，董事会网络安全工具包。 阅读主要来源
26. 开放全球应用程序安全项目、软件组件验证标准。 阅读主要来源
27. 开放全球应用程序安全项目、软件保障成熟度模型。 阅读主要来源
28. Linux 基金会，SPDX 软件包数据交换。 阅读主要来源
29. 国际标准化组织，ISO IEC 27001 信息安全管理系统。 阅读主要来源
30. 欧洲空间标准化合作组织、ECSS 软件工程标准。 阅读主要来源