Einführung
Software sitzt zwischen dem Satelliten, dem Bodennetz, Betreibern, Kunden und Regulierungsbehörden. Missionskontrollsysteme planen Kontakte, validieren und übermitteln Befehle, empfangen und verarbeiten Telemetriedaten, überwachen den Zustand von Raumfahrzeugen, berechnen Umlaufbahnen, verwalten Nutzlastpläne und bewahren die Betriebsaufzeichnungen auf. Ein Defekt, eine nicht verfügbare Abhängigkeit oder ein nicht zugänglicher Signaturschlüssel können die Einnahmen unterbrechen und die Befehlsautorität schwächen, selbst wenn das zugrunde liegende Raumschiff technisch fehlerfrei bleibt.
Eine Akquisition umfasst daher mehr als eine herkömmliche Überprüfung eines Softwareprodukts. Der Käufer muss verstehen, wie das Missionssystem betrieben wird. Dieses System umfasst Quellrepositorys, Build-Pipelines, Konfigurationsdaten, Bereitstellungsumgebungen, kryptografisches Material, Bodenschnittstellen, Runbooks, Lieferantendienste, technische Beurteilung und vertragliche Rechte. Mehrere dieser Elemente können außerhalb der juristischen Person des Ziels angesiedelt sein oder von namentlich genannten Personen abhängen.
In diesem Artikel wird ein Transaktionsrahmen für dieses Problem dargelegt. Es richtet sich an strategische Käufer, Infrastrukturinvestoren, Privatkapitalunternehmen, Satellitenbetreiber, Kreditgeber und Vorstände, die eine softwaregesteuerte Weltraumtransaktion bewerten. Es konzentriert sich auf Beweise dafür, dass sich Kontrolle, Kontinuität, Preis, Bedingungen und Integrationsdesign ändern.
1 Definieren Sie die erworbene Fähigkeit
Der Käufer sollte mit einer Leistungserklärung beginnen. Die Erklärung gibt an, welche Missionen, Raumfahrzeuge, Nutzlasten, Bodenstandorte, Kundendienste und Betriebsentscheidungen die Software unterstützt. Es erfasst Servicefenster, Verfügbarkeitserwartungen, Sicherheitsfolgen, regulatorische Verpflichtungen und Umsatzabhängigkeiten. Allein Produktnamen stellen einen unzuverlässigen Rahmen dar, da eine Markenplattform auf separate Flugdynamik-, Planungs-, Identitäts-, Datenbank-, Überwachungs- und Bodenstationsdienste angewiesen sein kann.
Die Fähigkeitserklärung sollte Flugsoftware von Bodensoftware unterscheiden. Die Erfassung der Satellitensteuerung konzentriert sich in der Regel auf das Bodensegment, während der betriebliche Wert von eingebetteten Flugschnittstellen und raumfahrzeugspezifischen Befehlsdatenbanken abhängen kann. Der Käufer benötigt den Nachweis, dass das Zielunternehmen alle für den weiteren Betrieb erforderlichen Schnittstellen nutzen, modifizieren und übertragen darf.
Der Perimeter sollte auch ausgeschlossene Dienste identifizieren. Eine gemeinsame Unternehmensidentität, Cloud-Abonnements, Kommunikationsverbindungen, Schlüsselverwaltungsdienste, Rechenzentren oder Mitarbeiter der Muttergesellschaft können vom ersten Tag an unerlässlich sein. Jeder Ausschluss wird zu einem Übergangsgebot, einer fortdauernden Abhängigkeit oder einer Wertanpassung.
2 Getrennte Eigentumsverhältnisse, Zugriff und Kontrolle
Rechtliches Eigentum ist ein Element der Kontrolle. Der Käufer benötigt außerdem physischen oder logischen Zugriff, ausreichende Rechte zum Ändern und Bereitstellen, Kenntnisse zum Betrieb sowie Autorität über Anmeldeinformationen und Freigabeentscheidungen. Diese Elemente können divergieren. Ein Ziel kann benutzerdefinierten Quellcode besitzen, während es auf eine nicht übertragbare Bibliothek angewiesen ist. Es verfügt möglicherweise über ein Repository, während der Produktions-Build von der privaten Toolchain eines Beraters abhängt. Es kann umfassende Lizenzen besitzen, während ein staatlicher Kunde die Bereitstellungsgenehmigung kontrolliert.
Das Sorgfaltsmodell sollte Eigentum, Besitz, Zugang, Änderungsrechte, Vertriebsrechte, Betriebsberechtigung und Kündigungsrechte getrennt erfassen. Für jeden Gegenstand sind dokumentarische Nachweise erforderlich. Zu den relevanten Beweisen gehören Aufträge, Arbeitsbedingungen, Auftragnehmervereinbarungen, Lizenzpläne, Repository-Berechtigungen, Bereitstellungsaufzeichnungen, Kundenverträge und Lieferantenbestätigungen.
Kontrolle hat auch eine zeitliche Dimension. Zugriffe, die während der Prüfung bestehen, können bei Abschluss erlöschen. Der Käufer sollte die genauen Maßnahmen identifizieren, die erforderlich sind, um den Repository-Zugriff, die Cloud-Mandantenfähigkeit, die Signaturberechtigung, die Administratoranmeldeinformationen, den Überwachungsverlauf und die Lieferantenunterstützung über die Transaktionsgrenze hinweg aufrechtzuerhalten.
3 Erstellen Sie das Software- und Abhängigkeitsinventar
Das Inventar sollte Anwendungen, Dienste, Repositorys, Zweige, Build-Systeme, Bereitstellungspakete, Datenbanken, Schnittstellen, kommerzielle Produkte, Open-Source-Komponenten, kryptografische Bibliotheken und Betriebsskripte identifizieren. Es sollte jede Komponente mit der von ihr unterstützten Missionsfunktion und der Umgebung, in der sie ausgeführt wird, verbinden.
Eine SBOM kann die Komponentenerkennung beschleunigen. Es ersetzt nicht das Betriebsinventar. Ein nützliches Erfassungsinventar verknüpft Komponentennamen und -version mit Quelle, Lizenz, Betreuer, Schwachstellenstatus, Build-Artefakt, bereitgestellter Konfiguration, Datenabhängigkeit und Ersetzungspfad. In Containern, Firmware oder Anbieter-Appliances eingebettete Komponenten erfordern Aufmerksamkeit, da sie in einer herkömmlichen Anwendungsliste fehlen können.
Der Käufer sollte drei Ansichten in Einklang bringen: was die Technik sagt, was existiert, was Repositories enthalten und was Produktionstelemetrie zeigt, dass es läuft. Unterschiede sind Sorgfaltsfeststellungen. Ein nicht aufgezeichneter Dienst kann kritisch sein. Ein aufgelistetes Repository ist möglicherweise veraltet. Eine Produktionsbinärdatei kann möglicherweise nicht auf ein genehmigtes Quell-Commit zurückgeführt werden.
4 Testen Sie die Vollständigkeit des Quellcodes
Der Repository-Zugriff sollte das gesamte Produkt und seinen Verlauf abdecken. Der Käufer sollte Quelle, Konfiguration, Infrastrukturdefinitionen, Datenbankschemata, Testressourcen, Build-Skripte, Bereitstellungsautomatisierung, Dokumentation und Problemhistorie prüfen. Ein Snapshot ausgewählter Dateien kann die Vollständigkeit nicht nachweisen.
Die Vollständigkeitsprüfung beginnt mit den bereitgestellten Artefakten. Das Team identifiziert repräsentative Produktionsbinärdateien oder Container und führt sie auf Quellrevisionen, Abhängigkeitsversionen, Build-Parameter und Genehmigungsdatensätze zurück. Anschließend wird die Software in einer kontrollierten Umgebung erstellt und das Ergebnis mit dem eingesetzten Artefakt oder seiner dokumentierten Herkunft verglichen. Unterschiede bedürfen der Erklärung.
Generierter Code verdient eine gesonderte Behandlung. Die Leitlinien der NASA erkennen an, dass eine langfristige Wartung den Zugriff auf Modelle, Simulationen, Datendefinitionen, Generatoren, Build-Daten, Testskripte und erwartete Ergebnisse erfordern kann. Der Besitz einer generierten Quelle kann unzureichend sein, wenn der Generator, das Modell oder die qualifizierte Konfiguration fehlt.
5 Reproduzieren Sie den Build
Ein reproduzierbarer Build ist ein hochwertiger Sorgfaltstest. Das Ziel besteht darin, zu zeigen, dass ein autorisiertes Team aus kontrollierten Eingaben ohne undokumentierten Eingriff ein einsetzbares Release erstellen kann. Für den Test sollten eine saubere Umgebung und das dokumentierte Verfahren des Ziels verwendet werden. Käuferbeobachter sollten Voraussetzungen, externe Downloads, Anmeldeinformationen, manuelle Schritte, Toolversionen, Warnungen und Abweichungen aufzeichnen.
Das Ergebnis muss nicht bitweise identisch sein, wenn der vorhandene Prozess keine deterministische Kompilierung unterstützt. Es sollte nachvollziehbar und unter vereinbarten Tests funktionell gleichwertig sein. Der Käufer sollte verstehen, warum es zu Unterschieden kommt und ob der Prozess die Integrität wahrt.
Build-Fehler können fehlende Lizenzen, abgelaufene Zertifikate, nicht verfügbare Paket-Repositorys, undokumentierte Patches oder die Abhängigkeit von einem benannten Ingenieur aufdecken. Diese Erkenntnisse stehen in direktem Zusammenhang mit den Übergangskosten und dem Kontinuitätsrisiko. Der Kaufvertrag kann einen erfolgreichen Clean Build vor dem Abschluss verlangen oder die Gegenleistung auf einem Treuhandkonto hinterlegen, bis die Bedingung erfüllt ist.
6 Trace-Release- und Bereitstellungsautorität
Der Zugriff auf die Quelle begründet nicht die Fähigkeit, die Produktion zu betreiben. Der Käufer sollte die Befugnisse von der Codegenehmigung über Build, Signierung, Freigabe, Bereitstellung und Rollback nachverfolgen. Die Ablaufverfolgung identifiziert, wer Änderungen genehmigen kann, wer über Signaturberechtigungen verfügt, wo Pakete gespeichert werden, wie Umgebungen gefördert werden und wie Notfallfreigaben kontrolliert werden.
Änderungen der Satellitensteuerung können Auswirkungen auf die Missionssicherheit haben. Der Freigabenachweis sollte Verifizierungsergebnisse, eine Überprüfung der Betriebsbereitschaft, eine Konfigurationsgenehmigung, gegebenenfalls die Zustimmung des Kunden oder einer Behörde sowie einen getesteten Wiederherstellungsweg umfassen. Der Käufer sollte zwischen routinemäßigen Anwendungsversionen und Änderungen an der Befehlsvalidierung, der Flugdynamik, der Telemetrieinterpretation oder dem kryptografischen Vertrauen unterscheiden.
Für die Übertragung von Anmeldedaten ist ein spezieller Prozess erforderlich. Private Schlüssel und privilegierte Zugangsdaten sollten beim Schließen nicht versehentlich kopiert werden. Die Parteien sollten Rotation, Widerruf, Neuregistrierung, Vier-Augen-Prinzip, Audit-Bewahrung und Rollback vereinbaren. Im Abschlussplan sollte angegeben werden, wann sich die operativen Befugnisse ändern und wie unklare Zuständigkeiten vermieden werden.
7 Untersuchen Sie die Missionskonfigurationsdaten
Missionskontrollsoftware ist auf Konfigurationen angewiesen, die genauso wertvoll sein können wie Quellcode. Befehlswörterbücher, Telemetriedefinitionen, Grenzwerte, Kalibrierungsdaten, Raumfahrzeugmodelle, Kontaktpläne, Orbitalparameter, Automatisierungsregeln und Kundenrouting bestimmen, wie generische Software mit einer realen Flotte interagiert.
Der Käufer sollte die maßgebliche Quelle für jede Konfigurationsklasse, ihren Genehmigungsprozess, ihren Versionsverlauf und ihre Wiederherstellungsmethode angeben. Es sollte testen, ob eine neue Umgebung aus kontrollierten Datensätzen gefüllt werden kann. Tabellenkalkulationsbasierte oder lokal gespeicherte Konfigurationen bergen Risiken, wenn es an Überprüfung, Herkunft und Sicherung mangelt.
Konfigurationsrechte sind ebenfalls wichtig. Ein Kunde, Raumfahrzeughersteller oder Systemintegrator kann einen Teil der Daten besitzen oder einen Teil davon einschränken. Der Erwerbsvertrag sollte die Übertragung, die weitere Nutzung, die Vertraulichkeit, Exportbeschränkungen und Löschpflichten regeln. Fehlende Konfiguration kann dazu führen, dass eine ansonsten vollständige Software für eine bestimmte Mission unbrauchbar wird.
8 Bewerten Sie Software-Assurance-Beweise
Software-Assurance-Beweise zeigen, ob das Produkt durch kontrollierte Praktiken entwickelt und gewartet wurde. Das SSDF des NIST organisiert sichere Entwicklung rund um die Vorbereitung der Organisation, den Schutz von Software, die Produktion gut gesicherter Software und die Reaktion auf Schwachstellen. Die Software-Assurance-Leitlinien der NASA liefern objektive Beweise für Sicherheit und Missionskontexte.
Der Käufer sollte die Rückverfolgbarkeit der Anforderungen, Architekturentscheidungen, Codeüberprüfung, statische Analyse, Abhängigkeitsscan, Testabdeckung, Release-Genehmigung, Fehlerhistorie und Reaktion auf Schwachstellen überprüfen. Die Nachweise sollten den in Produktion befindlichen Versionen entsprechen. Ein Policendokument ohne ausgeführte Aufzeichnungen bietet begrenzte Sicherheit.
Das Diligence-Team sollte kritische Pfade wie Befehlsgenerierung, Authentifizierung, Privilegienverwaltung, Orbitbestimmung und Wiederherstellung testen. Es sollte untersucht werden, ob die Tests unerwünschte Bedingungen und Randbedingungen abdecken. Offene Ergebnisse sollten nach Missionskonsequenz, Ausnutzbarkeit, Wiederherstellbarkeit und Sanierungsabhängigkeit klassifiziert werden.
9 Ordnen Sie die Software-Lieferkette zu
Die Lieferkette umfasst kommerzielle Anbieter, Open-Source-Projekte, Cloud-Anbieter, Build-Services, Paket-Repositories, Hardware-Lieferanten, Berater und spezialisierte Betreiber. Der Käufer sollte festlegen, welche Parteien das Produkt ändern, unterbrechen, darauf zugreifen oder es einschränken können.
Für jeden kritischen Lieferanten sollte die Sorgfaltspflicht die vertragliche Unterstützung, finanzielle Belastbarkeit, Sicherheitspraktiken, Zugriffsrechte, Vorfallbenachrichtigung, Änderungskontrolle, End-of-Life-Richtlinie, Datenspeicherung und Ersatzvorlaufzeit umfassen. Ein Lieferant, der mehrere geschäftskritische Komponenten unterstützt, schafft Konzentration, selbst wenn die jährlichen Ausgaben gering sind.
NIST SP 800-161 behandelt Lieferkettenrisiken als organisatorisches Governance-Problem und nicht als Beschaffungscheckliste. Das Transaktionsteam sollte Lieferantennachweise mit der Systemkritikalität und der geplanten Eigentümerschaft verknüpfen. Materiallieferanten benötigen möglicherweise vor dem Abschluss eine Zustimmung, eine Novation oder eine direkte Vereinbarung.
10 Analysieren Sie die Open-Source-Exposition
Open-Source-Komponenten können die Leistungsfähigkeit verbessern und die Entwicklungszeit verkürzen. Darüber hinaus schaffen sie Lizenz-, Wartungs- und Sicherheitspflichten. Der Käufer sollte deklarierte Komponenten mit Code-Scans und Build-Manifesten abgleichen. Es sollte Lizenzbedingungen, Änderungen, Hinweise, Vertriebspraktiken und bekannte Schwachstellen identifizieren.
Die Offenlegung von Copyleft erfordert eine rechtliche Analyse auf der Grundlage der tatsächlichen Nutzung und Verbreitung. Eine Lizenzplakette allein begründet die Verpflichtung nicht. Das Team sollte dokumentieren, wie Komponenten verknüpft, bereitgestellt, geändert und den Kunden bereitgestellt werden. Die Abhilfe kann die Korrektur von Hinweisen, Quellenangebote, den Austausch von Komponenten oder die Kundenkommunikation umfassen.
Der Wartungsstatus beeinflusst den Wert. Eine kritische Bibliothek ohne aktiven Betreuer oder unterstütztes Release kann internes Eigentum erfordern. Der Käufer sollte die Fork-Strategie, die Testabdeckung, die Patch-Fähigkeit und die Community-Abhängigkeit bewerten. Eine Software-Stückliste sollte nach dem Abschluss aktuell bleiben und nicht zu einem statischen Diligence-Artefakt werden.
11 Überprüfen Sie die Herkunft des geistigen Eigentums
Jeder Materialcode-Beitrag sollte einen vertretbaren Herkunftspfad haben. Arbeitnehmererfindungen sollten in angemessene Beschäftigungsbedingungen fallen. Auftragnehmerleistungen sollten in ausreichendem Umfang vergeben werden. Der erworbene oder beigesteuerte Code sollte über die erforderlichen Rechte verfügen. Eine universitäre, staatliche oder kundenfinanzierte Entwicklung kann Einschränkungen beinhalten, die einer detaillierten Prüfung bedürfen.
Das Team sollte den Commit-Verlauf mit den Aufzeichnungen und Verträgen der Mitwirkenden vergleichen. Unbekannte Autoren, persönliche Konten oder ungeklärte Massenimporte verdienen eine Untersuchung. Die Überprüfung sollte Dokumentation, Modelle, Testdaten, Benutzeroberflächen und Algorithmen umfassen, da wertvolles geistiges Eigentum über Quelldateien hinausgeht.
Die Analyse von Patenten und Geschäftsgeheimnissen sollte sich auf das tatsächliche Produkt und den kommerziellen Plan konzentrieren. Der Käufer sollte sich über defensive Registrierungen, Arbeitsfreiheit, Vertraulichkeitskontrollen und jegliche Offenlegung im Klaren sein, die den Schutz von Geschäftsgeheimnissen schwächen könnte. Transaktionsdokumente können bestimmte Herkunftsrisiken durch Garantien, Entschädigungen, Treuhandkonten oder bedingte Gegenleistungen zuweisen.
12 Testen Sie den privilegierten Zugriff und die Trennung
Missionskontrollumgebungen konzentrieren leistungsstarke Privilegien. Administratoren können Befehle, Identität, Datenbanken, Cloud-Ressourcen, Signaturschlüssel und Überwachung steuern. Der Käufer sollte ein Privilegienverzeichnis erhalten, das Personen-, Service- und Notfallkonten in Entwicklungs-, Test-, Produktions- und Wiederherstellungsumgebungen abdeckt.
Bei der Überprüfung sollten die Kontrollen für Neueinsteiger, Umzüge und Austritte geprüft werden; Multifaktor-Authentifizierung; Genehmigung; Sitzungsprotokollierung; Qualifikationsrotation; Zugang gegen Glasbruch; und Trennung zwischen Entwicklung und Produktion. Geteilte oder ruhende Konten verringern die Verantwortlichkeit. Für Dienstkonten sind Eigentums- und Lebenszykluskontrollen erforderlich.
Durch das Schließen entsteht ein erhöhtes Zugangsrisiko. Ausscheidendes Personal kann seine Qualifikationen oder sein Wissen über Wiederherstellungspfade behalten. Der Übergangsplan sollte sensible Zugangsdaten rotieren, alten Zugang widerrufen, Beweise sichern und eine doppelte Betriebsabdeckung aufrechterhalten. Diese Aktionen sollten dort geprobt werden, wo der Verlust des Zugangs Auswirkungen auf eine Live-Mission haben könnte.
13 Überprüfen Sie das Schwachstellenmanagement
Der Käufer sollte verstehen, wie Schwachstellen entdeckt, bewertet, behoben und kommuniziert werden. Zu den Quellen gehören statische Analysen, Abhängigkeitsscans, Penetrationstests, Kundenberichte, Lieferantenhinweise und Betriebsüberwachung. Das Programm sollte den Schweregrad, die Konsequenz des Einsatzes, den Zeitpunkt der Behebung, die Ausnahmegenehmigung und die erneuten Tests festlegen.
Eine Backlog-Analyse kann versteckte Wartungsanforderungen aufdecken. Der Käufer sollte Alter, Wiederholung, betroffene Versionen und Verschlussqualität prüfen. Eine niedrige Zahl kann auf eine schwache Erkennung hinweisen. Eine hohe Anzahl kann auf eine aktive Entdeckung hinweisen. Der nützliche Maßstab ist die Fähigkeit der Organisation, relevante Risiken zu identifizieren und diese innerhalb risikobasierter Zeitrahmen zu reduzieren.
Flug- und Bodensysteme verfügen möglicherweise über begrenzte Patch-Fenster. Das Ziel sollte zeigen, wie es kompensierende Kontrollen anwendet und sichere Freisetzungen plant. Bekannte Schwachstellen in unzugänglichen oder ausgedienten Komponenten können einen spezifischen Preisnachlass oder eine finanzierte Sanierungsrücklage rechtfertigen.
14 Schnittstellen und Interoperabilität bewerten
Software zur Satellitensteuerung ist auf Schnittstellen zu Raumfahrzeugen, Bodenstationen, Netzwerken, Identitätssystemen, Kundenplattformen, Wetterdaten, Umlaufbahndaten und Regulierungsdiensten angewiesen. Der Käufer sollte Protokoll, Version, Besitzer, Leistungsanforderung, Sicherheitskontrolle, Testumgebung und Änderungsprozess für jede Schnittstelle inventarisieren.
Die Schnittstellendokumentation sollte anhand des beobachteten Datenverkehrs und der aktuellen Konfigurationen getestet werden. Proprietäre oder undokumentierte Schnittstellen führen zu einem Lock-in. Ein Standardprotokoll kann dennoch kundenspezifische Erweiterungen enthalten, die den Austausch erschweren.
Das Team sollte Fehlermodi testen. Es sollte verzögerte Daten, doppelte Nachrichten, Uhrfehler, beschädigte Eingaben, Netzwerkunterbrechungen und teilweise Dienstausfälle beobachten. Das Wiederherstellungsverhalten beeinflusst den Betriebswert. Integrationspläne sollten die Beobachtbarkeit der Schnittstelle wahren und vermeiden, dass mehrere kritische Abhängigkeiten gleichzeitig geändert werden.
15 Bewerten Sie Datenrechte und -aufzeichnungen
Betriebsdaten unterstützen Überwachung, Anomalieanalyse, Modellverbesserung, Kundenberichterstattung und behördliche Nachweise. Der Käufer sollte Eigentum, Sorgerecht, erlaubte Nutzung, Aufbewahrungs- und Exportrechte für Telemetrie, Befehle, abgeleitete Produkte, Protokolle, Kundeninformationen und Schulungsdaten unterscheiden.
Der Transaktionsumfang sollte historische Daten enthalten, die für den Betrieb und die Verbesserung des Systems erforderlich sind. Ein Käufer erhält möglicherweise Software ohne ausreichende Betriebshistorie, um Warnungen zu optimieren oder Anomalien zu untersuchen. Bei der Datenmigration sollten Zeitstempel, Herkunft, Zugriffskontrollen und Beweisintegrität gewahrt bleiben.
Für Personal- und Kundendaten können Datenschutz- und Lokalisierungspflichten gelten. Exportkontrollen und nationale Sicherheitsbeschränkungen können Auswirkungen auf technische Daten und den Zugriff ausländischer Personen haben. Die rechtliche Analyse sollte Verpflichtungen auf tatsächliche Datensätze und Betriebsstandorte abbilden.
16 Untersuchen Sie die betriebliche Belastbarkeit und Wiederherstellung
Resilienztests sollten zeigen, wie der Dienst trotz Infrastruktur-, Software-, Lieferanten- und menschlichem Versagen fortbesteht. Der Käufer sollte Redundanz, Backups, Wiederherstellungsumgebungen, Kommunikationsalternativen, manuelle Verfahren, Wiederherstellungsziele und Übungsergebnisse überprüfen.
Ein Backup ist nur dann sinnvoll, wenn es im Rahmen der Missionstoleranz wiederhergestellt werden kann. Das Diligence-Team sollte eine repräsentative Wiederherstellung beobachten und Konfiguration, Anmeldeinformationen, Abhängigkeiten und Datenintegrität validieren. Die Wiederherstellung sollte die Möglichkeit umfassen, Systeme neu aufzubauen, wenn die primäre Umgebung oder der Lieferant nicht verfügbar ist.
Die Akquisition selbst sollte als Resilienzereignis behandelt werden. Unternehmenssysteme, Domänen, Cloud-Konten und Supportverträge können sich ändern. Ein detaillierter Umstellungsplan, Rollback-Kriterien, Befehlsbefugnisse und ein gemeinsamer Vorfallprozess reduzieren das Übergangsrisiko.
17 Bewerten Sie Personen und Wissenskonzentration
Softwarekontinuität hängt von Menschen ab, die Architektur, Missionen, Anomalien, Kunden und betriebliches Urteilsvermögen verstehen. Der Käufer sollte kritischen Prozessen Rollen zuordnen und einzelne Wissenspunkte identifizieren. Organigramme liefern nur begrenzte Beweise; Die Karte sollte widerspiegeln, wer tatsächlich Vorfälle löst und Freigaben genehmigt.
Bei Aufbewahrungsentscheidungen sollten sowohl die technische Bedeutung als auch die Unabhängigkeit berücksichtigt werden. Konzentriertes Wissen kann durch Paarung, Dokumentation, Probe und Nachfolge reduziert werden. Selbstbehaltszahlungen ohne Meilensteine des Wissenstransfers können die Abhängigkeit bewahren, anstatt sie zu verringern.
Das Transaktionsmodell sollte die Kosten für Rekrutierung, Bindung, Konvertierung von Auftragnehmern und Schulungen umfassen. Das Risiko einer Schlüsselperson kann sich auf die Bewertung auswirken, wenn die Fähigkeit nicht innerhalb des Übergangszeitraums übertragen werden kann. Das Management sollte Fortschritte anhand benannter Erkenntnisse zum Wissenstransfer melden.
18 Überprüfen Sie die Kunden- und Regulierungsakzeptanz
Kundenverträge können Softwareleistungs-, Sicherheits-, Audit-, Genehmigungs- und Änderungsverpflichtungen festlegen. Der Käufer sollte Verträge identifizieren, die eine Zustimmung, Mitteilung, Rezertifizierung oder die Benennung von Personal erfordern. Es sollte Einnahmen, die automatisch übertragen werden, von Einnahmen trennen, die von der Kundenakzeptanz abhängig sind.
Kunden von Behörden und kritischen Infrastrukturen können technische Daten, Sicherheitsfreigaben, Hosting oder Lieferkettenbeschränkungen auferlegen. Der Käufer sollte prüfen, ob sein Eigentum, seine Finanzierung, sein Personal und sein Betriebsmodell weiterhin förderfähig sind. Regulatorische Lizenzen und Frequenzrechte können außerhalb der Softwareeinheit liegen, bleiben aber für die Bereitstellung von Diensten unerlässlich.
Das kommerzielle Modell sollte ungewisse Verlängerungen und Zustimmungen mit der Wahrscheinlichkeit gewichten. Die Gegenleistung kann von einer bestätigten Übertragung oder einbehaltenen Einnahmen abhängig sein. Bei Verträgen, deren Betriebsvoraussetzungen nicht übertragen werden, sollte der Käufer vermeiden, den vollen Wert zu zahlen.
19 Verbinden Sie Sorgfalt mit der Bewertung
Software-Diligence verändert den Wert durch Cashflow, Timing, Risiko und Optionslaufzeit. Sanierung erhöht die Kosten. Fehlende Rechte können den adressierbaren Umsatz verringern. Betriebsschwäche kann die Ausfallwahrscheinlichkeit erhöhen. Eine schwache Build-Kontrolle kann die Produktentwicklung verzögern. Starke Beweise können auf geringere Integrationsreserven und ein größeres Vertrauen in die Erneuerung hinweisen.
Durch die Bewertungsbrücke sollen Doppelanpassungen vermieden werden. Wiederkehrende Supportkosten gehören zum prognostizierten Cashflow. Ein einmaliger Rebuild gehört zu den Transaktions- oder Integrationsverwendungen. Ein Mangel an binären Rechten erfordert möglicherweise einen Ausschluss, ein Treuhandkonto oder eine Bedingung anstelle einer Abzinsungsprämie.
Der Käufer sollte Basis-, Nachteils- und schwerwiegende Fälle aufzeigen. Für jeden Fall sollten betriebliche Annahmen, Beweise und Managementmaßnahmen identifiziert werden. Der Endwert sollte die laufende Wartung, die Veralterung von Komponenten, die Lieferantenkonzentration und die Möglichkeit zur Auffrischung des Produkts widerspiegeln.
20 Übersetzen Sie Erkenntnisse in Transaktionsmechanismen
Wesentliche Ergebnisse sollten einen Eigentümer und eine Transaktionsantwort haben. Zu den möglichen Reaktionen gehören Preisnachlass, Zurückbehaltung, Treuhandkonto, Earn-out, Entschädigung, Abschlussbedingung, Vereinbarung, Übergangsservice, Lizenznovation, Schlüsselpersonenvereinbarung oder ausgeschlossener Vermögenswert.
Bedingungen sollten objektiv überprüfbar sein. Ohne definierte Repositorys, Zweige, Artefakte und Akzeptanztests ist die Anforderung, eine vollständige Quelle bereitzustellen, schwach. Eine Build-Bedingung kann Umgebung, Eingaben, erfolgreiche Testsuite und Bereitstellungspaket angeben. Eine Zugriffsbedingung kann Identitäten, Privilegien, Schlüssel und verifizierte Anmeldungen angeben.
Der Offenlegungsprozess sollte versionierte Beweise bewahren. Der Käufer sollte aufzeichnen, welche Artefakte jede Darstellung unterstützen und wer Ausnahmen akzeptiert hat. Technische Zeitpläne müssen von Ingenieuren und Beratern überprüft werden, damit die Rechtssprache der betrieblichen Realität entspricht.
21 Entwerfen Sie den Abschlusskontrollraum
Die Schließung sollte als betriebliche Änderung gehandhabt werden. Der Kontrollraum koordiniert den rechtlichen Abschluss, die Übertragung von Anmeldeinformationen, Lieferantennovationen, Cloud-Tenancy, Code-Repositories, Signaturberechtigung, Kundenbenachrichtigungen, Überwachung und Vorfallabdeckung.
Der Plan sollte explizite Go-, Hold- und Rollback-Kriterien verwenden. Jeder Schritt identifiziert Beweise, Zeitpunkt, verantwortliche Person und Fallback. Kritische Zugriffe sollten getestet werden, bevor irreversible Aktionen auftreten. Die Parteien sollten während des Zeitfensters mit dem höchsten Risiko eine gemeinsame Absicherung aufrechterhalten.
Der Käufer sollte Protokolle und Konfigurations-Snapshots aufbewahren. Diese Aufzeichnungen stellen den Zustand zum Zeitpunkt der Übertragung fest und unterstützen spätere Untersuchungen. Das erste Post-Close-Release sollte dem vereinbarten Assurance-Prozess folgen und nicht zu einem improvisierten Integrationstest werden.
22 Legen Sie die ersten 100 Tage fest
Die ersten 100 Tage sollen die Kontrolle stabilisieren, vorrangige Evidenzlücken schließen und die Konzentration verringern. Zu den frühen Maßnahmen gehören die erneute Zugriffszertifizierung, die Rotation von Anmeldeinformationen, saubere Builds, die Bestätigung von Abhängigkeiten, die Behebung kritischer Rückstände, Wiederherstellungstests, die Mitarbeiterbindung und die Lieferantenkontrolle.
Architekturänderungen sollten den Beweisen folgen. Eine sofortige Plattformmigration kann den Eigentumsübergang mit technischen Änderungen verbinden und vermeidbare Risiken schaffen. Das Integrationsteam sollte Änderungen nach Missionsfenstern, Kundenverpflichtungen und Wiederherstellungskapazitäten ordnen.
Der Vorstand sollte ein prägnantes Dashboard erhalten, das Build-Reproduzierbarkeit, kritische Schwachstellen, Schlüsselzugriff, Lieferantennovationen, Kundeneinwilligungen, Wiederherstellungstests, Wissenstransfer und Ausgaben abdeckt. Für die gemeldete Fertigstellung sollten objektive Beweise erforderlich sein.
23 Bestimmen Sie den kontinuierlichen Softwarewert
Die Post-Close-Governance sollte den Zustand der Software mit den kommerziellen und finanziellen Ergebnissen in Verbindung bringen. Zu den technischen Maßnahmen gehören Bereitstellungszuverlässigkeit, Fehlerflucht, Schwachstellenalter, Build-Integrität, Wiederherstellungsleistung und Abhängigkeitsstatus. Zu den kommerziellen Maßnahmen gehören Serviceverfügbarkeit, Erneuerung, Lieferlatenz und Supportkosten.
Die Produkt-Roadmap sollte zwischen obligatorischer Wartung, Kundenverpflichtungen, Sicherheitsbehebung und Wachstumsinvestitionen unterscheiden. Aufgeschobene Wartungsarbeiten können die kurzfristigen Erträge in die Höhe treiben und gleichzeitig die zukünftige Cash-Generierung schwächen. Anlageausschüsse sollten diesen Unterschied verstehen.
Der Käufer sollte ein Nachweisregister für kritische Rechte, Konfigurationen und Lieferanten führen. Änderungen im Besitz, in der Lizenz, im Support oder in der Architektur können die Akquisitionsthese verändern. Jährliche Assurance- und regelmäßige Überprüfungen der Transaktionsbereitschaft bewahren die Möglichkeit einer Refinanzierung oder eines Ausstiegs.
24 Hypothetischer Transaktionsfall
Das hypothetische Ziel unterstützt 18 Satelliten in den Bereichen Kommunikation, Erdbeobachtung und gehostete Nutzlastmissionen. Seine Plattform umfasst Missionsplanung, Befehlsvalidierung, Telemetrieverarbeitung, Flugdynamik, Automatisierung und Kundenlieferung. Der Umsatz wird durch jährliche Software- und Betriebsverträge generiert.
Diligence bestätigt eine starke Kundenbindung und kompetente Technik. Außerdem werden fünf Transaktionsrisiken identifiziert. Für Produktions-Builds ist ein undokumentiertes kommerzielles Tool erforderlich. Zwei Bibliotheken sind für die Muttergesellschaft des Verkäufers lizenziert und können nicht automatisch übertragen werden. Ein Administrator steuert wichtige Produktions- und Signaturprozesse. Die Behebung kritischer Schwachstellen wurde um Missionsfenster herum verschoben. Ein kundenspezifischer Adapter enthält Beiträge mit unvollständigem Zuordnungsnachweis.
Der Käufer bewertet diese Ergebnisse durch einen Gesamtabzug von USD 25 million vom Hauptwert USD 84 million. Ein weiterer USD 6 million-Earn-Out ist verfügbar, wenn definierte Evidence-Gates erreicht werden. Die Struktur gewährleistet die Beteiligung des Verkäufers an der Sanierung und schützt gleichzeitig die Barmittel des Käufers beim Abschluss.
25 Entscheidungsgrundsätze
Definieren Sie zunächst die erworbene Missionsfähigkeit und ihren Einsatzumfang. Zweitens: Verfolgen Sie jedes kritische eingesetzte Artefakt anhand kontrollierter Quellen-, Bau- und Genehmigungsnachweise. Drittens getrenntes Eigentum, Zugang, Rechte und Betriebsbefugnis. Viertens: Ordnen Sie die Lieferanten- und Personalkonzentration der Kontinuität zu. Fünftens: Testwiederherstellung und Transaktionsumstellung. Sechstens: Übersetzen Sie jede ungelöste Abhängigkeit in Geld, Bedingung oder vertraglichen Schutz.
Diese Grundsätze schaffen eine gemeinsame Sprache für die Teams aus den Bereichen Technik, Finanzen, Betrieb und Recht. Sie verbessern auch die Transaktionsgeschwindigkeit, da Beweisanforderungen und Akzeptanztests konkreter werden.
Ziel des Käufers ist die nachweisbare Kontrolle über die Missionsergebnisse. Diese Kontrolle unterstützt Kontinuität, Kundenvertrauen, Integration und vertretbare Bewertungen.
26 Überprüfen Sie Architektur und technische Schulden
Architekturdiligence sollte erklären, wie das System Missionsplanung, Flugdynamik, Befehlsvalidierung, Telemetrie, Automatisierung, Identität, Datenspeicher und externe Schnittstellen trennt. Der Käufer sollte Vertrauensgrenzen, Fehlerdomänen, gemeinsam genutzte Dienste und Komponenten identifizieren, deren Änderung sich auf mehrere Missionen auswirken könnte. Architekturdiagramme sollten mit der bereitgestellten Topologie, den Netzwerkflüssen und dem Repository-Eigentum abgeglichen werden.
Technische Schulden sollten durch Konsequenzen ausgedrückt werden. Eine alte Programmiersprache kann beherrschbar bleiben, wenn Fachwissen, Tests und Toolchains vorhanden sind. Ein moderner Dienst kann fragil sein, wenn es ihm an Eigenverantwortung, Beobachtbarkeit oder Wiederherstellung mangelt. Das Diligence-Team sollte die Kosten, die Reihenfolge und das Betriebsrisiko jedes wesentlichen Schuldenpostens abschätzen.
Bei der Schuldenklassifizierung sollte zwischen Wartbarkeit, Sicherheit, Leistung, Skalierbarkeit, Obsoleszenz und Compliance unterschieden werden. Das Geschäftsmodell sollte die Kategorien widerspiegeln, die das Wachstum oder die Kundenbindung einschränken. Sanierungspläne sollten Abhängigkeiten und Missionsfenster identifizieren und keinen undifferenzierten Rückstand darstellen.
27 Beobachtbarkeit und Vorfallbeweise bewerten
Der Wert der Missionskontrolle hängt von der Fähigkeit ab, abnormales Verhalten zu erkennen und zu erklären. Der Käufer sollte Protokolle, Metriken, Spuren, Warnungen, Dashboards, Aufbewahrung, Uhrensynchronisierung und Vorfallaufzeichnungen überprüfen. Es sollte ermitteln, wo Daten generiert werden, wer darauf zugreifen kann und ob Datensätze einen System- oder Lieferantenausfall überstehen.
Die Alarmqualität verdient eine Probenahme. Große Mengen nicht umsetzbarer Warnungen können wesentliche Ereignisse verschleiern. Spärliche Warnungen können auf eine begrenzte Abdeckung hinweisen. Das Team sollte ausgewählte Vorfälle mit aufgezeichneten Telemetriedaten, Reaktionsmaßnahmen, Ursachenanalysen und Korrekturarbeiten vergleichen. Wiederholte Vorfälle ohne dauerhafte Sanierung deuten auf Kontrollschwächen hin.
Bei der Transaktionsplanung sollte die Überwachungskontinuität gewahrt bleiben. Kontomigration, Cloud-Trennung oder Tool-Ersatz können zu Blindzeiten führen. Der Abschlussplan sollte festlegen, welche Alarme aktiv bleiben, wer sie erhält und wie das gemeinsame Team ein Ereignis während des Übergangs behandelt. Der Nachweis einer stabilen Überwachung kann einen kürzeren Zeitraum für die Übergangsdienste unterstützen.
28 Skalierbarkeit und Flottenerweiterung testen
Die historische Leistung beweist nicht, dass die Plattform die geplante Flotte des Käufers unterstützen kann. Das Team sollte Skalierungsfaktoren wie Satelliten, Kontakte, Telemetrievolumen, Befehlslast, Kundenschnittstellen, gleichzeitige Betreiber und Bodenstandorte identifizieren. Es sollte die beobachtete Spitzenauslastung und die Kapazitätsmargen überprüfen.
Auslastungstests sollten repräsentative Nachrichtenmuster und Fehlerbedingungen verwenden. Weltraumoperationen können zu kurzen Phasen intensiver Aktivität rund um den Start, die Inbetriebnahme, Anomalien und Kontaktfenster führen. Die durchschnittliche Auslastung kann in diesen Zeiträumen Warteschlangen, Datenbankkonflikte oder Bedienerüberlastungen verbergen.
Der Wachstumsfall sollte Infrastruktur-, Lizenz-, Support- und Personalkosten umfassen. Eine technisch skalierbare Plattform kann durch die Preisgestaltung pro Satellit eines Anbieters oder durch den Mangel an Fachkräften an kommerzielle Grenzen stoßen. Das Bewertungsmodell sollte die Wachstumserlöse mit den dafür erforderlichen Kapital- und Betriebskosten in Einklang bringen.
29 Bewerten Sie die Funktionen der künstlichen Intelligenz sorgfältig
Ziele können maschinelles Lernen zur Anomalieerkennung, Planung, Bildverarbeitung, vorausschauenden Wartung oder Bedienerunterstützung nutzen. Bei der Sorgfaltsprüfung sollten die genaue unterstützte Entscheidung, der Modellbesitzer, die Trainingsdatenrechte, die Validierung, die Überwachung, die menschliche Aufsicht und die Fehlerreaktion ermittelt werden. Marketingbeschreibungen liefern nur begrenzte Hinweise auf den operativen Wert.
Der Käufer sollte die behauptete Leistung mit einer definierten Basislinie und repräsentativen Einsatzdaten vergleichen. Dabei sollten Falsch-Positiv- und Falsch-Negativ-Ergebnisse, Drift, Umschulung, Versionskontrolle und Grenzfälle untersucht werden. Ein Modell, das die Durchschnittserkennung verbessert, kann dennoch für Befehlsentscheidungen ungeeignet sein, wenn seine Fehlermodi undurchsichtig sind.
Generative Tools, die in der Technik oder im Betrieb eingesetzt werden, erfordern die Kontrolle sensibler Daten, die Herkunft des Codes und die Überprüfung der Ausgabe. Die Produkt-Roadmap sollte den nachgewiesenen Kundennutzen von der experimentellen Leistungsfähigkeit trennen. Bei der Bewertung sollten mit AI verbundene Einnahmen nur erfasst werden, wenn Rechte, Leistung, Bereitstellung und Barumwandlung nachgewiesen sind.
30 Überprüfen Sie die Exportkontrolle und die Beschränkungen des souveränen Zugangs
Satellitensoftware, technische Daten und Dienste können Exportkontrollen, Sanktionen, Sicherheitsklassifizierungen und Hoheitsbefugnissen unterliegen. Der Käufer sollte kontrollierte Artikel, Lizenzen, Nationalitäten, Standorte, Cloud-Regionen und Kundenbeschränkungen abbilden. Ein Fachberater sollte die geltende Rechtsordnung auslegen.
Der betriebliche Zugriff kann auch bei Eigentumsübertragungen eingeschränkt sein. Bestimmte Kunden benötigen möglicherweise freigegebenes Personal, inländisches Hosting oder getrennten Support. Die Eigentums- und Finanzierungsstruktur des Käufers kann eine Prüfung oder Zustimmung auslösen. Diese Faktoren wirken sich auf das Integrationsdesign und die Fähigkeit zur Zentralisierung von Abläufen aus.
Das Transaktionsmodell sollte Compliance-Personal, getrennte Umgebungen, Lizenzzeitpunkte und mögliche Umsatzbeschränkungen umfassen. Abschlussbedingungen sollten Genehmigungen berücksichtigen, die für die Kontinuität erforderlich sind. Das Management sollte pauschale Zusicherungen vermeiden und den genauen Umfang ermitteln, der von jeder Genehmigung abgedeckt wird.
31 Erstellen Sie ein Beweispaket für den Investitionsausschuss
Der Investitionsausschuss benötigt eine prägnante Verbindung zwischen technischen Erkenntnissen und wirtschaftlichen Entscheidungen. Das Paket sollte mit den erworbenen Fähigkeiten, der Umsatzabhängigkeit und den kritischen Kontrollpunkten beginnen. Es sollte die Quelle und den Aufbau von Beweisen, die Rechteposition, die Lieferantenkarte, die betriebliche Belastbarkeit, die Zustimmung der Kunden und die Konzentration der Mitarbeiter darstellen.
Bei jedem Materialbefund sollten der Beweisstatus, die finanziellen Konsequenzen, der vorgeschlagene Mechaniker, der verantwortliche Eigentümer und das Restrisiko angegeben werden. Der Ausschuss sollte in der Lage sein, eine bestätigte Lücke von einer Managementschätzung und einem zukünftigen Sanierungsversprechen zu unterscheiden. Die Szenarioanalyse sollte die Auswirkungen von Verzögerungen und kombinierten Ausfällen zeigen.
Die Genehmigung sollte Bedingungen, delegierte Befugnisse und Berichterstattung nach dem Abschluss enthalten. Das Beweispaket wird dann zur Grundlage für die Integrationsgovernance. Diese Kontinuität verringert das Risiko, dass Prüfungsergebnisse nach dem Abschluss verschwinden, und unterstützt die spätere Verantwortung für die Wertschöpfung.
32 Planen Sie die Trennung vom Verkäufer
Eine Ausgliederung erfordert ein Trennungsmodell, das Anwendungen, Infrastruktur, Identitäten, Netzwerke, Verträge, Daten und Personen abdeckt. Der Käufer sollte Dienstleistungen identifizieren, die beim Verkäufer verbleiben, Dienstleistungen, die übertragen werden, und Dienstleistungen, die neu aufgebaut werden müssen. Jede Linie sollte über eine vorläufige Betriebsweise, einen Zielzustand, Kosten, Abhängigkeiten und ein Ausstiegskriterium verfügen.
Übergangsdienstvereinbarungen sollten messbare Dienste und betriebliche Verantwortlichkeiten beschreiben. Sie sollten Servicelevel, Sicherheitsverpflichtungen, Vorfallkoordination, Zugriff, Änderungskontrolle, Datenrückgabe, Prüfrechte, Preise und Kündigung festlegen. Eine umfassende Verpflichtung zur Bereitstellung angemessener Hilfe kann dazu führen, dass kritische Missionsbedürfnisse ungelöst bleiben.
Der Trennungsplan sollte den Missionseinschränkungen entsprechen. Identitäts- oder Netzwerkänderungen können sich auf Überwachungs- und Befehlspfade auswirken. Die Datenmigration kann sich auf den Verlauf und die Prüfungsnachweise auswirken. Eine Lieferantennovation kann die Supportrechte ändern. Die Parteien sollten risikoreiche Änderungen durchführen und Rollbacks durchführen, bis die Akzeptanzkriterien erfüllt sind.
Die Ausstiegsbereitschaft sollte getestet werden, bevor ein Übergangsdienst endet. Der Käufer sollte unabhängigen Zugriff, Erstellung, Bereitstellung, Überwachung, Support und Wiederherstellung nachweisen. Es sollte außerdem bestätigt werden, dass Verkäuferkonten und -daten ohne Unterbrechung des Dienstes entfernt werden können. Für jede Erweiterung sollte es einen definierten Grund, einen Preis und einen Behebungsverantwortlichen geben.
Trennungskosten gehören in das Transaktionsmodell. Dazu gehören doppelte Infrastruktur, temporäre Lizenzen, Migrationstechnik, Sicherheitstests, Kundenvalidierung und Betriebsüberschneidungen. Die Schätzung sollte zwischen verbindlichen Angeboten und Annahmen des Managements unterscheiden. Ein finanzierter und geregelter Trennungsplan schützt die Kontinuität und verhindert, dass die Transaktion eine unbegrenzte Abhängigkeit vom Verkäufer mit sich bringt.
Der Vorstand sollte ein wöchentliches Trennungs-Dashboard erhalten, bis alle geschäftskritischen Dienste unabhängig voneinander arbeiten. Das Dashboard sollte überfällige Abhängigkeiten, getestete Exits, ungelöste Kundenverpflichtungen, prognostizierte Kosten und die nächste unumkehrbare Aktion identifizieren. Für die Schließung sollten Nachweise der Technik, des Betriebs, der Sicherheit, der Finanzen und des jeweiligen Diensteeigentümers erforderlich sein.
Anhang A Sorgfaltsnachweisregister
Das Beweisregister sollte die Frage, das angeforderte Artefakt, den Quelleneigentümer, die Version, das Überprüfungsergebnis, die Ausnahme, die finanziellen Konsequenzen und die Transaktionsantwort identifizieren. Es sollte mit dem virtuellen Datenraum verbunden bleiben, damit Schlussfolgerungen reproduziert werden können.
Zu den Beweisen mit hoher Priorität gehören das Produktionsinventar, die Repository-Karte, das Clean-Build-Ergebnis, die Bereitstellungsverfolgung, das Berechtigungsinventar, der Lizenzplan, die SBOM, der Schwachstellenrückstand, der Wiederherstellungstest, die Kundeneinwilligungskarte und der Schlüsselpersonenplan. Jeder Punkt sollte die genauen abgedeckten Systeme und Konfigurationen angeben.
Die Probenahme sollte risikobasiert erfolgen. Das Team sollte repräsentative Missionen mit hoher Tragweite, kritische Schnittstellen, aktuelle Versionen, Notfalländerungen und ältere Komponenten auswählen. Anhand von Beispielen sollten sowohl das Steuerungsdesign als auch die tatsächliche Ausführung getestet werden.
Anhang B Bewertungsmethode
Die illustrative Methode beginnt mit dem Unternehmenswert, der aus dem Geschäftsmodell des Käufers abgeleitet wird. Anschließend passt es den prognostizierten Cashflow an wiederkehrende Wartungs- und Lieferantenkosten an. Einmalige Sanierungs-, Trennungs- und Übergangskosten sind in den Nutzungen enthalten. Umsätze, die der Zustimmung des Kunden unterliegen, werden wahrscheinlichkeitsgewichtet. Rechtsmängel und Betriebsbedingungen werden durch Abzüge, Treuhandkonten oder bedingte Gegenleistungen behoben.
Die Szenarioanalyse sollte verwandte Risiken kombinieren. Eine Verzögerung des Lieferanten kann auch die Abhilfe und die Akzeptanz durch den Kunden verzögern. Der Abgang einer Schlüsselperson kann sowohl die Kontinuität als auch den Wissenstransfer schwächen. Der damit verbundene Nachteil verdient eine ausdrückliche Behandlung.
Keine hypothetische Zahl in diesem Dokument stellt eine identifizierte Transaktion dar. Der Fall zeigt, wie Beweise mit der Bewertung und der Transaktionsstruktur verknüpft werden können.
Anhang C Abschließende Abnahmetests
Abnahmetests sollten den Repository-Zugriff, Clean Build, Testausführung, Paketsignierung, Nicht-Produktionsbereitstellung, Konfigurationswiederherstellung, Überwachung, privilegierten Zugriff, Lieferantenunterstützung und Wiederherstellung abdecken. Die Parteien sollten sich vor der Unterzeichnung auf Testdaten, Umgebung, Bestehenskriterien und Nachweise einigen.
Durch Tests sollen Live-Betriebsunterbrechungen vermieden werden. Produktionsänderungen erfordern eine Auftragsgenehmigung und separate Kontrollen. Ein nicht produktionsbezogener Test kann dennoch die Kette von der kontrollierten Quelle bis zum einsetzbaren Artefakt validieren.
Fehlgeschlagene Tests sollten vordefinierte Konsequenzen haben. Dazu können Heilung, Treuhand, verspäteter Abschluss, reduzierte Gegenleistung oder Ausschluss eines Vermögenswerts gehören. Die Reaktion sollte der betrieblichen und finanziellen Bedeutung des Fehlers entsprechen.
Anhang D Entscheidungszahlen und -tabellen
Illustrativer Beweisverlauf; Die Werte sind hypothetisch und stellen kein identifiziertes Unternehmen dar.
Höhere Werte weisen im hypothetischen Fall auf eine größere Abhängigkeit hin.
Vorgeschlagene Reihenfolge; Der tatsächliche Zeitpunkt hängt von den Transaktionsfakten und den Missionseinschränkungen ab.
Völlig hypothetische Werte; USD Millionen.
Vorgeschlagene Reihenfolge abhängig von Missionsfenstern und Kundenverpflichtungen.
| Beweis | Transaktionsfrage | Akzeptanzindikator | Reaktion auf Lücke |
|---|---|---|---|
| Repository-Inventar | Wird die Herkunft aller Materialien kontrolliert? | Produktionskomponenten werden auf benannte Repositorys zurückverfolgt | Abschlussbedingung oder bereichsbezogener Ausschluss |
| Build-Definition | Kann eine saubere Umgebung eine Freisetzung bewirken? | Erfolgreicher kontrollierter Build mit dokumentierten Eingaben | Rückhalte- und Sanierungsplan |
| Herkunft | Können eingesetzte Artefakte zurückverfolgt werden? | Version, Abhängigkeiten, Genehmigung und Signatur verknüpft | Risikoreserve und Kontrollsanierung |
| Generierte Artefakte | Sind Modelle und Generatoren verfügbar? | Wiederaufbau aus kontrollierten Quellen möglich | Bedingung für die Übertragung einer Lizenz oder eines Vermögenswerts |
Vorgeschlagene Anforderungen an Transaktionsnachweise.
| Abhängigkeit | Beweis | Hauptexposition | Transaktionsbehandlung |
|---|---|---|---|
| Mitarbeitercode | Arbeits- und Erfindungsbedingungen | Eigentumslücke | Abtretung und Gewährleistung |
| Auftragnehmerarbeit | Leistungsbeschreibung und Aufgabenstellung | Eingeschränkte Änderung oder Übertragung | Spezifische Abtretung oder Entschädigung |
| Kommerzielle Software | Lizenz- und Supportbedingungen | Nichtübertragung, Kündigung oder Preisrücksetzung | Novation, Ersatz oder Abzug |
| Open-Source-Software | SBOM, Lizenz- und Vertriebsaufzeichnung | Compliance und Wartung | Heilungsplan und fortlaufende Governance |
| Kundenschnittstelle | Vertrags- und Beitragshistorie | Die Nutzung ist auf Bestandskunden beschränkt | Einwilligung oder bedingter Wert |
Vorgeschlagene rechtliche und betriebliche Abhängigkeitsklassifizierung.
| Artikel | USD Millionen | Beweisgrundlage | Behandlung |
|---|---|---|---|
| Gesamtwert des Unternehmens | 84 | Kommerzielles Modell | Startwert |
| Sanierung und Übergang | -9 | Bau-, Verwundbarkeits- und Trennungsplan | Schlussabzug |
| Rechte und Abhängigkeiten | -7 | Lizenz- und Herkunftslücken | Abzug oder Treuhandkonto |
| Konzentration und Zerbrechlichkeit | -5 | Zugang und Überprüfung durch Schlüsselpersonen | Integrationsreserve |
| Kundenakzeptanz | -4 | Einwilligung und Schnittstellennachweis | Bedingte Gegenleistung |
| Barwert bei Abschluss | 59 | Aggregiertes Framework | Anschauliches Ergebnis |
Völlig hypothetisch; USD Millionen.
| Kontrolle | Beweismittel vor der Übergabe | Abschlussaktion | Überprüfung nach dem Abschluss |
|---|---|---|---|
| Repositories | Zugriffsliste und geschützte Zweige | Transferadministratoren | Gleichen Sie Zugriff und Protokolle ab |
| Unterzeichnung | Schlüsselinventur und Genehmigungskette | Schlüssel drehen oder neu registrieren | Testen Sie eine signierte Nicht-Produktionsversion |
| Produktionszugang | Berechtigungsinventur | Nur-Verkäufer-Konten widerrufen | Rezertifizieren Sie den Zugriff von Personen und Diensten |
| Lieferanten | Vertrags- und Einwilligungsplan | Novationen durchführen | Bestätigen Sie Support- und Vorfallkontakte |
| Erholung | Aktuelles Trainings- und Backup-Inventar | Schnappschüsse aufbewahren | Führen Sie eine kontrollierte Wiederherstellung durch |
Vorgeschlagene Kontrollen; Die tatsächliche Reihenfolge hängt von den Missionseinschränkungen ab.
| Messen | Beweise für Tag 30 | Beweise für Tag 60 | Beweise für Tag 100 |
|---|---|---|---|
| Baukontrolle | Saubere Umgebung geschaffen | Kritische Produkte reproduziert | Die Beweise für die routinemäßige Freigabe sind vollständig |
| Zugang | Administratoren erneut zertifiziert | Dienstkonten zugewiesen | Ausnahmen geschlossen oder akzeptiert |
| Schwachstellen | Kritischer Rückstand validiert | Vorrangige Heilmittel getestet | Nachhaltiges Serviceniveau im Betrieb |
| Lieferanten | Kritische Abhängigkeiten bestätigt | Novationen und Ersatz kamen voran | Governance- und Ausstiegspläne genehmigt |
| Wissen | Schlüsselrollen bleiben erhalten | Runbooks und Pairing sind im Gange | Unabhängige Betriebsabdeckung getestet |
Vorgeschlagene Evidenzmeilensteine.
| Finden | Cash-Effekt | Vertragsmechaniker | Beweise für die Freilassung |
|---|---|---|---|
| Nicht übertragbare Abhängigkeit | USD 7 million | Treuhandkonto oder Preisabzug | Durchgeführte Novation oder qualifizierter Ersatz |
| Zerbrechlichkeit aufbauen | USD 4 million | Abschlussbedingung | Erfolgreicher sauberer Build und Test |
| Abhängigkeit von Schlüsselpersonen | USD 3 million | Aufbewahrungsgebundener Holdback | Meilensteine des Wissenstransfers |
| Kundenspezifische Rechte | USD 4 million | Earn-out | Einwilligung und einbehaltener Bargeldeinzug |
Völlig hypothetische Geldeffekte; USD Millionen.
| Entscheidungsbereich | Grüne Beweise | Bernsteinfarbener Zustand | Roter Zustand |
|---|---|---|---|
| Quellcodeverwaltung | Vollständig nachverfolgbare Repositorys | Kleinere kontrollierte Lücken | Wichtige Quelle oder Verlauf fehlen |
| Bauen | Wiederholbare kontrollierte Freisetzung | Manuelle Schritte mit finanzierter Heilung | Build kann nicht reproduziert werden |
| Rechte | Übertragbare dokumentierte Rechte | Einwilligung mit Schutz ausstehend | Materialrecht nicht verfügbar |
| Operationen | Unabhängige Personalabdeckung | Konzentration mit geprüftem Übergang | Abhängigkeit von einer benannten Person ohne Fallback |
| Erholung | Kürzlich erfolgreiche Wiederherstellung | Teilumfang oder Altersübung | Wiederherstellung ungetestet oder nicht verfügbar |
Vorgeschlagene Entscheidungsschwellen.
Quellen
- National Institute of Standards and Technology, SP 800-218 Secure Software Development Framework Version 1.1, 2022. Lesen Sie die Primärquelle
- National Institute of Standards and Technology, SP 800-161 Revision 1 Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, 2022. Lesen Sie die Primärquelle
- National Institute of Standards and Technology, Leitfaden zur Softwaresicherheit in Lieferketten, aktualisiert 2024. Lesen Sie die Primärquelle
- National Institute of Standards and Technology, Cybersecurity Framework 2.0, 2024. Lesen Sie die Primärquelle
- Nationales Institut für Standards und Technologie, NISTIR 8401 Satelliten-Bodensegment zur Anwendung des Cybersicherheits-Frameworks auf die Satellitensteuerung und -steuerung, 2022. Lesen Sie die Primärquelle
- National Institute of Standards and Technology, SP 800-53 Revision 5 Sicherheits- und Datenschutzkontrollen für Informationssysteme und Organisationen. Lesen Sie die Primärquelle
- Nationale Luft- und Raumfahrtbehörde, NASA Software Engineering and Assurance Handbook NASA-HDBK-2203. Lesen Sie die Primärquelle
- Nationale Luft- und Raumfahrtbehörde, SWE-042 Quellcode Elektronischer Zugriff. Lesen Sie die Primärquelle
- Nationale Luft- und Raumfahrtbehörde, SWE-158, Evaluierung von Software auf Sicherheitslücken. Lesen Sie die Primärquelle
- Nationale Luft- und Raumfahrtbehörde, SWE-206 Software-Eingaben zur automatischen Generierung. Lesen Sie die Primärquelle
- Nationale Luft- und Raumfahrtbehörde, NPR 7150.2 NASA-Software-Engineering-Anforderungen. Lesen Sie die Primärquelle
- Nationale Luft- und Raumfahrtbehörde, NASA-STD-8739.8 Software Assurance und Software Safety Standard. Lesen Sie die Primärquelle
- Nationale Luft- und Raumfahrtbehörde, NASA-STD-1006A Weltraumsystemschutzstandard. Lesen Sie die Primärquelle
- Nationale Luft- und Raumfahrtbehörde, Best Practices-Leitfaden für Weltraumsicherheit. Lesen Sie die Primärquelle
- Agentur für Cybersicherheit und Infrastruktursicherheit, Sicherung der empfohlenen Vorgehensweisen für die Software-Lieferkette für Entwickler, 2023. Lesen Sie die Primärquelle
- Agentur für Cybersicherheit und Infrastruktursicherheit, Software-Stückliste. Lesen Sie die Primärquelle
- Agentur für Cybersicherheit und Infrastruktursicherheit, Secure by Design. Lesen Sie die Primärquelle
- Agentur für Cybersicherheit und Infrastruktursicherheit, Playbooks der Bundesregierung zur Reaktion auf Cybersicherheitsvorfälle und Sicherheitslücken. Lesen Sie die Primärquelle
- Europäische Weltraumorganisation, Softwareprodukte für Missionsoperationen. Lesen Sie die Primärquelle
- Europäische Weltraumorganisation, SPACE-SHIELD – Schädliche Lieferkettenfunktionen und Software-Schwachstellen. Lesen Sie die Primärquelle
- Agentur der Europäischen Union für Cybersicherheit, ENISA Space Threat Landscape 2025. Lesen Sie die Primärquelle
- Beratender Ausschuss für Weltraumdatensysteme, Missionsbetrieb und Informationsmanagementdienste. Lesen Sie die Primärquelle
- Beratender Ausschuss für Weltraumdatensysteme, Veröffentlichungen der Sicherheitsarbeitsgruppe. Lesen Sie die Primärquelle
- United States Office of Space Commerce, Space Policy Directive 5 Cybersecurity Principles for Space Systems. Lesen Sie die Primärquelle
- Nationales Cyber-Sicherheitszentrum des Vereinigten Königreichs, Cyber-Sicherheits-Toolkit für Vorstände. Lesen Sie die Primärquelle
- Offenes weltweites Anwendungssicherheitsprojekt, Standard zur Überprüfung von Softwarekomponenten. Lesen Sie die Primärquelle
- Offenes weltweites Anwendungssicherheitsprojekt, Software Assurance Maturity Model. Lesen Sie die Primärquelle
- Die Linux Foundation, SPDX-Softwarepaket-Datenaustausch. Lesen Sie die Primärquelle
- Internationale Organisation für Normung, ISO IEC 27001 Informationssicherheits-Managementsysteme. Lesen Sie die Primärquelle
- Europäische Zusammenarbeit für Weltraumstandardisierung, ECSS Software Engineering Standards. Lesen Sie die Primärquelle
