Invoering
Software bevindt zich tussen de satelliet, het grondnetwerk, operators, klanten en toezichthouders. Missiecontrolesystemen plannen contacten, valideren en verzenden commando's, ontvangen en verwerken telemetrie, bewaken de gezondheid van ruimtevaartuigen, berekenen banen, beheren laadschema's en bewaren de operationele gegevens. Een defecte, niet-beschikbare afhankelijkheid of een ontoegankelijke handtekeningsleutel kan de inkomsten onderbreken en de bevelsautoriteit verzwakken, zelfs als het onderliggende ruimtevaartuig technisch gezond blijft.
Een overname houdt dus meer in dan een conventionele softwareproductbeoordeling. De koper moet het missiesysteem begrijpen zoals het wordt gebruikt. Dat systeem omvat bronrepository's, build-pijplijnen, configuratiegegevens, implementatieomgevingen, cryptografisch materiaal, grondinterfaces, runbooks, leveranciersdiensten, technisch oordeel en contractuele rechten. Verschillende van deze elementen kunnen buiten de juridische entiteit van het doelwit vallen of afhankelijk zijn van met name genoemde personen.
In dit artikel wordt een transactiekader voor dat probleem uiteengezet. Het is ontworpen voor strategische kopers, infrastructuurinvesteerders, particuliere kapitaalbedrijven, satellietexploitanten, kredietverstrekkers en besturen die een softwaregestuurde ruimtevaarttransactie beoordelen. Het richt zich op bewijsmateriaal dat controle, continuïteit, prijs, voorwaarden en integratieontwerp verandert.
1 Definieer de verworven capaciteit
De koper moet beginnen met een capaciteitsverklaring. De verklaring identificeert welke missies, ruimtevaartuigen, ladingen, grondlocaties, klantenservices en operationele beslissingen de software ondersteunt. Het registreert servicevensters, beschikbaarheidsverwachtingen, gevolgen voor de veiligheid, wettelijke verplichtingen en omzetafhankelijkheden. Productnamen alleen al bieden een onbetrouwbare perimeter, omdat één merkplatform afhankelijk kan zijn van afzonderlijke vluchtdynamiek, planning, identiteit, database, monitoring en grondstationdiensten.
In de capaciteitsverklaring moet onderscheid worden gemaakt tussen vluchtsoftware en grondsoftware. Acquisities op het gebied van satellietcontrole richten zich doorgaans op het grondsegment, terwijl de operationele waarde kan afhangen van ingebedde vluchtinterfaces en ruimtevaartuigspecifieke commandodatabases. De koper heeft bewijs nodig dat het doelwit elke interface die nodig is voor voortgezette activiteiten mag gebruiken, wijzigen en overdragen.
De perimeter moet ook uitgesloten diensten identificeren. Gedeelde bedrijfsidentiteit, cloudabonnementen, communicatieverbindingen, sleutelbeheerdiensten, datacenters of personeel van het moederbedrijf kunnen vanaf de eerste dag essentieel zijn. Elke uitsluiting wordt een transitievereiste, een voortdurende afhankelijkheid of een waardeaanpassing.
2 Afzonderlijk eigendom, toegang en controle
Juridisch eigendom is een element van controle. De koper heeft ook fysieke of logische toegang nodig, voldoende rechten om te wijzigen en in te zetten, kennis om te kunnen werken en autoriteit over inloggegevens en vrijgavebeslissingen. Deze elementen kunnen uiteenlopen. Een doelwit kan over aangepaste broncode beschikken terwijl hij afhankelijk is van een niet-overdraagbare bibliotheek. Het kan over een repository beschikken, terwijl de productie-build afhankelijk is van de privé-toolchain van een consultant. Het kan over ruime licenties beschikken, terwijl een overheidsklant de goedkeuring van de implementatie controleert.
Het diligencemodel moet eigendom, bezit, toegang, wijzigingsrechten, distributierechten, operationele bevoegdheden en beëindigingsrechten afzonderlijk vastleggen. Voor elk item is bewijsmateriaal nodig. Relevant bewijsmateriaal omvat opdrachten, arbeidsvoorwaarden, contractovereenkomsten, licentieschema's, repository-machtigingen, implementatiegegevens, klantcontracten en leveranciersbevestigingen.
Controle heeft ook een tijdsdimensie. Toegang die bestaat tijdens diligence kan bij sluiting vervallen. De koper moet de exacte acties identificeren die nodig zijn om toegang tot de repository, cloudhuur, ondertekeningsbevoegdheid, beheerdersreferenties, monitoringgeschiedenis en leveranciersondersteuning via de transactiegrens te behouden.
3 Bouw de software- en afhankelijkheidsinventaris op
De inventaris moet applicaties, diensten, repositories, branches, build-systemen, implementatiepakketten, databases, interfaces, commerciële producten, open-sourcecomponenten, cryptografische bibliotheken en operationele scripts identificeren. Het moet elke component verbinden met de missiefunctie die het ondersteunt en de omgeving waarin het draait.
Een SBOM kan de ontdekking van componenten versnellen. Het vervangt niet de bedrijfsinventaris. Een nuttige acquisitie-inventaris koppelt de componentnaam en -versie aan de bron, licentie, onderhouder, kwetsbaarheidsstatus, build-artefact, geïmplementeerde configuratie, gegevensafhankelijkheid en vervangingspad. Componenten die zijn ingebed in containers, firmware of apparaten van leveranciers vereisen aandacht omdat ze afwezig kunnen zijn in een conventionele lijst met applicaties.
De koper moet drie standpunten met elkaar verzoenen: wat volgens de techniek bestaat, wat de opslagplaatsen bevatten en wat de productietelemetrie laat zien. Verschillen zijn diligence-bevindingen. Een niet-geregistreerde dienst kan van cruciaal belang zijn. Een beursgenoteerde repository kan verouderd zijn. Een productiebinair bestand mag niet herleidbaar zijn tot een goedgekeurde broncommit.
4 Test de volledigheid van de broncode
Toegang tot de repository moet het volledige product en de geschiedenis ervan omvatten. De koper moet de bron, configuratie, infrastructuurdefinities, databaseschema's, testmiddelen, buildscripts, implementatieautomatisering, documentatie en probleemgeschiedenis inspecteren. Een momentopname van geselecteerde bestanden kan de volledigheid niet aantonen.
Het testen van de volledigheid begint vanaf de ingezette artefacten. Het team identificeert representatieve productiebinaire bestanden of containers en traceert deze terug naar bronrevisies, afhankelijkheidsversies, buildparameters en goedkeuringsrecords. Vervolgens bouwt het de software in een gecontroleerde omgeving en vergelijkt het resultaat met het ingezette artefact of de gedocumenteerde herkomst ervan. Verschillen vereisen uitleg.
Gegenereerde code verdient een aparte behandeling. In de richtlijnen van NASA wordt erkend dat onderhoud op de lange termijn toegang kan vereisen tot modellen, simulaties, datadefinities, generatoren, builddata, testscripts en verwachte resultaten. Het bezit van een gegenereerde bron kan onvoldoende zijn als de generator, het model of de gekwalificeerde configuratie ontbreekt.
5 Reproduceer de build
Een reproduceerbare build is een hoogwaardige diligence-test. Het doel is om aan te tonen dat een geautoriseerd team een inzetbare release kan creëren van gecontroleerde inputs zonder ongedocumenteerde tussenkomst. Bij de test moet gebruik worden gemaakt van een schone omgeving en de gedocumenteerde procedure van het doelwit. Waarnemers van kopers moeten de vereisten, externe downloads, inloggegevens, handmatige stappen, toolversies, waarschuwingen en afwijkingen vastleggen.
Het resultaat hoeft niet bit-voor-bit identiek te zijn als het bestaande proces geen deterministische compilatie ondersteunt. Het moet traceerbaar en functioneel gelijkwaardig zijn onder overeengekomen tests. De koper moet begrijpen waarom er enig verschil ontstaat en of het proces de integriteit bewaart.
Een mislukte build kan ontbrekende licenties, verlopen certificaten, niet-beschikbare pakketrepository's, ongedocumenteerde patches of de afhankelijkheid van een met name genoemde ingenieur aan het licht brengen. Deze bevindingen houden rechtstreeks verband met de transitiekosten en het continuïteitsrisico. De koopovereenkomst kan een succesvolle, schone bouw vereisen voordat deze wordt gesloten, of een borgsom plaatsen totdat aan de voorwaarde is voldaan.
6 Traceer de vrijgave- en implementatiebevoegdheid
Toegang tot de bron betekent niet dat de productie kan worden uitgevoerd. De koper moet de autoriteit traceren vanaf de goedkeuring van de code tot en met de build, ondertekening, release, implementatie en rollback. De tracering identificeert wie wijzigingen kan goedkeuren, wie ondertekeningsreferenties heeft, waar pakketten worden opgeslagen, hoe omgevingen worden gepromoot en hoe noodreleases worden gecontroleerd.
Veranderingen in de satellietcontrole kunnen gevolgen hebben voor de missieveiligheid. Vrijgavebewijs moet bestaan uit verificatieresultaten, beoordeling van de operationele gereedheid, goedkeuring van de configuratie, toestemming van de klant of autoriteit, indien van toepassing, en een geteste herstelroute. De koper moet onderscheid maken tussen routinematige applicatie-releases en wijzigingen in commandovalidatie, vluchtdynamiek, telemetrie-interpretatie of cryptografisch vertrouwen.
De overdracht van legitimatiebewijzen vereist een ontworpen proces. Privésleutels en geprivilegieerde inloggegevens mogen tijdens het afsluiten niet terloops worden gekopieerd. De partijen moeten overeenstemming bereiken over rotatie, intrekking, herinschrijving, dubbele controle, behoud van audits en terugdraaien. In het afsluitingsplan moet worden vermeld wanneer de operationele bevoegdheid verandert en hoe dubbelzinnige verantwoordelijkheid wordt vermeden.
7 Onderzoek de configuratiegegevens van de missie
Mission-control-software is afhankelijk van configuratie die net zo waardevol kan zijn als de broncode. Commandowoordenboeken, telemetriedefinities, limieten, kalibratiegegevens, modellen van ruimtevaartuigen, contactplannen, orbitale parameters, automatiseringsregels en klantroutering bepalen hoe generieke software samenwerkt met een echte vloot.
De koper moet voor elke configuratieklasse de gezaghebbende bron, het goedkeuringsproces, de versiegeschiedenis en de herstelmethode identificeren. Er moet worden getest of een nieuwe omgeving kan worden gevuld vanuit gecontroleerde records. Op spreadsheets gebaseerde of lokaal opgeslagen configuraties creëren risico's als er geen controle, overzicht en back-up aanwezig is.
Configuratierechten zijn ook van belang. Een klant, fabrikant van ruimtevaartuigen of systeemintegrator kan een deel van de gegevens bezitten of beperken. In de overnameovereenkomst moeten de overdracht, het voortgezette gebruik, de vertrouwelijkheid, de exportbeperkingen en de verwijderingsverplichtingen worden geregeld. Ontbrekende configuratie kan anderszins complete software onbruikbaar maken voor een specifieke missie.
8 Beoordeel het bewijsmateriaal voor softwareborging
Bewijsmateriaal voor softwareborging laat zien of het product is ontwikkeld en onderhouden via gecontroleerde praktijken. NIST's SSDF organiseert veilige ontwikkeling rond het voorbereiden van de organisatie, het beschermen van software, het produceren van goed beveiligde software en het reageren op kwetsbaarheden. NASA-richtlijnen voor softwareborging voegen objectief bewijs toe voor veiligheids- en missiecontexten.
De koper moet de traceerbaarheid van vereisten, architectuurbeslissingen, codebeoordeling, statische analyse, afhankelijkheidsscans, testdekking, vrijgavegoedkeuring, defectgeschiedenis en reactie op kwetsbaarheden beoordelen. Bewijs moet overeenkomen met de versies in productie. Een beleidsdocument zonder uitgevoerde vastleggingen biedt beperkte zekerheid.
Het diligenceteam moet kritieke paden onderzoeken, zoals het genereren van commando's, authenticatie, privilegebeheer, baanbepaling en herstel. Er moet worden onderzocht of de tests ongunstige en randvoorwaarden omvatten. Openstaande bevindingen moeten worden geclassificeerd op basis van de gevolgen van de missie, exploiteerbaarheid, herstelbaarheid en herstelafhankelijkheid.
9 Breng de softwaretoeleveringsketen in kaart
De supply chain omvat commerciële leveranciers, open-sourceprojecten, cloudproviders, buildservices, pakketrepository's, hardwareleveranciers, consultants en gespecialiseerde operators. De koper moet in kaart brengen welke partijen het product kunnen veranderen, onderbreken, er toegang toe krijgen of het kunnen beperken.
Voor elke kritische leverancier moet de zorgvuldigheid betrekking hebben op contractuele ondersteuning, financiële veerkracht, beveiligingspraktijken, toegangsprivileges, melding van incidenten, wijzigingscontrole, beleid inzake het einde van de levenscyclus, de locatie van gegevens en de doorlooptijd van vervanging. Een leverancier die meerdere bedrijfskritische componenten ondersteunt, creëert concentratie, zelfs als de jaarlijkse uitgaven klein zijn.
NIST SP 800-161 behandelt risico's in de toeleveringsketen als een organisatorisch bestuursprobleem in plaats van als een inkoopchecklist. Het transactieteam moet leveranciersbewijs koppelen aan systeemkriticiteit en gepland eigendom. Materiaalleveranciers kunnen vóór sluiting toestemming, schuldvernieuwing of directe overeenstemming vereisen.
10 Analyseer de blootstelling aan open source
Open-sourcecomponenten kunnen de mogelijkheden verbeteren en de ontwikkeltijd verkorten. Ook scheppen ze licentie-, onderhouds- en beveiligingsverplichtingen. De koper moet de aangegeven componenten afstemmen op het scannen van codes en manifesten bouwen. Het moet licentievoorwaarden, wijzigingen, mededelingen, distributiepraktijken en bekende kwetsbaarheden identificeren.
Copyleft-blootstelling vereist een juridische analyse op basis van feitelijk gebruik en distributie. Een licentielabel alleen schept niet de verplichting. Het team moet documenteren hoe componenten worden gekoppeld, ingezet, aangepast en aan klanten worden geleverd. Herstel kan bestaan uit correctie van kennisgevingen, bronaanbiedingen, vervanging van componenten of communicatie met klanten.
De onderhoudsstatus heeft invloed op de waarde. Voor een kritieke bibliotheek zonder actieve onderhouder of ondersteunde release kan intern eigendom nodig zijn. De koper moet de forkstrategie, de testdekking, de patchmogelijkheden en de afhankelijkheid van de gemeenschap beoordelen. Een softwarestuklijst moet na afsluiting actueel blijven en mag geen statisch zorgvuldigheidsartefact worden.
11 Herziening van de herkomst van intellectueel eigendom
Elke bijdrage aan de materiële code moet een verdedigbaar herkomstpad hebben. Uitvindingen van werknemers moeten binnen passende arbeidsvoorwaarden vallen. Opdrachtnemerwerkzaamheden dienen met voldoende omvang te worden opgedragen. Verkregen of bijgedragen code moet over de benodigde rechten beschikken. Door universiteiten, overheden of door klanten gefinancierde ontwikkelingen kunnen beperkingen inhouden die een gedetailleerde beoordeling vereisen.
Het team moet de commitgeschiedenis vergelijken met de records en contracten van de bijdragers. Niet-herkende auteurs, persoonlijke verhalen of onverklaarde bulkimporten verdienen onderzoek. De beoordeling moet documentatie, modellen, testgegevens, gebruikersinterfaces en algoritmen omvatten, omdat waardevol intellectueel eigendom verder reikt dan bronbestanden.
De analyse van octrooien en bedrijfsgeheimen moet zich richten op het eigenlijke product- en commerciële plan. De koper moet inzicht hebben in defensieve registraties, vrijheid van handelen, vertrouwelijkheidscontroles en elke openbaarmaking die de bescherming van bedrijfsgeheimen zou kunnen verzwakken. Transactiedocumenten kunnen specifieke herkomstrisico's toewijzen door middel van garanties, schadevergoedingen, borgstellingen of voorwaardelijke vergoedingen.
12 Test geprivilegieerde toegang en segregatie
Mission-control-omgevingen concentreren krachtige privileges. Beheerders kunnen opdrachten, identiteit, databases, cloudbronnen, ondertekeningssleutels en monitoring beheren. De koper moet een privilege-inventaris verkrijgen die personeels-, service- en noodaccounts omvat in ontwikkelings-, test-, productie- en herstelomgevingen.
Bij de beoordeling moeten de controles op joiner, mover en leaver worden getest; meervoudige authenticatie; goedkeuring; sessieregistratie; referentierotatie; toegang tot breekglas; en scheiding tussen ontwikkeling en productie. Gedeelde of slapende accounts verminderen de verantwoordelijkheid. Voor serviceaccounts zijn eigendoms- en levenscycluscontroles vereist.
Sluiting brengt een verhoogd toegangsrisico met zich mee. Vertrekkend personeel kan de inloggegevens of kennis van herstelpaden behouden. Het transitieplan moet gevoelige referenties rouleren, oude toegang intrekken, bewijsmateriaal behouden en dubbele operationele dekking behouden. Deze acties moeten worden geoefend wanneer verlies van toegang een live missie zou kunnen beïnvloeden.
13 Beoordeel het beheer van kwetsbaarheden
De koper moet begrijpen hoe kwetsbaarheden worden ontdekt, beoordeeld, verholpen en gecommuniceerd. Bronnen zijn onder meer statische analyses, afhankelijkheidsscans, penetratietesten, klantrapporten, leveranciersadviezen en operationele monitoring. Het programma moet de ernst, de gevolgen van de missie, de timing van het herstel, de goedkeuring van uitzonderingen en het opnieuw testen definiëren.
Achterstandanalyse kan verborgen onderhoudsbehoeften aan het licht brengen. De koper moet de leeftijd, het herhalingspatroon, de getroffen versies en de kwaliteit van de sluiting onderzoeken. Een lage telling kan een zwakke detectie weerspiegelen. Een hoog aantal kan actieve ontdekking weerspiegelen. De nuttige maatstaf is het vermogen van de organisatie om relevante blootstelling te identificeren en deze binnen op risico gebaseerde tijdsbestekken te verminderen.
Vlucht- en grondsystemen kunnen beperkte patchvensters hebben. Het doel moet laten zien hoe het compenserende controles toepast en veilige introducties plant. Bekende kwetsbaarheden in ontoegankelijke of end-of-life componenten kunnen een specifieke prijsaftrek of gefinancierde herstelreserve rechtvaardigen.
14 Beoordeel interfaces en interoperabiliteit
Software voor satellietcontrole is afhankelijk van interfaces met ruimtevaartuigen, grondstations, netwerken, identiteitssystemen, klantenplatforms, weergegevens, baangegevens en regelgevende diensten. De koper dient voor elke interface het protocol, de versie, de eigenaar, de prestatie-eisen, de beveiligingscontrole, de testomgeving en het wijzigingsproces te inventariseren.
Interfacedocumentatie moet worden getest aan de hand van waargenomen verkeer en huidige configuraties. Eigen of ongedocumenteerde interfaces creëren lock-in. Een standaardprotocol kan nog steeds klantspecifieke uitbreidingen bevatten die vervanging bemoeilijken.
Het team moet faalmodi testen. Het moet vertraagde gegevens, dubbele berichten, klokfouten, beschadigde invoer, netwerkonderbreking en gedeeltelijk serviceverlies waarnemen. Herstelgedrag heeft invloed op de operationele waarde. Integratieplannen moeten de waarneembaarheid van de interface behouden en voorkomen dat meerdere kritische afhankelijkheden tegelijk worden gewijzigd.
15 Evalueer gegevensrechten en -registraties
Operationele gegevens ondersteunen monitoring, anomalieanalyse, modelverbetering, klantrapportage en bewijsmateriaal uit de regelgeving. De koper dient onderscheid te maken tussen eigendom, bewaring, toegestaan gebruik, retentie en exportrechten voor telemetrie, opdrachten, afgeleide producten, logs, klantinformatie en trainingsgegevens.
De transactieperimeter moet historische gegevens bevatten die nodig zijn om het systeem te laten werken en verbeteren. Een koper kan software ontvangen zonder voldoende operationele geschiedenis om waarschuwingen af te stemmen of afwijkingen te onderzoeken. Bij datamigratie moeten de tijdstempels, herkomst, toegangscontroles en bewijsintegriteit behouden blijven.
Privacy- en lokalisatieverplichtingen kunnen van toepassing zijn op personeels- en klantgegevens. Exportcontroles en nationale veiligheidsbeperkingen kunnen van invloed zijn op technische gegevens en toegang door buitenlandse personen. De juridische analyse moet de verplichtingen in kaart brengen voor feitelijke datasets en operationele locaties.
16 Onderzoek operationele veerkracht en herstel
Veerkrachttests moeten uitwijzen hoe de dienstverlening doorgaat door falen van infrastructuur, software, leveranciers en mensen. De koper moet redundantie, back-ups, herstelomgevingen, communicatiealternatieven, handmatige procedures, hersteldoelstellingen en trainingsresultaten beoordelen.
Een back-up is alleen nuttig als deze binnen de tolerantie van de missie kan worden hersteld. Het diligenceteam moet een representatieve herstel- en valideringsconfiguratie, inloggegevens, afhankelijkheden en gegevensintegriteit observeren. Herstel moet de mogelijkheid omvatten om systemen opnieuw op te bouwen wanneer de primaire omgeving of leverancier niet beschikbaar is.
De overname zelf moet worden beschouwd als een veerkrachtgebeurtenis. Bedrijfssystemen, domeinen, cloudaccounts en ondersteuningscontracten kunnen veranderen. Een gedetailleerd overgangsplan, terugdraaicriteria, commandobevoegdheid en een gezamenlijk incidentproces verminderen het transitierisico.
17 Beoordeel mensen en kennisconcentratie
Softwarecontinuïteit is afhankelijk van mensen die architectuur, missies, afwijkingen, klanten en operationeel oordeel begrijpen. De koper moet rollen toewijzen aan kritieke processen en afzonderlijke kennispunten identificeren. Organigrammen bieden beperkt bewijs; de kaart moet weerspiegelen wie daadwerkelijk incidenten oplost en releases goedkeurt.
Bij beslissingen over bewaring moet rekening worden gehouden met zowel het technische belang als de onafhankelijkheid. Geconcentreerde kennis kan worden verminderd door paren, documentatie, repetitie en opvolging. Retentiebetalingen zonder mijlpalen voor kennisoverdracht kunnen de afhankelijkheid in stand houden in plaats van verminderen.
Het transactiemodel moet werving, behoud, conversie van contractanten en opleidingskosten omvatten. Het sleutelpersoonrisico kan van invloed zijn op de waardering wanneer capaciteiten niet binnen de overgangsperiode kunnen worden overgedragen. Het management moet de voortgang rapporteren aan de hand van genoemd bewijsmateriaal voor kennisoverdracht.
18 Beoordeel de acceptatie door klanten en regelgevende instanties
Klantcontracten kunnen softwareprestaties, beveiliging, audit-, goedkeurings- en wijzigingsverplichtingen definiëren. De koper moet contracten identificeren waarvoor toestemming, kennisgeving, hercertificering of genoemd personeel vereist is. Er moet een onderscheid worden gemaakt tussen de inkomsten die automatisch worden overgedragen en de inkomsten die afhankelijk zijn van de acceptatie door de klant.
Klanten uit de overheid en kritieke infrastructuur kunnen beperkingen opleggen op het gebied van technische gegevens, veiligheidsmachtigingen, hosting of toeleveringsketen. De koper moet beoordelen of zijn eigendom, financiering, personeel en bedrijfsmodel in aanmerking blijven komen. Regelgevende licenties en spectrumrechten kunnen buiten de software-entiteit vallen, terwijl ze essentieel blijven voor de dienstverlening.
Het commerciële model zou onzekere verlengingen en toestemmingen moeten wegen naar de waarschijnlijkheid. De vergoeding kan afhankelijk zijn van geverifieerde overdracht of ingehouden inkomsten. De koper moet vermijden de volledige waarde te betalen voor contracten waarvan de operationele vereisten niet worden overgedragen.
19 Verbind zorgvuldigheid met waardering
Software diligence verandert de waarde via cashflow, timing, risico en levensduur van opties. Sanering verhoogt de kosten. Ontbrekende rechten kunnen de adresseerbare inkomsten verminderen. operationele kwetsbaarheid kan de kans op uitval vergroten. Zwakke bouwcontrole kan de productontwikkeling vertragen. Sterk bewijsmateriaal kan lagere integratiereserves en een groter vertrouwen in vernieuwing ondersteunen.
De waarderingsbrug moet dubbele aanpassingen vermijden. Terugkerende ondersteuningskosten horen thuis in de verwachte cashflow. Een eenmalige herbouw hoort thuis in transactie- of integratiegebruik. Een gebrek aan binaire rechten kan uitsluiting, borgstelling of een voorwaarde vereisen in plaats van een disconteringspremie.
De koper moet basis-, negatieve en ernstige gevallen laten zien. In elk geval moeten operationele aannames, bewijsmateriaal en managementacties worden geïdentificeerd. De eindwaarde moet het voortdurende onderhoud, de veroudering van componenten, de leveranciersconcentratie en de mogelijkheid om het product te vernieuwen weerspiegelen.
20 Bevindingen vertalen naar transactiemechanismen
Materiële bevindingen moeten een eigenaar en een transactiereactie hebben. Mogelijke reacties zijn onder meer prijsverlaging, holdback, escrow, earn-out, schadevergoeding, sluitingsvoorwaarde, convenant, transitieservice, licentievernieuwing, sleutelpersoonovereenkomst of uitgesloten activa.
De omstandigheden moeten objectief toetsbaar zijn. Een vereiste om een volledige bron te verstrekken is zwak zonder gedefinieerde repositories, vertakkingen, artefacten en acceptatietests. Een bouwvoorwaarde kan de omgeving, invoer, succesvolle testsuite en implementatiepakket specificeren. Een toegangsvoorwaarde kan identiteiten, privileges, sleutels en geverifieerde login specificeren.
Bij het openbaarmakingsproces moeten versieversies van bewijsmateriaal bewaard blijven. De koper moet vastleggen welke artefacten elke representatie ondersteunen en wie uitzonderingen heeft geaccepteerd. Technische schema's moeten worden beoordeeld door ingenieurs en adviseurs, zodat de juridische taal overeenkomt met de operationele realiteit.
21 Ontwerp de afsluitende controlekamer
De sluiting moet worden beheerd als een operationele wijziging. De controlekamer coördineert de juridische afhandeling, de overdracht van legitimatiegegevens, leveranciersnovatie, cloudhuur, codeopslagplaatsen, ondertekeningsbevoegdheid, klantkennisgevingen, monitoring en incidentdekking.
Het plan moet expliciete go-, hold- en rollback-criteria gebruiken. Elke stap identificeert bewijsmateriaal, timing, verantwoordelijke persoon en terugval. Kritieke toegang moet worden getest voordat onomkeerbare acties plaatsvinden. De partijen moeten gedurende de periode met het hoogste risico een gezamenlijke dekking behouden.
De koper moet logboeken en configuratiemomentopnamen bewaren. Deze gegevens stellen de staat bij de overdracht vast en ondersteunen later onderzoek. De eerste release na afsluiting moet het overeengekomen borgingsproces volgen en geen geïmproviseerde integratietest worden.
22 Bepaal de eerste 100 dagen
De eerste honderd dagen zouden de controle moeten stabiliseren, de hiaten in het prioritaire bewijsmateriaal moeten dichten en de concentratie moeten verminderen. Vroege acties omvatten hercertificering van toegang, rotatie van referenties, schone builds, bevestiging van afhankelijkheid, herstel van kritieke achterstanden, hersteltests, personeelsbehoud en leveranciersbeheer.
Architectuurveranderingen moeten het bewijs volgen. Een onmiddellijke platformmigratie kan de eigendomsoverdracht combineren met technische veranderingen en vermijdbare risico's met zich meebrengen. Het integratieteam moet de veranderingen op het gebied van missievensters, klantverplichtingen en herstelcapaciteit opvolgen.
Het bestuur zou een beknopt dashboard moeten krijgen over de reproduceerbaarheid van de build, kritieke kwetsbaarheden, sleuteltoegang, vernieuwingen van leveranciers, toestemmingen van klanten, hersteltests, kennisoverdracht en uitgaven. Voor de gerapporteerde voltooiing moet objectief bewijsmateriaal nodig zijn.
23 Beheer de voortdurende waarde van software
Post-close governance moet de gezondheid van software koppelen aan commerciële en financiële resultaten. Technische maatregelen omvatten de betrouwbaarheid van de implementatie, het ontsnappen van defecten, de ouderdom van kwetsbaarheden, de integriteit van de build, de herstelprestaties en de afhankelijkheidsstatus. Commerciële maatregelen omvatten de beschikbaarheid van diensten, verlenging, latentie van levering en ondersteuningskosten.
In de productroadmap moet onderscheid worden gemaakt tussen verplicht onderhoud, klantverplichtingen, beveiligingsherstel en groei-investeringen. Uitgesteld onderhoud kan de kortetermijnwinsten opdrijven en tegelijkertijd de toekomstige kasstroomgeneratie verzwakken. Beleggingscomités moeten dat onderscheid begrijpen.
De koper dient een bewijsregister bij te houden voor kritische rechten, configuraties en leveranciers. Veranderingen in eigendom, licentie, ondersteuning of architectuur kunnen de acquisitiethese veranderen. Jaarlijkse zekerheid en periodieke beoordelingen van de gereedheid voor transacties behouden de mogelijkheid tot herfinanciering of exit.
24 Hypothetisch transactiegeval
Het hypothetische doelwit ondersteunt 18 satellieten voor communicatie-, aardobservatie- en gehoste payload-missies. Het platform omvat missieplanning, commandovalidatie, telemetrieverwerking, vluchtdynamiek, automatisering en klantlevering. Inkomsten worden gegenereerd via jaarlijkse software- en operationele contracten.
Diligence bevestigt een sterke klantenbinding en capabele engineering. Het identificeert ook vijf transactieblootstellingen. Voor productiebuilds is een ongedocumenteerd commercieel hulpmiddel vereist. Twee bibliotheken zijn in licentie gegeven aan de moedermaatschappij van de verkoper en kunnen niet automatisch worden overgedragen. Eén beheerder beheert de belangrijkste productie- en ondertekeningsprocessen. Het herstel van kritieke kwetsbaarheden is uitgesteld rond missievensters. Een klantspecifieke adapter bevat bijdragen met onvolledig opdrachtbewijs.
De koper prijst deze bevindingen door middel van een totale USD 25 million-aftrek van de nominale waarde van USD 84 million. Er is nog een USD 6 million-earn-out beschikbaar als aan de gedefinieerde bewijspoorten wordt voldaan. De structuur behoudt de deelname van de verkoper aan de sanering en beschermt tegelijkertijd het geld van de koper bij de sluiting.
25 Beslissingsprincipes
Definieer eerst de verworven missiecapaciteit en de operationele perimeter ervan. Ten tweede: traceer elk kritisch ingezet artefact tot gecontroleerd bron-, constructie- en goedkeuringsbewijs. Ten derde: gescheiden eigendom, toegang, rechten en operationele autoriteit. Ten vierde: breng de concentratie van leveranciers en mensen in kaart met continuïteit. Ten vijfde: test het herstel en de transactie-cutover. Ten zesde: vertaal elke onopgeloste afhankelijkheid in geld, voorwaarden of contractuele bescherming.
Deze principes creëren een gemeenschappelijke taal voor engineering-, financiële, operationele en juridische teams. Ze verbeteren ook de transactiesnelheid omdat bewijsverzoeken en acceptatietests specifiek worden.
Het doel van de inkoper is aantoonbare controle over de missieresultaten. Die controle ondersteunt continuïteit, klantvertrouwen, integratie en verdedigbare waardering.
26 Review architectuur en technische schulden
Architectuurdiligence moet verklaren hoe het systeem missieplanning, vluchtdynamiek, commandovalidatie, telemetrie, automatisering, identiteit, gegevensopslag en externe interfaces scheidt. De koper moet vertrouwensgrenzen, faaldomeinen, gedeelde diensten en componenten identificeren waarvan de verandering verschillende missies kan beïnvloeden. Architectuurdiagrammen moeten in overeenstemming worden gebracht met de geïmplementeerde topologie, netwerkstromen en eigendom van de repository.
Technische schulden moeten tot uitdrukking komen in de gevolgen. Een oude programmeertaal kan beheersbaar blijven als er expertise, tests en toolchains beschikbaar zijn. Een moderne dienst kan kwetsbaar zijn als het eigenaarschap, waarneembaarheid of herstel ontbeert. Het diligenceteam moet de kosten, de volgorde en het operationele risico van elke materiële schuldpost inschatten.
Bij de classificatie van schulden moet onderscheid worden gemaakt tussen onderhoudbaarheid, veiligheid, prestaties, schaalbaarheid, veroudering en compliance. Het commerciële model moet de categorieën weerspiegelen die de groei of het klantenbehoud belemmeren. Herstelplannen moeten afhankelijkheden en missievensters identificeren in plaats van een ongedifferentieerde achterstand te presenteren.
27 Evalueer de waarneembaarheid en het bewijs van incidenten
De waarde van de missiecontrole hangt af van het vermogen om abnormaal gedrag te detecteren en te verklaren. De koper moet logboeken, statistieken, sporen, waarschuwingen, dashboards, retentie, kloksynchronisatie en incidentrecords bekijken. Het moet identificeren waar gegevens worden gegenereerd, wie er toegang toe heeft en of de gegevens een systeem- of leveranciersfout overleven.
Alerte kwaliteit verdient bemonstering. Grote aantallen niet-uitvoerbare waarschuwingen kunnen materiële gebeurtenissen verbergen. Schaarse waarschuwingen kunnen een beperkte dekking weerspiegelen. Het team moet geselecteerde incidenten vergelijken met opgenomen telemetrie, responsacties, analyse van de hoofdoorzaak en corrigerend werk. Herhaalde incidenten zonder duurzaam herstel duiden op zwakte in de controle.
Transactieplanning moet de continuïteit van het toezicht waarborgen. Accountmigratie, cloudscheiding of vervanging van tools kunnen blinde perioden veroorzaken. Het sluitingsplan moet definiëren welke waarschuwingen actief blijven, wie ze ontvangt en hoe het gezamenlijke team omgaat met een gebeurtenis tijdens de overgang. Bewijs van stabiele monitoring kan een kortere periode van transitiediensten ondersteunen.
28 Test de schaalbaarheid en vlootuitbreiding
Uit historische prestaties blijkt niet dat het platform de geplande vloot van de koper kan ondersteunen. Het team moet schaalfactoren identificeren, zoals satellieten, contacten, telemetrievolume, commandobelasting, klantinterfaces, gelijktijdige operators en grondlocaties. Er moet een evaluatie worden gemaakt van de waargenomen piekbezetting en capaciteitsmarges.
Bij belastingstests moeten representatieve berichtpatronen en foutcondities worden gebruikt. Ruimteoperaties kunnen korte perioden van intense activiteit creëren rondom lancering, inbedrijfstelling, afwijkingen en contactvensters. Gemiddeld gebruik kan tijdens deze perioden wachtrijen, databaseconflicten of overbelasting van operators verbergen.
Het groeiscenario moet infrastructuur-, licentie-, ondersteunings- en personeelskosten omvatten. Een platform dat technisch schaalbaar is, kan te maken krijgen met commerciële beperkingen als gevolg van prijzen per satellietleverancier of schaarse specialisten. Het waarderingsmodel moet de groei-inkomsten afstemmen op de kapitaal- en bedrijfskosten die nodig zijn om deze groei te realiseren.
29 Beoordeel de kenmerken van kunstmatige intelligentie zorgvuldig
Doelen kunnen machine learning gebruiken voor het detecteren van afwijkingen, planning, beeldverwerking, voorspellend onderhoud of assistentie van operators. Diligence moet de exacte ondersteunde beslissing, modeleigenaar, trainingsgegevensrechten, validatie, monitoring, menselijk toezicht en reactie op fouten identificeren. Marketingbeschrijvingen bieden beperkt bewijs van de operationele waarde.
De koper moet de geclaimde prestaties vergelijken met een gedefinieerde basislijn en representatieve missiegegevens. Het moet valse positieven, valse negatieven, drift, herscholing, versiebeheer en randgevallen onderzoeken. Een model dat de gemiddelde detectie verbetert, kan nog steeds ongeschikt zijn voor commandobeslissingen als de faalmodi ondoorzichtig zijn.
Generatieve tools die worden gebruikt in engineering of operations hebben behoefte aan beheer van gevoelige gegevens, codeherkomst en outputbeoordeling. In de productroadmap moet de aangetoonde klantwaarde worden gescheiden van de experimentele mogelijkheden. Bij de waardering mogen AI-gerelateerde opbrengsten alleen worden erkend als de rechten, prestaties, inzet en contante conversie zijn bewezen.
30. Herziening van de exportcontrole en beperkingen op de toegang van overheden
Satellietsoftware, technische gegevens en diensten kunnen onderworpen zijn aan exportcontroles, sancties, veiligheidsclassificaties en vereisten voor soevereine toegang. De koper moet gecontroleerde artikelen, licenties, nationaliteiten, locaties, cloudregio's en klantbeperkingen in kaart brengen. Een gespecialiseerde raadsman moet het toepasselijke wettelijke regime interpreteren.
Operationele toegang kan beperkt zijn, zelfs wanneer het eigendom wordt overgedragen. Bepaalde klanten hebben mogelijk bevoegd personeel, binnenlandse hosting of gescheiden ondersteuning nodig. De eigendoms- en financieringsstructuur van de koper kunnen aanleiding geven tot beoordeling of toestemming. Deze factoren zijn van invloed op het integratieontwerp en de mogelijkheid om activiteiten te centraliseren.
Het transactiemodel moet compliance-personeel, gescheiden omgevingen, licentietiming en mogelijke inkomstenbeperkingen omvatten. De sluitingsvoorwaarden moeten betrekking hebben op goedkeuringen die noodzakelijk zijn voor de continuïteit. Het management moet brede garanties vermijden en de precieze reikwijdte van elke autorisatie vaststellen.
31 Maak een bewijspakket voor het investeringscomité
Het investeringscomité heeft behoefte aan een beknopte verbinding tussen technische bevindingen en economische beslissingen. Het pakket moet beginnen met de verworven capaciteiten, de inkomstenafhankelijkheid en de kritische controlepunten. Het moet de bron presenteren en bewijsmateriaal, de rechtenpositie, de leverancierskaart, de operationele veerkracht, de toestemming van de klant en de concentratie van mensen opbouwen.
Elke materiële bevinding moet de status van het bewijsmateriaal, het financiële gevolg, het voorgestelde mechanisme, de verantwoordelijke eigenaar en het resterende risico aantonen. De commissie moet een geverifieerd hiaat kunnen onderscheiden van een managementschatting en een toekomstige herstelbelofte. Scenarioanalyse moet het effect van vertragingen en gecombineerde mislukkingen aantonen.
Bij goedkeuring moeten de voorwaarden, gedelegeerde bevoegdheden en rapportage na afsluiting worden vermeld. Het bewijsmateriaal wordt dan de basis voor integratiebeheer. Deze continuïteit verkleint het risico dat de bevindingen van de zorgvuldigheid na de afsluiting verdwijnen en ondersteunt de latere verantwoording voor waardecreatie.
32 Plan scheiding van de verkoper
Een carve-out vereist een scheidingsmodel dat applicaties, infrastructuur, identiteiten, netwerken, contracten, data en mensen omvat. De koper moet diensten identificeren die bij de verkoper blijven, diensten die worden overgedragen en diensten die opnieuw moeten worden opgebouwd. Elke lijn moet een tussentijdse werkwijze, doelstatus, kosten, afhankelijkheid en exitcriterium hebben.
Transitiedienstovereenkomsten moeten meetbare diensten en operationele verantwoordelijkheden beschrijven. Ze moeten serviceniveaus, beveiligingsverplichtingen, incidentcoördinatie, toegang, wijzigingscontrole, gegevensteruggave, auditrechten, prijzen en beëindiging identificeren. Een brede inzet om redelijke hulp te bieden kan cruciale missiebehoeften onopgelost laten.
Het scheidingsschema moet de beperkingen van de missie volgen. Identiteits- of netwerkwijzigingen kunnen de monitoring- en opdrachtpaden beïnvloeden. Gegevensmigratie kan van invloed zijn op de geschiedenis en het auditbewijs. Leveranciersnovatie kan de ondersteuningsrechten wijzigen. De partijen moeten veranderingen met een hoog risico in gang zetten en het terugdraaien handhaven totdat aan de acceptatiecriteria is voldaan.
De exitgereedheid moet worden getest voordat een transitieservice eindigt. De koper moet onafhankelijke toegang, bouw, implementatie, monitoring, ondersteuning en herstel aantonen. Het moet ook bevestigen dat verkopersaccounts en gegevens kunnen worden verwijderd zonder de service te onderbreken. Elke uitbreiding moet een gedefinieerde reden, prijs en hersteleigenaar hebben.
Scheidingskosten horen thuis in het transactiemodel. Het omvat dubbele infrastructuur, tijdelijke licenties, migratie-engineering, beveiligingstests, klantvalidatie en operationele overlap. Bij de schatting moet onderscheid worden gemaakt tussen toegezegde prijsopgaven en aannames van het management. Een gefinancierd en beheerd scheidingsplan beschermt de continuïteit en voorkomt dat de transactie voor onbepaalde tijd afhankelijk is van de verkoper.
Het bestuur zou een wekelijks scheidingsdashboard moeten ontvangen totdat alle missiekritieke diensten onafhankelijk opereren. Het dashboard moet achterstallige afhankelijkheden, geteste exits, onopgeloste klantverplichtingen, voorspelde kosten en de volgende onomkeerbare actie identificeren. Voor de sluiting is bewijs vereist van de afdeling engineering, operations, beveiliging, financiën en de relevante service-eigenaar.
Bijlage A Diligence bewijsregister
Het bewijsregister moet de vraag, het aangevraagde artefact, de broneigenaar, de versie, het beoordelingsresultaat, de uitzondering, het financiële gevolg en de transactiereactie identificeren. Het moet gekoppeld blijven aan de virtuele dataroom, zodat conclusies kunnen worden gereproduceerd.
Bewijsmateriaal met hoge prioriteit omvat de productie-inventaris, repository-kaart, clean-build-resultaat, implementatietracering, privilege-inventaris, licentieschema, SBOM, kwetsbaarheidsachterstand, hersteltest, klanttoestemmingskaart en sleutelpersoonplan. Bij elk item moeten de exacte systemen en configuraties worden vermeld die worden behandeld.
De bemonstering moet risicogebaseerd zijn. Het team moet representatieve missies met hoge gevolgen, kritieke interfaces, recente releases, noodwijzigingen en oudere componenten kiezen. Monsters moeten zowel het ontwerp van de besturing als de daadwerkelijke uitvoering ervan testen.
Bijlage B Waarderingsmethode
De illustratieve methode begint met ondernemingswaarde afgeleid van het commerciële model van de koper. Vervolgens past het de verwachte cashflow aan voor terugkerende onderhouds- en leverancierskosten. Eenmalige sanerings-, scheidings- en transitiekosten zijn inbegrepen in de gebruiksdoeleinden. Opbrengsten die afhankelijk zijn van de toestemming van de klant, zijn waarschijnlijkheidsgewogen. Gebreken in rechten en operationele omstandigheden worden aangepakt door middel van inhoudingen, escrows of voorwaardelijke vergoedingen.
Scenarioanalyse moet de daarmee samenhangende risico's combineren. Een vertraging bij de leverancier kan ook het herstel en de acceptatie door de klant vertragen. Het vertrek van een sleutelpersoon kan zowel de continuïteit als de kennisoverdracht verzwakken. Het daarmee samenhangende nadeel verdient een expliciete behandeling.
Geen enkel hypothetisch getal in dit document vertegenwoordigt een geïdentificeerde transactie. De casus laat zien hoe bewijs kan worden gekoppeld aan waardering en transactiestructuur.
Bijlage C Afsluiten acceptatietesten
Acceptatietests moeten betrekking hebben op toegang tot de repository, schone build, testuitvoering, pakketondertekening, niet-productie-implementatie, configuratieherstel, monitoring, geprivilegieerde toegang, leveranciersondersteuning en herstel. De partijen moeten vóór ondertekening overeenstemming bereiken over de testgegevens, de omgeving, de criteria en het bewijsmateriaal.
Tests moeten live operationele verstoringen voorkomen. Productiewijzigingen vereisen goedkeuring van de missie en afzonderlijke controles. Een niet-productietest kan nog steeds de keten van gecontroleerde bron tot inzetbaar artefact valideren.
Mislukte tests moeten vooraf gedefinieerde gevolgen hebben. Deze kunnen onder meer herstel, escrow, vertraagde afsluiting, verminderde vergoeding of uitsluiting van een actief omvatten. De reactie moet overeenkomen met de operationele en financiële betekenis van de mislukking.
Bijlage D Beslissingscijfers en tabellen
Illustratieve bewijsvoortgang; waarden zijn hypothetisch en vertegenwoordigen geen geïdentificeerd bedrijf.
Hogere scores duiden op een grotere afhankelijkheid in het hypothetische geval.
Voorgestelde volgorde; de werkelijke timing hangt af van transactiefeiten en missiebeperkingen.
Geheel hypothetische waarden; USD miljoen.
Voorgestelde volgorde afhankelijk van missievensters en klantverplichtingen.
| Bewijs | Transactie vraag | Acceptatie-indicator | Reactie op kloof |
|---|---|---|---|
| Inventaris van opslagplaatsen | Wordt alle materiaalbron gecontroleerd? | Productiecomponenten traceren naar benoemde opslagplaatsen | Voltooiingsvoorwaarde of beperkte uitsluiting |
| Bouw definitie | Kan een schoon milieu vrijkomen? | Succesvolle gecontroleerde build met gedocumenteerde input | Holdback- en herstelplan |
| Herkomst | Kunnen ingezette artefacten worden getraceerd? | Versie, afhankelijkheden, goedkeuring en handtekening gekoppeld | Risicoreservering en controleherstel |
| Gegenereerde artefacten | Zijn er modellen en generatoren beschikbaar? | Herbouw mogelijk vanuit gecontroleerde bronnen | Licentie of voorwaarde voor overdracht van activa |
Voorgestelde vereisten voor bewijs van transacties.
| Afhankelijkheid | Bewijs | Belangrijkste blootstelling | Transactiebehandeling |
|---|---|---|---|
| Medewerkerscode | Arbeidsvoorwaarden en uitvindingsvoorwaarden | Eigendomskloof | Opdracht en garantie |
| Aannemer werk | Verklaring van werk en opdracht | Beperkte wijziging of overdracht | Specifieke overdracht of schadeloosstelling |
| Commerciële software | Licentie- en ondersteuningsvoorwaarden | Niet-overdracht, beëindiging of prijsreset | Vernieuwing, vervanging of aftrek |
| Open source-software | SBOM, licentie en distributierecord | Naleving en onderhoud | Genezingsplan en voortgezet bestuur |
| Klantinterface | Contract- en contributiegeschiedenis | Gebruik beperkt tot bestaande klant | Toestemming of voorwaardelijke waarde |
Voorgestelde juridische en operationele afhankelijkheidsclassificatie.
| Item | USD miljoen | Bewijsbasis | Behandeling |
|---|---|---|---|
| Hoofdondernemingswaarde | 84 | Commercieel model | Startwaarde |
| Sanering en transitie | -9 | Plan voor opbouw, kwetsbaarheid en scheiding | Afsluitende aftrek |
| Rechten en afhankelijkheden | -7 | Hiaten in licentie en herkomst | Aftrek of borg |
| Concentratie en kwetsbaarheid | -5 | Toegang en sleutelpersoonbeoordeling | Integratie reserve |
| Klantacceptatie | -4 | Toestemming en interfacebewijs | Voorwaardelijke overweging |
| Contante waarde bij afsluiting | 59 | Geaggregeerd raamwerk | Illustratief resultaat |
Geheel hypothetisch; USD miljoen.
| Controle | Bewijs vóór overdracht | Sluitende actie | Verificatie na afsluiting |
|---|---|---|---|
| Opslagplaatsen | Toegangslijst en beschermde takken | Beheerders van overdrachten | Stem toegang en logboeken af |
| Ondertekening | Belangrijke inventarisatie en goedkeuringsketen | Sleutels roteren of opnieuw registreren | Testondertekende niet-productierelease |
| Toegang tot productie | Privilege-inventaris | Accounts voor alleen verkopers intrekken | Certificeer de toegang voor mensen en diensten opnieuw |
| Leveranciers | Contract- en toestemmingsschema | Voer novaties uit | Bevestig ondersteunings- en incidentcontacten |
| Herstel | Laatste oefening en back-upinventaris | Bewaar momentopnamen | Voer gecontroleerd herstel uit |
Voorgestelde controles; de daadwerkelijke sequentie hangt af van de beperkingen van de missie.
| Meeteenheid | Dag 30 bewijs | Bewijs van dag 60 | Dag 100 bewijs |
|---|---|---|---|
| Bouw controle | Schone omgeving gevestigd | Kritieke producten gereproduceerd | Bewijsmateriaal voor routinematige vrijgave voltooid |
| Toegang | Beheerders opnieuw gecertificeerd | Serviceaccounts toegewezen | Uitzonderingen gesloten of geaccepteerd |
| Kwetsbaarheden | Kritieke achterstand gevalideerd | Prioriteitskuren getest | Duurzame serviceniveaus operationeel |
| Leveranciers | Kritieke afhankelijkheden bevestigd | Novaties en vervangers vorderden | Bestuurs- en exitplannen goedgekeurd |
| Kennis | Sleutelrollen behouden | Runbooks en koppeling zijn onderweg | Onafhankelijke operationele dekking getest |
Voorgestelde bewijsmijlpalen.
| Vinden | Contant effect | Contractmonteur | Bewijs voor vrijlating |
|---|---|---|---|
| Niet-overdraagbare afhankelijkheid | USD 7 million | Escrow of prijsaftrek | Uitgevoerde schuldvernieuwing of gekwalificeerde vervanging |
| Bouw kwetsbaarheid op | USD 4 million | Sluitingsconditie | Succesvol schoon bouwen en testen |
| Afhankelijkheid van sleutelpersonen | USD 3 million | Aan retentie gekoppelde holdback | Mijlpalen op het gebied van kennisoverdracht |
| Klantspecifieke rechten | USD 4 million | Verdien uit | Toestemming en ingehouden contante incasso |
Geheel hypothetische contante effecten; USD miljoen.
| Beslissingsgebied | Groen bewijs | Amberkleurige staat | Rode staat |
|---|---|---|---|
| Broncontrole | Volledige traceerbare opslagplaatsen | Kleine gecontroleerde hiaten | Ontbrekende kritische bron of geschiedenis |
| Bouwen | Herhaalbare gecontroleerde afgifte | Handmatige stappen met gefinancierde genezing | Bouw kan niet worden gereproduceerd |
| Rechten | Overdraagbare gedocumenteerde rechten | Toestemming in behandeling met bescherming | Materiaalrecht niet beschikbaar |
| Operaties | Onafhankelijke bemande dekking | Concentratie met beproefde overgang | Afhankelijkheid op naam zonder terugval |
| Herstel | Recent succesvol herstel | Gedeeltelijke reikwijdte of leeftijdsoefening | Herstel niet getest of niet beschikbaar |
Voorgestelde beslissingsdrempels.
Bronnen
- National Institute of Standards and Technology, SP 800-218 Secure Software Development Framework versie 1.1, 2022. Lees de primaire bron
- National Institute of Standards and Technology, SP 800-161 Revisie 1 Cybersecurity Supply Chain Risk Management Practices voor systemen en organisaties, 2022. Lees de primaire bron
- National Institute of Standards and Technology, Software Security in Supply Chains Guidance, bijgewerkt in 2024. Lees de primaire bron
- Nationaal Instituut voor Standaarden en Technologie, Cybersecurity Framework 2.0, 2024. Lees de primaire bron
- Nationaal Instituut voor Standaarden en Technologie, NISTIR 8401 Satellietgrondsegment Het cyberbeveiligingskader toepassen op satellietcommando en -controle, 2022. Lees de primaire bron
- National Institute of Standards and Technology, SP 800-53 Revisie 5 Beveiligings- en privacycontroles voor informatiesystemen en organisaties. Lees de primaire bron
- National Aeronautics and Space Administration, NASA Software Engineering and Assurance Handbook NASA-HDBK-2203. Lees de primaire bron
- National Aeronautics and Space Administration, SWE-042 Broncode elektronische toegang. Lees de primaire bron
- National Aeronautics and Space Administration, SWE-158 Evalueer software op beveiligingsproblemen. Lees de primaire bron
- National Aeronautics and Space Administration, SWE-206 Automatische generatie software-invoer. Lees de primaire bron
- National Aeronautics and Space Administration, NPR 7150.2 NASA Software Engineering-vereisten. Lees de primaire bron
- National Aeronautics and Space Administration, NASA-STD-8739.8 Software Assurance en Software Safety Standard. Lees de primaire bron
- National Aeronautics and Space Administration, NASA-STD-1006A Space System Protection Standard. Lees de primaire bron
- Nationale Luchtvaart- en Ruimtevaartadministratie, Gids voor beste praktijken op het gebied van ruimtebeveiliging. Lees de primaire bron
- Cybersecurity and Infrastructure Security Agency, Beveiliging van de softwaretoeleveringsketen Aanbevolen werkwijzen voor ontwikkelaars, 2023. Lees de primaire bron
- Agentschap voor cyberbeveiliging en infrastructuurbeveiliging, softwarestuklijst. Lees de primaire bron
- Agentschap voor cyberbeveiliging en infrastructuurbeveiliging, Secure by Design. Lees de primaire bron
- Agentschap voor cyberbeveiliging en infrastructuurbeveiliging, draaiboeken voor cyberbeveiligingsincidenten en respons op kwetsbaarheden van de federale overheid. Lees de primaire bron
- European Space Agency, softwareproducten voor missieoperaties. Lees de primaire bron
- European Space Agency, SPACE-SHIELD Schadelijke mogelijkheden van de toeleveringsketen en softwarekwetsbaarheden. Lees de primaire bron
- Agentschap van de Europese Unie voor cyberbeveiliging, ENISA Space Threat Landscape 2025. Lees de primaire bron
- Raadgevend Comité voor ruimtegegevenssystemen, missieoperaties en informatiebeheerdiensten. Lees de primaire bron
- Raadgevend Comité voor Ruimtegegevenssystemen, Publicaties van de Veiligheidswerkgroep. Lees de primaire bron
- United States Office of Space Commerce, Richtlijn ruimtevaartbeleid 5 Cyberbeveiligingsprincipes voor ruimtesystemen. Lees de primaire bron
- Nationaal Cyber Security Centre van het Verenigd Koninkrijk, Cyber Security Toolkit for Boards. Lees de primaire bron
- Open Worldwide Application Security Project, Software Component Verification Standard. Lees de primaire bron
- Open wereldwijd applicatiebeveiligingsproject, Software Assurance Maturity Model. Lees de primaire bron
- De Linux Foundation, SPDX-softwarepakketgegevensuitwisseling. Lees de primaire bron
- Internationale Organisatie voor Standaardisatie, ISO IEC 27001 Informatiebeveiligingsbeheersystemen. Lees de primaire bron
- Europese samenwerking voor ruimtestandaardisatie, ECSS Software Engineering Standards. Lees de primaire bron
