Introduzione
Il software si colloca tra il satellite, la rete di terra, gli operatori, i clienti e le autorità di regolamentazione. I sistemi di controllo missione pianificano i contatti, convalidano e trasmettono i comandi, ricevono ed elaborano la telemetria, monitorano lo stato di salute del veicolo spaziale, calcolano le orbite, gestiscono i programmi del carico utile e conservano il registro operativo. Un difetto, una dipendenza non disponibile o una chiave di firma inaccessibile possono interrompere i ricavi e indebolire l'autorità di comando anche quando il veicolo spaziale sottostante resta tecnicamente integro.
Un'acquisizione comporta quindi più di una revisione convenzionale di un prodotto software. L'acquirente deve comprendere il sistema di missione così come viene operato. Tale sistema comprende repository di codice sorgente, pipeline di build, dati di configurazione, ambienti di distribuzione, materiale crittografico, interfacce di terra, runbook, servizi dei fornitori, giudizio ingegneristico e diritti contrattuali. Diversi di questi elementi possono trovarsi al di fuori dell'entità giuridica del target o dipendere da persone specifiche.
Il presente documento definisce un quadro di riferimento per la transazione volto a risolvere tale problema. È destinato ad acquirenti strategici, investitori infrastrutturali, società di capitale privato, operatori satellitari, finanziatori e consigli di amministrazione che valutano un'operazione spaziale guidata dal software. Si concentra sulle evidenze che modificano controllo, continuità, prezzo, condizioni e progettazione dell'integrazione.
1 Definire la capacità acquisita
L'acquirente dovrebbe iniziare con una dichiarazione della capacità. La dichiarazione identifica quali missioni, veicoli spaziali, carichi utili, siti di terra, servizi ai clienti e decisioni operative il software supporta. Registra finestre di servizio, aspettative di disponibilità, conseguenze per la sicurezza, obblighi normativi e dipendenze dai ricavi. I soli nomi dei prodotti forniscono un perimetro inaffidabile, perché una singola piattaforma con marchio può dipendere da servizi separati di dinamica del volo, pianificazione, identità, database, monitoraggio e stazione di terra.
La dichiarazione della capacità dovrebbe distinguere il software di volo dal software di terra. Le acquisizioni di controllo satellitare si concentrano di solito sul segmento di terra, mentre il valore operativo può dipendere da interfacce di volo incorporate e da database di comandi specifici del veicolo spaziale. L'acquirente necessita di evidenze che il target possa utilizzare, modificare e trasferire ogni interfaccia necessaria per la prosecuzione delle operazioni.
Il perimetro dovrebbe inoltre identificare i servizi esclusi. Identità aziendale condivisa, abbonamenti cloud, collegamenti di comunicazione, servizi di gestione delle chiavi, data center o personale della società madre possono essere essenziali fin dal primo giorno. Ogni esclusione diventa un requisito di transizione, una dipendenza permanente o una rettifica di valore.
2 Separare proprietà, accesso e controllo
La proprietà giuridica è un elemento del controllo. L'acquirente necessita anche di accesso fisico o logico, diritti sufficienti per modificare e distribuire, conoscenza per operare e autorità su credenziali e decisioni di rilascio. Questi elementi possono divergere. Un target può possedere codice sorgente personalizzato pur dipendendo da una libreria non trasferibile. Può possedere un repository mentre la build di produzione dipende da una toolchain privata di un consulente. Può detenere licenze ampie mentre un cliente governativo controlla l'approvazione della distribuzione.
Il modello di due diligence dovrebbe registrare separatamente proprietà, possesso, accesso, diritti di modifica, diritti di distribuzione, autorità operativa e diritti di risoluzione. Ogni voce necessita di evidenza documentale. Le evidenze pertinenti includono atti di cessione, termini di impiego, accordi con collaboratori, allegati di licenza, autorizzazioni sui repository, registri di distribuzione, contratti con i clienti e conferme dei fornitori.
Il controllo ha anche una dimensione temporale. L'accesso esistente durante la due diligence può scadere alla chiusura. L'acquirente dovrebbe identificare le azioni esatte necessarie per preservare l'accesso ai repository, la tenancy cloud, l'autorità di firma, le credenziali di amministratore, la cronologia di monitoraggio e il supporto dei fornitori attraverso il confine della transazione.
3 Costruire l'inventario del software e delle dipendenze
L'inventario dovrebbe identificare applicazioni, servizi, repository, rami, sistemi di build, pacchetti di distribuzione, database, interfacce, prodotti commerciali, componenti open source, librerie crittografiche e script operativi. Dovrebbe collegare ogni componente alla funzione di missione che supporta e all'ambiente in cui viene eseguito.
Un SBOM può accelerare l'individuazione dei componenti. Non sostituisce l'inventario operativo. Un inventario di acquisizione utile collega nome e versione del componente a fonte, licenza, manutentore, stato delle vulnerabilità, artefatto di build, configurazione distribuita, dipendenza dai dati e percorso di sostituzione. I componenti incorporati in container, firmware o appliance dei fornitori richiedono attenzione perché possono essere assenti da un elenco applicativo convenzionale.
L'acquirente dovrebbe riconciliare tre viste: ciò che l'ingegneria afferma esistere, ciò che i repository contengono e ciò che la telemetria di produzione mostra in esecuzione. Le differenze sono risultati della due diligence. Un servizio non registrato può essere critico. Un repository elencato può essere obsoleto. Un binario di produzione può non essere riconducibile a un commit sorgente approvato.
4 Verificare la completezza del codice sorgente
L'accesso al repository dovrebbe coprire l'intero prodotto e la sua storia. L'acquirente dovrebbe esaminare codice sorgente, configurazione, definizioni dell'infrastruttura, schemi di database, asset di test, script di build, automazione della distribuzione, documentazione e storico delle issue. Un'istantanea di file selezionati non può dimostrare la completezza.
Il test di completezza parte dagli artefatti distribuiti. Il team identifica binari o container di produzione rappresentativi e li riconduce alle revisioni del codice sorgente, alle versioni delle dipendenze, ai parametri di build e ai registri di approvazione. Poi esegue la build del software in un ambiente controllato e confronta il risultato con l'artefatto distribuito o con la sua provenienza documentata. Le differenze richiedono una spiegazione.
Il codice generato merita un trattamento separato. Le linee guida NASA riconoscono che la manutenzione a lungo termine può richiedere accesso a modelli, simulazioni, definizioni dei dati, generatori, dati di build, script di test e risultati attesi. Il possesso del codice sorgente generato può essere insufficiente quando mancano il generatore, il modello o una configurazione qualificata.
5 Riprodurre la build
Una build riproducibile è un test di due diligence di alto valore. L'obiettivo è dimostrare che un team autorizzato può creare una release distribuibile da input controllati senza interventi non documentati. Il test dovrebbe utilizzare un ambiente pulito e la procedura documentata del target. Gli osservatori dell'acquirente dovrebbero registrare prerequisiti, download esterni, credenziali, passaggi manuali, versioni degli strumenti, avvisi e deviazioni.
Il risultato non deve necessariamente essere identico bit per bit quando il processo esistente non supporta una compilazione deterministica. Dovrebbe essere tracciabile e funzionalmente equivalente nell'ambito di test concordati. L'acquirente dovrebbe comprendere perché sorge qualsiasi differenza e se il processo preserva l'integrità.
Un fallimento della build può rivelare licenze mancanti, certificati scaduti, repository di pacchetti non disponibili, patch non documentate o dipendenza da un ingegnere specifico. Queste risultanze si collegano direttamente al costo di transizione e al rischio di continuità. Il contratto di acquisto può richiedere una build pulita riuscita prima del closing o collocare il corrispettivo in escrow fino al soddisfacimento della condizione.
6 Tracciare l'autorità di rilascio e distribuzione
L'accesso al codice sorgente non stabilisce la capacità di gestire la produzione. L'acquirente dovrebbe tracciare l'autorità dall'approvazione del codice attraverso build, firma, rilascio, distribuzione e rollback. La traccia identifica chi può approvare modifiche, chi detiene le credenziali di firma, dove sono archiviati i pacchetti, come vengono promossi gli ambienti e come sono controllati i rilasci di emergenza.
Le modifiche al controllo dei satelliti possono avere conseguenze sulla sicurezza della missione. Le evidenze di rilascio dovrebbero includere risultati di verifica, revisione della prontezza operativa, approvazione della configurazione, consenso del cliente o dell'autorità ove applicabile e un percorso di ripristino testato. L'acquirente dovrebbe distinguere i rilasci applicativi di routine dalle modifiche alla convalida dei comandi, alla dinamica del volo, all'interpretazione della telemetria o alla fiducia crittografica.
Il trasferimento delle credenziali richiede un processo progettato. Le chiavi private e le credenziali privilegiate non dovrebbero essere copiate con leggerezza durante il closing. Le parti dovrebbero concordare rotazione, revoca, nuova registrazione, doppio controllo, conservazione degli audit e rollback. Il piano di closing dovrebbe indicare quando cambia l'autorità operativa e come si evita una responsabilità ambigua.
7 Esaminare i dati di configurazione della missione
Il software di controllo missione si basa su configurazioni che possono essere preziose quanto il codice sorgente. Dizionari dei comandi, definizioni di telemetria, limiti, dati di calibrazione, modelli di veicolo spaziale, piani di contatto, parametri orbitali, regole di automazione e instradamento dei clienti determinano come il software generico interagisce con una flotta reale.
L'acquirente dovrebbe identificare la fonte autorevole per ciascuna classe di configurazione, il relativo processo di approvazione, lo storico delle versioni e il metodo di ripristino. Dovrebbe verificare se un nuovo ambiente può essere popolato da registri controllati. Una configurazione basata su fogli di calcolo o memorizzata localmente crea rischio quando manca di revisione, tracciabilità e backup.
Anche i diritti di configurazione sono rilevanti. Un cliente, un produttore di veicoli spaziali o un integratore di sistemi può possedere o limitare parte dei dati. Il contratto di acquisizione dovrebbe disciplinare trasferimento, uso continuativo, riservatezza, restrizioni all'esportazione e obblighi di cancellazione. Una configurazione mancante può rendere inutilizzabile per una specifica missione un software altrimenti completo.
8 Valutare le evidenze di garanzia del software
Le evidenze di garanzia del software indicano se il prodotto è stato sviluppato e mantenuto attraverso pratiche controllate. L'SSDF del NIST organizza lo sviluppo sicuro attorno alla preparazione dell'organizzazione, alla protezione del software, alla produzione di software ben protetto e alla risposta alle vulnerabilità. Le linee guida NASA sulla garanzia del software aggiungono evidenze oggettive per contesti di sicurezza e missione.
L'acquirente dovrebbe esaminare la tracciabilità dei requisiti, le decisioni architetturali, la revisione del codice, l'analisi statica, la scansione delle dipendenze, la copertura dei test, l'approvazione del rilascio, la cronologia dei difetti e la risposta alle vulnerabilità. Le evidenze devono corrispondere alle versioni in produzione. Un documento di policy privo di registrazioni eseguite fornisce garanzie limitate.
Il team di due diligence dovrebbe campionare percorsi critici quali generazione dei comandi, autenticazione, gestione dei privilegi, determinazione dell'orbita e ripristino. Dovrebbe verificare se i test coprono condizioni avverse e al contorno. Le risultanze aperte dovrebbero essere classificate in base alle conseguenze sulla missione, alla sfruttabilità, alla recuperabilità e alla dipendenza dagli interventi correttivi.
9 Mappare la catena di fornitura del software
La catena di fornitura include fornitori commerciali, progetti open source, fornitori cloud, servizi di build, repository di pacchetti, fornitori hardware, consulenti e operatori specializzati. L'acquirente dovrebbe mappare quali soggetti possono modificare, interrompere, accedere o limitare il prodotto.
Per ciascun fornitore critico, la due diligence dovrebbe coprire supporto contrattuale, resilienza finanziaria, pratiche di sicurezza, privilegi di accesso, notifica degli incidenti, controllo delle modifiche, politica di fine vita, ubicazione dei dati e tempi di sostituzione. Un fornitore che supporta diversi componenti critici per la missione crea concentrazione anche quando la spesa annua è ridotta.
NIST SP 800-161 considera il rischio della catena di fornitura un problema di governance organizzativa anziché una checklist di approvvigionamento. Il team dell'operazione dovrebbe collegare le evidenze dei fornitori alla criticità del sistema e alla proprietà pianificata. I fornitori significativi possono richiedere consenso, novazione o accordo diretto prima del closing.
10 Analizzare l'esposizione all'open source
I componenti open source possono migliorare le capacità e ridurre i tempi di sviluppo. Creano anche obblighi di licenza, manutenzione e sicurezza. L'acquirente dovrebbe riconciliare i componenti dichiarati con la scansione del codice e i manifest di build. Dovrebbe identificare i termini di licenza, le modifiche, gli avvisi, le pratiche di distribuzione e le vulnerabilità note.
L'esposizione al copyleft richiede un'analisi legale basata sull'uso e sulla distribuzione effettivi. Una sola etichetta di licenza non stabilisce l'obbligo. Il team dovrebbe documentare come i componenti sono collegati, implementati, modificati e forniti ai clienti. Gli interventi correttivi possono comportare la correzione degli avvisi, l'offerta del codice sorgente, la sostituzione dei componenti o la comunicazione ai clienti.
Lo stato di manutenzione influisce sul valore. Una libreria critica priva di manutentore attivo o di release supportata può richiedere una gestione interna. L'acquirente dovrebbe valutare la strategia di fork, la copertura dei test, la capacità di applicare patch e la dipendenza dalla community. Una distinta base del software dovrebbe rimanere aggiornata dopo il closing anziché diventare un artefatto statico di due diligence.
11 Verificare la provenienza della proprietà intellettuale
Ogni contributo di codice significativo dovrebbe avere un percorso di provenienza difendibile. Le invenzioni dei dipendenti dovrebbero rientrare in adeguate condizioni di impiego. Il lavoro dei consulenti esterni dovrebbe essere ceduto con una portata sufficiente. Il codice acquisito o conferito dovrebbe essere accompagnato dai diritti necessari. Lo sviluppo finanziato da università, governo o clienti può includere restrizioni che richiedono una revisione dettagliata.
Il team dovrebbe effettuare un campionamento della cronologia dei commit rispetto ai registri e ai contratti dei contributori. Autori non riconosciuti, account personali o importazioni massive ingiustificate meritano un'analisi approfondita. La revisione dovrebbe includere documentazione, modelli, dati di test, interfacce utente e algoritmi, poiché la proprietà intellettuale di valore va oltre i file sorgente.
L'analisi di brevetti e segreti commerciali dovrebbe concentrarsi sul prodotto effettivo e sul piano commerciale. L'acquirente dovrebbe comprendere le registrazioni difensive, le attività di libertà di operare, i controlli di riservatezza e qualsiasi divulgazione che potrebbe indebolire la protezione del segreto commerciale. I documenti dell'operazione possono allocare rischi specifici di provenienza tramite garanzie, manleve, escrow o corrispettivi potenziali.
12 Verificare accessi privilegiati e segregazione
Gli ambienti di controllo missione concentrano privilegi elevati. Gli amministratori possono controllare comandi, identità, database, risorse cloud, chiavi di firma e monitoraggio. L'acquirente dovrebbe ottenere un inventario dei privilegi che copra account umani, di servizio e di emergenza in ambienti di sviluppo, test, produzione e ripristino.
La revisione dovrebbe verificare i controlli su assunzioni, trasferimenti e cessazioni; l'autenticazione a più fattori; l'approvazione; la registrazione delle sessioni; la rotazione delle credenziali; l'accesso di emergenza break-glass; e la segregazione tra sviluppo e produzione. Account condivisi o inattivi riducono la responsabilizzazione. Gli account di servizio richiedono titolarità e controlli del ciclo di vita.
Il closing crea un rischio di accesso più elevato. Il personale in uscita potrebbe conservare credenziali o conoscenza dei percorsi di ripristino. Il piano di transizione dovrebbe ruotare le credenziali sensibili, revocare i vecchi accessi, preservare le prove e mantenere una doppia copertura operativa. Queste azioni dovrebbero essere provate tramite esercitazioni laddove la perdita di accesso potrebbe influire su una missione in corso.
13 Esaminare la gestione delle vulnerabilità
L'acquirente dovrebbe comprendere come le vulnerabilità vengono individuate, classificate per priorità, corrette e comunicate. Le fonti includono analisi statica, scansione delle dipendenze, test di penetrazione, segnalazioni dei clienti, avvisi dei fornitori e monitoraggio operativo. Il programma dovrebbe definire gravità, conseguenze sulla missione, tempistiche di correzione, approvazione delle eccezioni e nuovi test.
L'analisi del backlog può rivelare requisiti di manutenzione nascosti. L'acquirente dovrebbe esaminare età, ricorrenza, versioni interessate e qualità della chiusura. Un numero basso può riflettere una capacità di rilevamento debole. Un numero elevato può riflettere un'attività di individuazione attiva. La misura utile è la capacità dell'organizzazione di identificare l'esposizione rilevante e ridurla entro tempistiche basate sul rischio.
I sistemi di volo e di terra possono avere finestre di applicazione delle patch limitate. Il target dovrebbe mostrare come applica controlli compensativi e pianifica rilasci sicuri. Vulnerabilità note in componenti inaccessibili o a fine vita possono giustificare una specifica riduzione del prezzo o una riserva di fondi per la correzione.
14 Valutare interfacce e interoperabilità
Il software di controllo satellitare dipende da interfacce con veicoli spaziali, stazioni di terra, reti, sistemi di identità, piattaforme dei clienti, dati meteo, dati orbitali e servizi regolatori. L'acquirente dovrebbe inventariare protocollo, versione, responsabile, requisito di prestazione, controllo di sicurezza, ambiente di test e processo di modifica per ciascuna interfaccia.
La documentazione delle interfacce dovrebbe essere verificata rispetto al traffico osservato e alle configurazioni attuali. Le interfacce proprietarie o non documentate creano lock-in. Un protocollo standard può comunque contenere estensioni specifiche del cliente che complicano la sostituzione.
Il team dovrebbe verificare le modalità di guasto. Dovrebbe osservare dati in ritardo, messaggi duplicati, errori di orologio, input corrotti, interruzioni di rete e perdita parziale del servizio. Il comportamento di ripristino influisce sul valore operativo. I piani di integrazione dovrebbero preservare l'osservabilità delle interfacce ed evitare di modificare più dipendenze critiche contemporaneamente.
15 Valutare diritti sui dati e registri
I dati operativi supportano il monitoraggio, l'analisi delle anomalie, il miglioramento dei modelli, la rendicontazione ai clienti e l'evidenza normativa. L'acquirente dovrebbe distinguere proprietà, custodia, uso consentito, conservazione e diritti di esportazione per telemetria, comandi, prodotti derivati, log, informazioni dei clienti e dati di addestramento.
Il perimetro dell'operazione dovrebbe includere i dati storici necessari per gestire e migliorare il sistema. Un acquirente potrebbe ricevere software senza una sufficiente cronologia operativa per calibrare gli alert o investigare le anomalie. La migrazione dei dati dovrebbe preservare timestamp, provenienza, controlli di accesso e integrità probatoria.
Obblighi in materia di privacy e localizzazione possono applicarsi ai dati del personale e dei clienti. I controlli sulle esportazioni e le restrizioni di sicurezza nazionale possono incidere sui dati tecnici e sull'accesso da parte di persone straniere. L'analisi legale dovrebbe mappare gli obblighi sui dataset e sulle sedi operative effettive.
16 Esaminare la resilienza operativa e il ripristino
I test di resilienza dovrebbero mostrare come il servizio continua a operare in caso di guasti a infrastrutture, software, fornitori e persone. L'acquirente dovrebbe esaminare ridondanza, backup, ambienti di ripristino, alternative di comunicazione, procedure manuali, obiettivi di ripristino e risultati delle esercitazioni.
Un backup è utile solo quando può essere ripristinato entro la tolleranza della missione. Il team di due diligence dovrebbe osservare un ripristino rappresentativo e validare configurazione, credenziali, dipendenze e integrità dei dati. Il ripristino dovrebbe includere la capacità di ricostruire i sistemi quando l'ambiente primario o il fornitore non è disponibile.
L'acquisizione stessa dovrebbe essere trattata come un evento di resilienza. I sistemi aziendali, i domini, gli account cloud e i contratti di supporto possono cambiare. Un piano dettagliato di cutover, criteri di rollback, autorità di comando e un processo congiunto di gestione degli incidenti riducono il rischio di transizione.
17 Valutare la concentrazione di persone e conoscenze
La continuità del software dipende da persone che comprendono architettura, missioni, anomalie, clienti e giudizio operativo. L'acquirente dovrebbe mappare i ruoli rispetto ai processi critici e individuare punti unici di conoscenza. Gli organigrammi forniscono prove limitate; la mappa dovrebbe riflettere chi risolve effettivamente gli incidenti e approva i rilasci.
Le decisioni di retention dovrebbero considerare sia l'importanza tecnica sia l'indipendenza. La conoscenza concentrata può essere ridotta tramite affiancamento, documentazione, simulazioni e successione. Pagamenti di retention senza milestone di trasferimento delle conoscenze possono mantenere la dipendenza anziché ridurla.
Il modello dell'operazione dovrebbe includere costi di assunzione, retention, conversione dei collaboratori esterni e formazione. Il rischio di persone chiave può incidere sulla valutazione quando le competenze non possono essere trasferite entro il periodo di transizione. La direzione dovrebbe riportare i progressi rispetto a evidenze specifiche di trasferimento delle conoscenze.
18 Verificare l'accettazione da parte dei clienti e delle autorità di regolamentazione
I contratti con i clienti possono definire obblighi in materia di prestazioni del software, sicurezza, audit, approvazione e modifiche. L'acquirente dovrebbe individuare i contratti che richiedono consenso, notifica, ricertificazione o personale nominato. Dovrebbe distinguere i ricavi che si trasferiscono automaticamente dai ricavi dipendenti dall'accettazione del cliente.
I clienti governativi e delle infrastrutture critiche possono imporre restrizioni su dati tecnici, nulla osta di sicurezza, hosting o catena di approvvigionamento. L'acquirente dovrebbe valutare se la propria proprietà, il finanziamento, il personale e il modello operativo restano idonei. Le licenze regolamentari e i diritti di spettro possono trovarsi al di fuori dell'entità software pur restando essenziali per l'erogazione del servizio.
Il modello commerciale dovrebbe ponderare per probabilità i rinnovi e i consensi incerti. Il corrispettivo può essere subordinato a un trasferimento verificato o a ricavi mantenuti. L'acquirente dovrebbe evitare di pagare il valore pieno per contratti i cui prerequisiti operativi non si trasferiscono.
19 Collegare la due diligence alla valutazione
La due diligence sul software modifica il valore attraverso flussi di cassa, tempistica, rischio e vita dell'opzione. La remediation aumenta i costi. La mancanza di diritti può ridurre i ricavi raggiungibili. La fragilità operativa può aumentare la probabilità di interruzione del servizio. Un controllo debole delle build può ritardare lo sviluppo del prodotto. Evidenze solide possono giustificare riserve di integrazione più basse e una maggiore fiducia nel rinnovo.
Il ponte di valutazione dovrebbe evitare la duplicazione degli aggiustamenti. Un costo di supporto ricorrente appartiene ai flussi di cassa previsionali. Una ricostruzione una tantum appartiene agli impieghi di transazione o integrazione. Un difetto binario nei diritti può richiedere esclusione, escrow o una condizione anziché un premio al tasso di sconto.
L'acquirente dovrebbe presentare scenari base, avversi e severi. Ciascuno scenario dovrebbe individuare ipotesi operative, evidenze e azioni del management. Il valore terminale dovrebbe riflettere la manutenzione continua, l'obsolescenza dei componenti, la concentrazione dei fornitori e la capacità di aggiornare il prodotto.
20 Tradurre le risultanze nella meccanica della transazione
Le risultanze materiali dovrebbero avere un responsabile e una risposta di transazione. Le risposte possibili includono riduzione del prezzo, trattenuta, escrow, earn-out, manleva, condizione di chiusura, covenant, servizio di transizione, novazione della licenza, accordo sulle persone chiave o asset escluso.
Le condizioni dovrebbero essere verificabili oggettivamente. Un requisito di fornire il codice sorgente completo è debole senza repository, branch, artefatti e test di accettazione definiti. Una condizione di build può specificare ambiente, input, suite di test con esito positivo e pacchetto di distribuzione. Una condizione di accesso può specificare identità, privilegi, chiavi e login verificato.
Il processo di disclosure dovrebbe preservare evidenze versionate. L'acquirente dovrebbe registrare quali artefatti supportano ciascuna dichiarazione e chi ha accettato le eccezioni. I prospetti tecnici devono essere esaminati da ingegneria e consulenza legale affinché il linguaggio legale corrisponda alla realtà operativa.
21 Progettare la control room di chiusura
La chiusura dovrebbe essere gestita come un cambiamento operativo. La control room coordina il completamento legale, il trasferimento delle credenziali, la novazione dei fornitori, la tenancy cloud, i repository di codice, i poteri di firma, le comunicazioni ai clienti, il monitoraggio e la copertura degli incidenti.
Il piano dovrebbe utilizzare criteri espliciti di go, hold e rollback. Ogni fase individua evidenze, tempistica, persona responsabile e fallback. L'accesso critico dovrebbe essere testato prima che si verifichino azioni irreversibili. Le parti dovrebbero mantenere una copertura congiunta durante la finestra di rischio più elevato.
L'acquirente dovrebbe conservare log e snapshot di configurazione. Queste registrazioni stabiliscono lo stato al momento del trasferimento e supportano le indagini successive. La prima release post-chiusura dovrebbe seguire il processo di assurance concordato anziché diventare un test di integrazione improvvisato.
22 Stabilire i primi 100 giorni
I primi 100 giorni dovrebbero stabilizzare il controllo, colmare le lacune di evidenza prioritarie e ridurre la concentrazione. Le azioni iniziali includono la ricertificazione degli accessi, la rotazione delle credenziali, build pulite, conferma delle dipendenze, remediation del backlog critico, test di ripristino, retention del personale e governance dei fornitori.
Le modifiche architetturali dovrebbero seguire le evidenze. Una migrazione immediata della piattaforma può combinare il passaggio di proprietà con il cambiamento tecnico e creare rischio evitabile. Il team di integrazione dovrebbe sequenziare le modifiche in base alle finestre mission-critical, agli impegni verso i clienti e alla capacità di ripristino.
Il consiglio di amministrazione dovrebbe ricevere una dashboard sintetica che copra riproducibilità delle build, vulnerabilità critiche, accessi alle chiavi, novazioni con i fornitori, consensi dei clienti, test di ripristino, trasferimento di conoscenze e spesa. La dichiarazione di completamento dovrebbe richiedere prove oggettive.
23 Governare il valore continuativo del software
La governance post-chiusura dovrebbe collegare la salute del software ai risultati commerciali e finanziari. Le metriche ingegneristiche includono affidabilità dei deployment, difetti sfuggiti, età delle vulnerabilità, integrità delle build, prestazioni di ripristino e stato delle dipendenze. Le metriche commerciali includono disponibilità del servizio, rinnovo, latenza di consegna e costo del supporto.
La roadmap di prodotto dovrebbe distinguere manutenzione obbligatoria, impegni verso i clienti, remediation di sicurezza e investimenti per la crescita. La manutenzione differita può gonfiare gli utili di breve periodo indebolendo la generazione di cassa futura. I comitati investimenti dovrebbero comprendere tale distinzione.
L'acquirente dovrebbe mantenere un registro delle prove per diritti critici, configurazioni e fornitori. Cambiamenti nella proprietà, nelle licenze, nel supporto o nell'architettura possono alterare la tesi di acquisizione. L'assurance annuale e periodiche revisioni di preparazione all'operazione preservano l'opzionalità per rifinanziamento o uscita.
24 Caso di transazione ipotetico
Il target ipotetico supporta 18 satelliti per missioni di comunicazioni, osservazione della Terra e payload ospitati. La sua piattaforma comprende pianificazione delle missioni, validazione dei comandi, elaborazione della telemetria, dinamica del volo, automazione e consegna al cliente. I ricavi sono generati tramite contratti annuali di software e operazioni.
La due diligence conferma una forte fidelizzazione dei clienti e competenze ingegneristiche solide. Identifica inoltre cinque esposizioni legate all'operazione. Le build di produzione richiedono uno strumento commerciale non documentato. Due librerie sono licenziate alla controllante del venditore e non possono essere trasferite automaticamente. Un amministratore controlla processi chiave di produzione e firma. La remediation delle vulnerabilità critiche è stata rinviata in corrispondenza delle finestre di missione. Un adattatore specifico per il cliente contiene contributi con prove incomplete di cessione dei diritti.
L'acquirente incorpora questi rilievi nel prezzo tramite una deduzione aggregata USD 25 million dal valore complessivo dichiarato USD 84 million. Un ulteriore earn-out USD 6 million è disponibile al raggiungimento di gate probatori definiti. La struttura preserva la partecipazione del venditore alla remediation proteggendo la cassa dell'acquirente al closing.
25 Principi decisionali
In primo luogo, definire la capacità di missione acquisita e il suo perimetro operativo. In secondo luogo, tracciare ogni artefatto critico distribuito fino a fonti controllate e prove di build e approvazione. In terzo luogo, separare proprietà, accesso, diritti e autorità operativa. In quarto luogo, mappare la concentrazione di fornitori e personale rispetto alla continuità. In quinto luogo, testare il ripristino e il cutover transazionale. In sesto luogo, tradurre ogni dipendenza irrisolta in cassa, condizioni o protezione contrattuale.
Questi principi creano un linguaggio comune per i team di ingegneria, finanza, operazioni e legale. Migliorano inoltre la velocità della transazione perché le richieste di prove e i test di accettazione diventano specifici.
L'obiettivo dell'acquirente è un controllo dimostrabile sugli esiti della missione. Tale controllo sostiene la continuità, la fiducia dei clienti, l'integrazione e una valutazione difendibile.
26 Revisione dell'architettura e del debito tecnico
La due diligence sull'architettura dovrebbe spiegare come il sistema separa pianificazione delle missioni, dinamica del volo, validazione dei comandi, telemetria, automazione, identità, archivi dati e interfacce esterne. L'acquirente dovrebbe identificare confini di fiducia, domini di guasto, servizi condivisi e componenti le cui modifiche potrebbero influire su più missioni. I diagrammi architetturali dovrebbero essere riconciliati con la topologia distribuita, i flussi di rete e la titolarità dei repository.
Il debito tecnico dovrebbe essere espresso attraverso le conseguenze. Un vecchio linguaggio di programmazione può restare gestibile quando sono disponibili competenze, test e toolchain. Un servizio moderno può essere fragile quando manca di una chiara attribuzione di responsabilità, osservabilità o capacità di ripristino. Il team di due diligence dovrebbe stimare il costo, l'ordine di esecuzione e il rischio operativo di ciascuna voce di debito rilevante.
La classificazione del debito dovrebbe distinguere manutenibilità, sicurezza, prestazioni, scalabilità, obsolescenza e conformità. Il modello commerciale dovrebbe riflettere le categorie che limitano la crescita o la fidelizzazione dei clienti. I piani di correzione dovrebbero identificare dipendenze e finestre operative della missione anziché presentare un backlog indifferenziato.
27 Valutare l'osservabilità e le evidenze degli incidenti
Il valore del controllo missione dipende dalla capacità di rilevare e spiegare comportamenti anomali. L'acquirente dovrebbe esaminare log, metriche, tracce, avvisi, dashboard, conservazione, sincronizzazione dell'orologio e registri degli incidenti. Dovrebbe identificare dove vengono generati i dati, chi può accedervi e se i registri sopravvivono a un guasto del sistema o del fornitore.
La qualità degli avvisi merita campionamento. Volumi elevati di avvisi non azionabili possono nascondere eventi rilevanti. Avvisi radi possono riflettere una copertura limitata. Il team dovrebbe confrontare incidenti selezionati con telemetria registrata, azioni di risposta, analisi delle cause profonde e attività correttive. Incidenti ripetuti senza correzione duratura indicano debolezza dei controlli.
La pianificazione della transazione dovrebbe preservare la continuità del monitoraggio. La migrazione degli account, la separazione cloud o la sostituzione degli strumenti possono creare periodi ciechi. Il piano di closing dovrebbe definire quali avvisi restano attivi, chi li riceve e come il team congiunto gestisce un evento durante la transizione. Evidenze di monitoraggio stabile possono supportare un periodo più breve di servizi di transizione.
28 Testare la scalabilità e l'espansione della flotta
Le prestazioni storiche non dimostrano che la piattaforma possa supportare la flotta pianificata dall'acquirente. Il team dovrebbe identificare i fattori di scala come satelliti, contatti, volume di telemetria, carico di comandi, interfacce clienti, operatori simultanei e stazioni di terra. Dovrebbe esaminare l'utilizzo di picco osservato e i margini di capacità.
I test di carico dovrebbero utilizzare modelli di messaggi rappresentativi e condizioni di guasto. Le operazioni spaziali possono creare brevi periodi di attività intensa intorno a lancio, messa in servizio, anomalie e finestre di contatto. L'utilizzo medio può nascondere accodamento, contesa del database o sovraccarico degli operatori durante questi periodi.
Il caso di crescita dovrebbe includere costi di infrastruttura, licenze, supporto e personale. Una piattaforma che scala tecnicamente può affrontare limiti commerciali dovuti a prezzi del fornitore per satellite o a specialisti scarsi. Il modello di valutazione dovrebbe allineare i ricavi di crescita al capitale e ai costi operativi necessari per generarli.
29 Valutare con attenzione le funzionalità di intelligenza artificiale
Le società target possono utilizzare l'apprendimento automatico per rilevamento di anomalie, pianificazione, elaborazione delle immagini, manutenzione predittiva o assistenza agli operatori. La due diligence dovrebbe identificare la decisione esatta supportata, il proprietario del modello, i diritti sui dati di addestramento, la validazione, il monitoraggio, la supervisione umana e la risposta ai guasti. Le descrizioni di marketing forniscono prove limitate del valore operativo.
L'acquirente dovrebbe confrontare le prestazioni dichiarate con una baseline definita e dati di missione rappresentativi. Dovrebbe esaminare falsi positivi, falsi negativi, deriva, riaddestramento, controllo delle versioni e casi limite. Un modello che migliora il rilevamento medio può comunque essere inadatto alle decisioni di comando quando le sue modalità di guasto sono opache.
Gli strumenti generativi utilizzati in ingegneria o nelle operazioni necessitano di governance su dati sensibili, provenienza del codice e revisione degli output. La roadmap di prodotto dovrebbe separare il valore dimostrato per il cliente dalla capacità sperimentale. La valutazione dovrebbe riconoscere i ricavi correlati a AI solo quando diritti, prestazioni, implementazione e conversione in cassa sono documentati.
30 Esaminare i vincoli di controllo delle esportazioni e di accesso sovrano
Il software satellitare, i dati tecnici e i servizi possono essere soggetti a controlli sulle esportazioni, sanzioni, classificazioni di sicurezza e requisiti di accesso sovrano. L'acquirente dovrebbe mappare articoli controllati, licenze, nazionalità, ubicazioni, regioni cloud e restrizioni sui clienti. Consulenti legali specializzati dovrebbero interpretare il regime giuridico applicabile.
L'accesso operativo può essere limitato anche quando la proprietà viene trasferita. Alcuni clienti possono richiedere personale con nulla osta di sicurezza, hosting nazionale o supporto segregato. La struttura proprietaria e finanziaria dell'acquirente può attivare una revisione o richiedere un consenso. Questi fattori incidono sul design dell'integrazione e sulla capacità di centralizzare le operazioni.
Il modello di transazione dovrebbe includere personale di conformità, ambienti segregati, tempistiche delle licenze e possibili restrizioni sui ricavi. Le condizioni di closing dovrebbero affrontare le approvazioni necessarie per la continuità. Il management dovrebbe evitare rassicurazioni generiche e identificare l'ambito preciso coperto da ciascuna autorizzazione.
31 Creare un dossier di evidenze per il comitato investimenti
Il comitato investimenti necessita di un collegamento sintetico tra risultanze tecniche e decisioni economiche. Il dossier dovrebbe iniziare dalla capacità acquisita, dalla dipendenza dai ricavi e dai punti di controllo critici. Dovrebbe presentare evidenze sul codice sorgente e sulla build, posizione sui diritti, mappa dei fornitori, resilienza operativa, consensi dei clienti e concentrazione del personale.
Ogni riscontro rilevante dovrebbe indicare stato delle evidenze, conseguenza di cassa, meccanismo proposto, responsabile incaricato e rischio residuo. Il comitato dovrebbe poter distinguere una lacuna verificata da una stima del management e da una promessa futura di rimedio. L'analisi di scenario dovrebbe mostrare l'effetto di ritardi e guasti combinati.
L'approvazione dovrebbe indicare condizioni, poteri delegati e rendicontazione successiva al closing. Il dossier di evidenze diventa quindi la base di riferimento per la governance dell'integrazione. Questa continuità riduce il rischio che i risultati della due diligence scompaiano dopo il closing e favorisce la successiva responsabilizzazione per la creazione di valore.
32 Pianificare la separazione dal venditore
Uno scorporo richiede un modello di separazione che copra applicazioni, infrastruttura, identità, reti, contratti, dati e persone. L'acquirente dovrebbe identificare i servizi che restano in capo al venditore, i servizi che vengono trasferiti e i servizi che devono essere ricostruiti. Ogni voce dovrebbe avere una modalità operativa transitoria, uno stato obiettivo, un costo, una dipendenza e un criterio di uscita.
Gli accordi di servizi transitori dovrebbero descrivere servizi misurabili e responsabilità operative. Dovrebbero identificare livelli di servizio, obblighi di sicurezza, coordinamento degli incidenti, accesso, controllo delle modifiche, restituzione dei dati, diritti di audit, prezzi e cessazione. Un impegno generico a fornire assistenza ragionevole può lasciare irrisolte esigenze critiche della missione.
Il calendario di separazione dovrebbe rispettare i vincoli della missione. Le modifiche a identità o rete possono incidere sui percorsi di monitoraggio e comando. La migrazione dei dati può incidere sulla cronologia e sulle evidenze di audit. La novazione dei fornitori può modificare i diritti di supporto. Le parti dovrebbero introdurre per fasi le modifiche ad alto rischio e mantenere il rollback fino al soddisfacimento dei criteri di accettazione.
La preparazione all'uscita dovrebbe essere testata prima della fine di un servizio transitorio. L'acquirente dovrebbe dimostrare accesso, build, distribuzione, monitoraggio, supporto e ripristino indipendenti. Dovrebbe inoltre confermare che gli account e i dati del venditore possano essere rimossi senza interrompere il servizio. Qualsiasi proroga dovrebbe avere una ragione, un prezzo e un responsabile del rimedio definiti.
I costi di separazione vanno inclusi nel modello di transazione. Comprendono infrastrutture duplicate, licenze temporanee, ingegneria della migrazione, test di sicurezza, validazione da parte dei clienti e sovrapposizione operativa. La stima dovrebbe distinguere le quotazioni impegnative dalle ipotesi del management. Un piano di separazione finanziato e governato protegge la continuità e impedisce che la transazione comporti una dipendenza indefinita dal venditore.
Il consiglio di amministrazione dovrebbe ricevere un dashboard settimanale sulla separazione finché tutti i servizi critici per la missione non operano in modo indipendente. Il dashboard dovrebbe identificare dipendenze in ritardo, uscite testate, obblighi verso i clienti irrisolti, costi previsti e la prossima azione irreversibile. La chiusura dovrebbe richiedere evidenze da ingegneria, operazioni, sicurezza, finanza e dal responsabile del servizio competente.
Appendice A Registro delle evidenze di due diligence
Il registro delle evidenze dovrebbe identificare la domanda, l'artefatto richiesto, il titolare della fonte, la versione, l'esito della revisione, l'eccezione, la conseguenza finanziaria e la risposta dell'operazione. Dovrebbe rimanere collegato alla data room virtuale affinché le conclusioni possano essere riprodotte.
Le evidenze ad alta priorità includono l'inventario di produzione, la mappa del repository, l'esito della build pulita, la traccia di deployment, l'inventario dei privilegi, il prospetto delle licenze, SBOM, il backlog delle vulnerabilità, il test di ripristino, la mappa dei consensi dei clienti e il piano per le persone chiave. Ogni voce dovrebbe identificare gli esatti sistemi e configurazioni coperti.
Il campionamento dovrebbe essere basato sul rischio. Il team dovrebbe scegliere missioni rappresentative ad elevate conseguenze, interfacce critiche, rilasci recenti, modifiche di emergenza e componenti più datati. I campioni dovrebbero testare sia la progettazione dei controlli sia l'esecuzione effettiva.
Appendice B Metodo di valutazione
Il metodo illustrativo parte dal valore d'impresa derivato dal modello commerciale dell'acquirente. Rettifica poi il flusso di cassa previsionale per i costi ricorrenti di manutenzione e dei fornitori. I costi una tantum di rimedio, separazione e transizione sono inclusi negli impieghi. I ricavi soggetti al consenso dei clienti sono ponderati per probabilità. I difetti nei diritti e le condizioni operative sono affrontati tramite deduzioni, escrow o corrispettivi condizionali.
L'analisi di scenario dovrebbe combinare rischi correlati. Un ritardo di un fornitore può ritardare anche il rimedio e l'accettazione da parte del cliente. L'uscita di una persona chiave può indebolire sia la continuità sia il trasferimento di conoscenze. Gli scenari negativi correlati meritano un trattamento esplicito.
Nessun numero ipotetico in questo documento rappresenta un'operazione identificata. Il caso dimostra come le evidenze possano essere collegate alla valutazione e alla struttura dell'operazione.
Appendice C Test di accettazione al closing
I test di accettazione dovrebbero coprire l'accesso al repository, la build pulita, l'esecuzione dei test, la firma dei pacchetti, il deployment in ambiente non di produzione, il ripristino della configurazione, il monitoraggio, l'accesso privilegiato, il supporto dei fornitori e il recupero. Le parti dovrebbero concordare dati di test, ambiente, criteri di superamento ed evidenze prima della firma.
I test dovrebbero evitare interruzioni delle operazioni in esercizio. Le modifiche alla produzione richiedono approvazione della missione e controlli separati. Un test in ambiente non di produzione può comunque validare la catena dalla fonte controllata all'artefatto distribuibile.
I test falliti dovrebbero avere conseguenze predefinite. Queste possono includere rimedio, escrow, closing differito, corrispettivo ridotto o esclusione di un asset. La risposta dovrebbe corrispondere alla rilevanza operativa e finanziaria del fallimento.
Appendice D Figure e tabelle decisionali
Progressione illustrativa delle evidenze; i valori sono ipotetici e non rappresentano una società identificata.
Punteggi più elevati indicano una maggiore dipendenza nel caso ipotetico.
Sequenza proposta; la tempistica effettiva dipende dai fatti della transazione e dai vincoli della missione.
Valori del tutto ipotetici; USD milioni.
Sequenza proposta soggetta a finestre della missione e obblighi verso i clienti.
| Evidenza | Questione della transazione | Indicatore di accettazione | Risposta alla lacuna |
|---|---|---|---|
| Inventario dei repository | Tutto il materiale è sotto controllo del codice sorgente? | I componenti di produzione sono riconducibili a repository denominati | Condizione di completamento o esclusione dall'ambito |
| Definizione della build | Un ambiente pulito può generare una release? | Build controllata riuscita con input documentati | Piano di trattenuta e rimedio |
| Provenienza | È possibile tracciare gli artefatti distribuiti? | Versione, dipendenze, approvazione e firma collegate | Riserva per rischi e rimedio dei controlli |
| Artefatti generati | Sono disponibili modelli e generatori? | Ricostruzione possibile da fonti controllate | Condizione di trasferimento di licenza o asset |
Requisiti di evidenza dell'operazione proposta.
| Dipendenza | Evidenza | Esposizione principale | Trattamento dell'operazione |
|---|---|---|---|
| Codice dipendente | Termini del rapporto di lavoro e delle invenzioni | Lacuna di titolarità | Cessione e garanzia |
| Opere di appaltatori | Capitolato e cessione | Limitazioni alla modifica o al trasferimento | Cessione specifica o manleva |
| Software commerciale | Termini di licenza e supporto | Non trasferibilità, risoluzione o rideterminazione del prezzo | Novazione, sostituzione o detrazione |
| Software open source | SBOM, licenza e registro di distribuzione | Conformità e manutenzione | Piano di rimedio e governance continua |
| Interfaccia con il cliente | Storico dei contratti e dei contributi | Uso limitato al cliente esistente | Valore soggetto a consenso o condizionato |
Classificazione proposta delle dipendenze legali e operative.
| Voce | USD milioni | Base delle evidenze | Trattamento |
|---|---|---|---|
| Valore d'impresa dichiarato | 84 | Modello commerciale | Valore iniziale |
| Rimedio e transizione | -9 | Piano di sviluppo, vulnerabilità e separazione | Deduzione al closing |
| Diritti e dipendenze | -7 | Lacune su licenze e provenienza | Detrazione o escrow |
| Concentrazione e fragilità | -5 | Revisione degli accessi e delle persone chiave | Riserva di integrazione |
| Accettazione del cliente | -4 | Evidenza di consenso e interfaccia | Corrispettivo potenziale |
| Valore in contanti al closing | 59 | Quadro aggregato | Risultato illustrativo |
Del tutto ipotetico; USD milioni.
| Controllo | Evidenza prima del trasferimento | Azione di closing | Verifica post-closing |
|---|---|---|---|
| Repository | Elenco degli accessi e dei rami protetti | Trasferire gli amministratori | Riconciliare accessi e log |
| Firma | Inventario delle chiavi e catena di approvazione | Ruotare o registrare nuovamente le chiavi | Testare una release firmata non di produzione |
| Accesso alla produzione | Inventario dei privilegi | Revocare gli account riservati al venditore | Ricertificare gli accessi utente e di servizio |
| Fornitori | Prospetto dei contratti e dei consensi | Eseguire le novazioni | Confermare i contatti per supporto e incidenti |
| Ripristino | Ultima esercitazione e inventario dei backup | Conservare gli snapshot | Eseguire un ripristino controllato |
Controlli proposti; la sequenza effettiva dipende dai vincoli della missione.
| Misura | Evidenze del giorno 30 | Evidenze del giorno 60 | Evidenze del giorno 100 |
|---|---|---|---|
| Controllo della build | Ambiente pulito predisposto | Prodotti critici riprodotti | Evidenze del rilascio di routine complete |
| Accesso | Amministratori ricertificati | Account di servizio assegnati | Eccezioni chiuse o accettate |
| Vulnerabilità | Backlog critico validato | Rimedi prioritari testati | Livelli di servizio sostenibili in esercizio |
| Fornitori | Dipendenze critiche confermate | Novazioni e sostituzioni portate avanti | Piani di governance e di uscita approvati |
| Conoscenza | Ruoli chiave mantenuti | Runbook e affiancamento in corso | Copertura operativa indipendente testata |
Milestone di evidenza proposte.
| Rilievo | Effetto di cassa | Meccanismo contrattuale | Prova per lo svincolo |
|---|---|---|---|
| Dipendenza non trasferibile | USD 7 million | Escrow o riduzione del prezzo | Novazione perfezionata o sostituzione qualificata |
| Fragilità del build | USD 4 million | Condizione di chiusura | Build pulita e test superati con successo |
| Dipendenza da persone chiave | USD 3 million | Trattenuta legata alla retention | Milestone di trasferimento delle conoscenze |
| Diritti specifici dei clienti | USD 4 million | Earn-out | Consenso e incasso della liquidità trattenuta |
Effetti di cassa del tutto ipotetici; USD milioni.
| Area decisionale | Evidenza verde | Condizione ambra | Condizione rossa |
|---|---|---|---|
| Controllo del codice sorgente | Repository completi e tracciabili | Lacune minori controllate | Assenza di codice sorgente o cronologia critici |
| Realizzazione | Rilascio ripetibile e controllato | Passaggi manuali con correzione finanziata | Build non riproducibile |
| Diritti | Diritti documentati trasferibili | Consenso in sospeso con protezione | Diritto materiale non disponibile |
| Operazioni | Copertura indipendente con personale dedicato | Concentrazione con transizione testata | Dipendenza da persona specifica senza fallback |
| Ripristino | Ripristino recente riuscito | Ambito parziale o esercizio datato | Ripristino non testato o non disponibile |
Soglie decisionali proposte.
Fonti
- National Institute of Standards and Technology, SP 800-218 Framework per lo sviluppo sicuro del software Versione 1.1, 2022. Leggi la fonte primaria
- National Institute of Standards and Technology, SP 800-161 Revisione 1 Pratiche di gestione del rischio della catena di approvvigionamento informatica per sistemi e organizzazioni, 2022. Leggi la fonte primaria
- National Institute of Standards and Technology, Guida alla sicurezza del software nelle catene di approvvigionamento, aggiornata al 2024. Leggi la fonte primaria
- National Institute of Standards and Technology, Framework di cybersecurity 2.0, 2024. Leggi la fonte primaria
- National Institute of Standards and Technology, NISTIR 8401 Segmento di terra satellitare: applicazione del framework di cybersecurity al comando e controllo satellitare, 2022. Leggi la fonte primaria
- National Institute of Standards and Technology, SP 800-53 Revisione 5 Controlli di sicurezza e privacy per sistemi e organizzazioni informatici. Leggi la fonte primaria
- National Aeronautics and Space Administration, Manuale di ingegneria e assicurazione del software NASA NASA-HDBK-2203. Leggi la fonte primaria
- National Aeronautics and Space Administration, SWE-042 Accesso elettronico al codice sorgente. Leggi la fonte primaria
- National Aeronautics and Space Administration, SWE-158 Valutare il software per le vulnerabilità di sicurezza. Leggi la fonte primaria
- National Aeronautics and Space Administration, SWE-206 Generazione automatica degli input software. Leggi la fonte primaria
- National Aeronautics and Space Administration, NPR 7150.2 Requisiti di ingegneria del software NASA. Leggi la fonte primaria
- National Aeronautics and Space Administration, NASA-STD-8739.8 Standard di assicurazione e sicurezza del software. Leggi la fonte primaria
- National Aeronautics and Space Administration, NASA-STD-1006A Standard di protezione dei sistemi spaziali. Leggi la fonte primaria
- Amministrazione nazionale per l'aeronautica e lo spazio, Guida alle migliori pratiche per la sicurezza spaziale. Leggi la fonte primaria
- Agenzia per la cybersicurezza e la sicurezza delle infrastrutture, Proteggere la catena di fornitura del software: pratiche raccomandate per gli sviluppatori, 2023. Leggi la fonte primaria
- Agenzia per la cybersicurezza e la sicurezza delle infrastrutture, Elenco dei componenti software. Leggi la fonte primaria
- Agenzia per la cybersicurezza e la sicurezza delle infrastrutture, Sicuro fin dalla progettazione. Leggi la fonte primaria
- Agenzia per la cybersicurezza e la sicurezza delle infrastrutture, Manuali operativi per la risposta agli incidenti di sicurezza informatica e alle vulnerabilità del governo federale. Leggi la fonte primaria
- Agenzia spaziale europea, Prodotti software per le operazioni di missione. Leggi la fonte primaria
- Agenzia spaziale europea, SPACE-SHIELD: capacità malevole nella catena di fornitura e vulnerabilità del software. Leggi la fonte primaria
- Agenzia dell'Unione europea per la cybersicurezza, Panorama delle minacce spaziali ENISA 2025. Leggi la fonte primaria
- Comitato consultivo per i sistemi di dati spaziali, Operazioni di missione e servizi di gestione delle informazioni. Leggi la fonte primaria
- Comitato consultivo per i sistemi di dati spaziali, Pubblicazioni del gruppo di lavoro sulla sicurezza. Leggi la fonte primaria
- Ufficio per il commercio spaziale degli Stati Uniti, Direttiva sulla politica spaziale 5: principi di cybersicurezza per i sistemi spaziali. Leggi la fonte primaria
- National Cyber Security Centre del Regno Unito, Kit di strumenti di cybersicurezza per i consigli di amministrazione. Leggi la fonte primaria
- Open Worldwide Application Security Project, Standard per la verifica dei componenti software. Leggi la fonte primaria
- Open Worldwide Application Security Project, Modello di maturità per la garanzia del software. Leggi la fonte primaria
- The Linux Foundation, SPDX: scambio di dati sui pacchetti software. Leggi la fonte primaria
- Organizzazione internazionale per la normazione, sistemi di gestione della sicurezza delle informazioni ISO IEC 27001. Leggi la fonte primaria
- Cooperazione europea per la standardizzazione spaziale, standard di ingegneria del software ECSS. Leggi la fonte primaria
