Introduction
Le logiciel se situe entre le satellite, le réseau au sol, les opérateurs, les clients et les régulateurs. Les systèmes de contrôle de mission planifient les contacts, valident et transmettent les commandes, reçoivent et traitent la télémétrie, surveillent l'état des engins spatiaux, calculent les orbites, gèrent les calendriers de charge utile et préservent le dossier opérationnel. Un défaut, une dépendance indisponible ou une clé de signature inaccessible peut interrompre les revenus et affaiblir l'autorité de commandement même lorsque le vaisseau spatial sous-jacent reste techniquement sain.
Une acquisition implique donc plus qu’une simple revue de produit logiciel. L'acheteur doit comprendre le système de mission tel qu'il est exploité. Ce système comprend des référentiels sources, des pipelines de construction, des données de configuration, des environnements de déploiement, du matériel cryptographique, des interfaces au sol, des runbooks, des services fournisseurs, un jugement technique et des droits contractuels. Plusieurs de ces éléments peuvent se situer en dehors de l'entité juridique de la cible ou dépendre de personnes nommées.
Cet article présente un cadre de transaction pour ce problème. Il est conçu pour les acquéreurs stratégiques, les investisseurs en infrastructures, les sociétés de capitaux privés, les opérateurs de satellites, les prêteurs et les conseils d'administration évaluant une transaction spatiale pilotée par logiciel. Il se concentre sur les preuves qui modifient le contrôle, la continuité, le prix, les conditions et la conception de l'intégration.
1 Définir la capacité acquise
L'acheteur doit commencer par une déclaration de capacité. La déclaration identifie les missions, les engins spatiaux, les charges utiles, les sites au sol, les services clients et les décisions opérationnelles pris en charge par le logiciel. Il enregistre les fenêtres de service, les attentes de disponibilité, les conséquences en matière de sécurité, les obligations réglementaires et les dépendances en matière de revenus. Les noms de produits à eux seuls fournissent un périmètre peu fiable, car une plate-forme de marque peut dépendre de services distincts en matière de dynamique de vol, de planification, d'identité, de base de données, de surveillance et de station au sol.
La déclaration de capacité doit distinguer les logiciels de vol des logiciels au sol. Les acquisitions de contrôle par satellite se concentrent généralement sur le segment sol, tandis que la valeur opérationnelle peut dépendre des interfaces de vol intégrées et des bases de données de commandes spécifiques aux engins spatiaux. L'acheteur a besoin de la preuve que la cible peut utiliser, modifier et transférer toutes les interfaces nécessaires à la poursuite des opérations.
Le périmètre doit également identifier les services exclus. L'identité d'entreprise partagée, les abonnements cloud, les liens de communication, les services de gestion des clés, les centres de données ou le personnel de la société mère peuvent être essentiels dès le premier jour. Chaque exclusion devient une exigence de transition, une dépendance continue ou une correction de valeur.
2 Propriété, accès et contrôle séparés
La propriété légale est un élément de contrôle. L'acheteur a également besoin d'un accès physique ou logique, de droits suffisants pour modifier et déployer, de connaissances pour fonctionner et d'une autorité sur les informations d'identification et les décisions de publication. Ces éléments peuvent diverger. Une cible peut posséder un code source personnalisé tout en s'appuyant sur une bibliothèque non transférable. Il peut posséder un référentiel alors que la version de production dépend de la chaîne d'outils privée d'un consultant. Il peut détenir des licences étendues tandis qu'un client gouvernemental contrôle l'approbation du déploiement.
Le modèle de diligence doit enregistrer séparément la propriété, la possession, l’accès, les droits de modification, les droits de distribution, l’autorité opérationnelle et les droits de résiliation. Chaque élément nécessite des preuves documentaires. Les preuves pertinentes comprennent les missions, les conditions d'emploi, les accords avec les entrepreneurs, les calendriers de licences, les autorisations de référentiel, les enregistrements de déploiement, les contrats clients et les confirmations des fournisseurs.
Le contrôle a également une dimension temporelle. L'accès qui existe pendant la vérification peut expirer à la clôture. L'acheteur doit identifier les actions exactes requises pour préserver l'accès au référentiel, la location cloud, l'autorité de signature, les informations d'identification de l'administrateur, l'historique de surveillance et l'assistance du fournisseur tout au long de la transaction.
3 Construire l'inventaire des logiciels et des dépendances
L'inventaire doit identifier les applications, les services, les référentiels, les branches, les systèmes de build, les packages de déploiement, les bases de données, les interfaces, les produits commerciaux, les composants open source, les bibliothèques cryptographiques et les scripts opérationnels. Il doit connecter chaque composant à la fonction de mission qu'il prend en charge et à l'environnement dans lequel il s'exécute.
Un SBOM peut accélérer la découverte de composants. Il ne remplace pas le stock d'exploitation. Un inventaire d'acquisition utile relie le nom et la version du composant à la source, à la licence, au responsable, à l'état de vulnérabilité, à l'artefact de construction, à la configuration déployée, à la dépendance des données et au chemin de remplacement. Les composants intégrés dans des conteneurs, des micrologiciels ou des appareils d'un fournisseur nécessitent une attention particulière car ils peuvent être absents d'une liste d'applications conventionnelle.
L'acheteur doit concilier trois points de vue : ce que l'ingénierie dit existe, ce que contiennent les référentiels et ce que la télémétrie de production montre en cours d'exécution. Les différences sont des constatations de diligence. Un service non enregistré peut être critique. Un référentiel répertorié peut être obsolète. Un binaire de production ne peut pas remonter à une validation source approuvée.
4 Tester l'exhaustivité du code source
L'accès au référentiel doit couvrir l'intégralité du produit et son historique. L'acheteur doit inspecter la source, la configuration, les définitions d'infrastructure, les schémas de base de données, les actifs de test, les scripts de construction, l'automatisation du déploiement, la documentation et l'historique des problèmes. Un instantané des fichiers sélectionnés ne peut pas démontrer l'exhaustivité.
Les tests d'exhaustivité commencent à partir des artefacts déployés. L'équipe identifie les binaires ou conteneurs de production représentatifs et les retrace jusqu'aux révisions sources, aux versions de dépendances, aux paramètres de construction et aux enregistrements d'approbation. Il construit ensuite le logiciel dans un environnement contrôlé et compare le résultat avec l'artefact déployé ou sa provenance documentée. Les différences nécessitent une explication.
Le code généré mérite un traitement séparé. Les directives de la NASA reconnaissent que la maintenance à long terme peut nécessiter l'accès à des modèles, des simulations, des définitions de données, des générateurs, des données de construction, des scripts de test et des résultats attendus. La possession de la source générée peut s'avérer insuffisante lorsque le générateur, le modèle ou la configuration qualifiée est manquant.
5 Reproduire le build
Une construction reproductible est un test de diligence de grande valeur. L'objectif est de montrer qu'une équipe autorisée peut créer une version déployable à partir d'entrées contrôlées sans intervention non documentée. Le test doit utiliser un environnement propre et la procédure documentée de la cible. Les observateurs des acheteurs doivent enregistrer les conditions préalables, les téléchargements externes, les informations d'identification, les étapes manuelles, les versions des outils, les avertissements et les écarts.
Le résultat n'a pas besoin d'être identique bit à bit lorsque le processus existant ne prend pas en charge la compilation déterministe. Il doit être traçable et fonctionnellement équivalent selon des tests convenus. L'acheteur doit comprendre pourquoi une différence apparaît et si le processus préserve l'intégrité.
L'échec de la construction peut révéler des licences manquantes, des certificats expirés, des référentiels de packages indisponibles, des correctifs non documentés ou une dépendance à l'égard d'un ingénieur nommé. Ces résultats sont directement liés aux coûts de transition et au risque de continuité. Le contrat d’achat peut exiger une construction propre et réussie avant la clôture ou placer la contrepartie en dépôt jusqu’à ce que la condition soit remplie.
6 Autorité de publication et de déploiement de trace
L’accès à la source n’établit pas la capacité d’exploiter la production. L'acheteur doit retracer l'autorité depuis l'approbation du code jusqu'à la construction, la signature, la publication, le déploiement et la restauration. La trace identifie qui peut approuver les modifications, qui détient les informations d'identification de signature, où les packages sont stockés, comment les environnements sont promus et comment les versions d'urgence sont contrôlées.
Les modifications apportées au contrôle des satellites peuvent avoir des conséquences sur la sécurité des missions. Les preuves de version doivent inclure les résultats de la vérification, l'examen de l'état de préparation opérationnelle, l'approbation de la configuration, le consentement du client ou de l'autorité, le cas échéant, et une voie de récupération testée. L'acheteur doit distinguer les versions d'applications de routine des modifications apportées à la validation des commandes, à la dynamique de vol, à l'interprétation de la télémétrie ou à la confiance cryptographique.
Le transfert d’informations d’identification nécessite un processus conçu. Les clés privées et les informations d’identification privilégiées ne doivent pas être copiées avec désinvolture lors de la clôture. Les parties doivent convenir de la rotation, de la révocation, de la réinscription, du double contrôle, de la préservation de l'audit et du démantèlement. Le plan de clôture doit indiquer quand l'autorité opérationnelle change et comment une responsabilité ambiguë est évitée.
7 Examiner les données de configuration de la mission
Les logiciels de contrôle de mission reposent sur une configuration qui peut être aussi précieuse que le code source. Les dictionnaires de commandes, les définitions de télémétrie, les limites, les données d'étalonnage, les modèles d'engins spatiaux, les plans de contact, les paramètres orbitaux, les règles d'automatisation et le routage client déterminent la manière dont les logiciels génériques interagissent avec une flotte réelle.
L'acheteur doit identifier la source faisant autorité pour chaque classe de configuration, son processus d'approbation, son historique des versions et sa méthode de récupération. Il doit tester si un nouvel environnement peut être alimenté à partir d'enregistrements contrôlés. La configuration basée sur une feuille de calcul ou stockée localement crée des risques lorsqu'elle manque de révision, de traçage et de sauvegarde.
Les droits de configuration sont également importants. Un client, un fabricant d'engins spatiaux ou un intégrateur de systèmes peut posséder ou restreindre une partie des données. L'accord d'acquisition doit aborder le transfert, l'utilisation continue, la confidentialité, les restrictions à l'exportation et les obligations de suppression. Une configuration manquante peut rendre un logiciel autrement complet inutilisable pour une mission spécifique.
8 Évaluer les preuves d'assurance logicielle
Les preuves d'assurance logicielle montrent si le produit a été développé et maintenu selon des pratiques contrôlées. Le SSDF du NIST organise le développement sécurisé autour de la préparation de l'organisation, de la protection des logiciels, de la production de logiciels bien sécurisés et de la réponse aux vulnérabilités. Les directives d'assurance logicielle de la NASA ajoutent des preuves objectives des contextes de sécurité et de mission.
L'acheteur doit examiner la traçabilité des exigences, les décisions d'architecture, la révision du code, l'analyse statique, l'analyse des dépendances, la couverture des tests, l'approbation des versions, l'historique des défauts et la réponse aux vulnérabilités. Les preuves doivent correspondre aux versions en production. Un document de politique sans documents signés fournit une assurance limitée.
L’équipe de diligence doit échantillonner les chemins critiques tels que la génération de commandes, l’authentification, la gestion des privilèges, la détermination de l’orbite et la récupération. Il convient d'examiner si les tests couvrent les conditions défavorables et aux limites. Les résultats ouverts doivent être classés par conséquence de la mission, exploitabilité, récupérabilité et dépendance en matière de remédiation.
9 Cartographier la chaîne d'approvisionnement des logiciels
La chaîne d'approvisionnement comprend des fournisseurs commerciaux, des projets open source, des fournisseurs de cloud, des services de build, des référentiels de packages, des fournisseurs de matériel, des consultants et des opérateurs spécialisés. L'acheteur doit identifier les parties qui peuvent modifier, interrompre, accéder ou restreindre le produit.
Pour chaque fournisseur critique, la diligence doit couvrir le support contractuel, la résilience financière, les pratiques de sécurité, les privilèges d'accès, la notification des incidents, le contrôle des modifications, la politique de fin de vie, la localisation des données et le délai de substitution. Un fournisseur qui prend en charge plusieurs composants critiques crée de la concentration même lorsque les dépenses annuelles sont faibles.
Le NIST SP 800-161 traite le risque de la chaîne d'approvisionnement comme un problème de gouvernance organisationnelle plutôt que comme une liste de contrôle d'approvisionnement. L'équipe de transaction doit relier les preuves du fournisseur à la criticité du système et à la propriété planifiée. Les fournisseurs de matériaux peuvent exiger un consentement, une novation ou un accord direct avant de conclure.
10 Analyser l'exposition open source
Les composants open source peuvent améliorer les capacités et réduire le temps de développement. Ils créent également des obligations en matière de licence, de maintenance et de sécurité. L'acheteur doit rapprocher les composants déclarés avec l'analyse du code et créer des manifestes. Il doit identifier les termes de la licence, les modifications, les avis, les pratiques de distribution et les vulnérabilités connues.
L’exposition au copyleft nécessite une analyse juridique basée sur l’utilisation et la distribution réelles. Une étiquette de licence à elle seule n’établit pas l’obligation. L'équipe doit documenter la manière dont les composants sont liés, déployés, modifiés et fournis aux clients. La remédiation peut impliquer la correction d'un avis, des offres de source, le remplacement de composants ou une communication avec le client.
L’état de maintenance affecte la valeur. Une bibliothèque critique sans responsable actif ni version prise en charge peut nécessiter une propriété interne. L’acheteur doit évaluer la stratégie du fork, la couverture des tests, la capacité des correctifs et la dépendance de la communauté. Une nomenclature logicielle doit rester à jour après la clôture plutôt que de devenir un artefact de diligence statique.
11 Examiner la provenance de la propriété intellectuelle
Chaque contribution au code matériel doit avoir un chemin de provenance défendable. Les inventions des employés doivent s'inscrire dans des conditions d'emploi appropriées. Le travail de l’entrepreneur doit être attribué avec une portée suffisante. Le code acquis ou contribué doit comporter les droits nécessaires. Le développement financé par l’université, le gouvernement ou le client peut inclure des restrictions qui nécessitent un examen détaillé.
L'équipe doit échantillonner l'historique des engagements par rapport aux enregistrements et aux contrats des contributeurs. Les auteurs non reconnus, les témoignages personnels ou les importations massives inexpliquées méritent une enquête. L'examen doit inclure la documentation, les modèles, les données de test, les interfaces utilisateur et les algorithmes, car la propriété intellectuelle précieuse s'étend au-delà des fichiers sources.
L’analyse des brevets et des secrets commerciaux doit se concentrer sur le produit réel et le plan commercial. L'acheteur doit comprendre les enregistrements défensifs, la liberté d'exploitation, les contrôles de confidentialité et toute divulgation susceptible d'affaiblir la protection des secrets commerciaux. Les documents de transaction peuvent attribuer des risques de provenance spécifiques au moyen de garanties, d'indemnisations, de dépôts fiduciaires ou de contreparties conditionnelles.
12 Tester l’accès privilégié et la ségrégation
Les environnements de contrôle de mission concentrent de puissants privilèges. Les administrateurs peuvent contrôler les commandes, l'identité, les bases de données, les ressources cloud, les clés de signature et la surveillance. L'acheteur doit obtenir un inventaire privilégié couvrant les comptes humains, de service et d'urgence dans les environnements de développement, de test, de production et de récupération.
L’examen devrait tester les contrôles des nouveaux arrivants, des nouveaux arrivants et des sortants ; authentification multifacteur ; approbation; journalisation des sessions ; rotation des titres de compétences ; accès aux bris de vitres ; et la ségrégation entre le développement et la production. Les comptes partagés ou dormants réduisent la responsabilité. Les comptes de service nécessitent des contrôles de propriété et de cycle de vie.
La fermeture crée un risque d’accès accru. Le personnel qui part peut conserver ses informations d'identification ou sa connaissance des voies de rétablissement. Le plan de transition devrait alterner les informations d’identification sensibles, révoquer les anciens accès, préserver les preuves et maintenir une double couverture opérationnelle. Ces actions doivent être répétées là où la perte d'accès pourrait affecter une mission en direct.
13 Examiner la gestion des vulnérabilités
L'acheteur doit comprendre comment les vulnérabilités sont découvertes, triées, corrigées et communiquées. Les sources incluent l'analyse statique, l'analyse des dépendances, les tests d'intrusion, les rapports clients, les avis des fournisseurs et la surveillance opérationnelle. Le programme doit définir la gravité, les conséquences de la mission, le calendrier des mesures correctives, l'approbation des exceptions et les nouveaux tests.
L’analyse du backlog peut révéler des besoins de maintenance cachés. L'acheteur doit examiner l'âge, la récurrence, les versions concernées et la qualité de la fermeture. Un nombre faible peut refléter une détection faible. Un nombre élevé peut refléter une découverte active. La mesure utile est la capacité de l'organisation à identifier l'exposition pertinente et à la réduire dans des délais fondés sur les risques.
Les systèmes de vol et au sol peuvent avoir des fenêtres de mise à jour limitées. La cible doit montrer comment elle applique des contrôles compensatoires et planifie des rejets sûrs. Les vulnérabilités connues des composants inaccessibles ou en fin de vie peuvent justifier une déduction de prix spécifique ou une réserve de remédiation financée.
14 Évaluer les interfaces et l'interopérabilité
Les logiciels de contrôle des satellites dépendent des interfaces avec les engins spatiaux, les stations au sol, les réseaux, les systèmes d'identité, les plates-formes clients, les données météorologiques, les données orbitales et les services de réglementation. L'acheteur doit inventorier le protocole, la version, le propriétaire, les exigences de performances, le contrôle de sécurité, l'environnement de test et le processus de modification pour chaque interface.
La documentation de l'interface doit être testée par rapport au trafic observé et aux configurations actuelles. Les interfaces propriétaires ou non documentées créent un verrouillage. Un protocole standard peut toujours contenir des extensions spécifiques au client qui compliquent le remplacement.
L'équipe doit tester les modes de défaillance. Il doit observer des données retardées, des messages en double, des erreurs d'horloge, des entrées corrompues, une interruption du réseau et une perte partielle de service. Le comportement de récupération affecte la valeur opérationnelle. Les plans d'intégration doivent préserver l'observabilité de l'interface et éviter de modifier plusieurs dépendances critiques à la fois.
15 Évaluer les droits et les enregistrements relatifs aux données
Les données opérationnelles prennent en charge la surveillance, l'analyse des anomalies, l'amélioration des modèles, les rapports clients et les preuves réglementaires. L'acheteur doit distinguer les droits de propriété, de garde, d'utilisation autorisée, de conservation et d'exportation pour la télémétrie, les commandes, les produits dérivés, les journaux, les informations client et les données de formation.
Le périmètre de transaction doit inclure les données historiques nécessaires au fonctionnement et à l'amélioration du système. Un acheteur peut recevoir un logiciel sans historique opérationnel suffisant pour régler les alertes ou enquêter sur des anomalies. La migration des données doit préserver les horodatages, la provenance, les contrôles d’accès et l’intégrité des preuves.
Les obligations de confidentialité et de localisation peuvent s’appliquer aux données du personnel et des clients. Les contrôles à l'exportation et les restrictions liées à la sécurité nationale peuvent affecter les données techniques et l'accès des personnes étrangères. L’analyse juridique doit faire correspondre les obligations aux ensembles de données réels et aux lieux d’exploitation.
16 Examiner la résilience opérationnelle et le rétablissement
Les tests de résilience doivent montrer comment le service perdure malgré les pannes d’infrastructure, de logiciels, de fournisseurs et humaines. L'acheteur doit examiner la redondance, les sauvegardes, les environnements de récupération, les alternatives de communication, les procédures manuelles, les objectifs de récupération et les résultats des exercices.
Une sauvegarde n'est utile que lorsqu'elle peut être restaurée dans les limites de tolérance de la mission. L’équipe de diligence doit observer une restauration représentative et valider la configuration, les informations d’identification, les dépendances et l’intégrité des données. La récupération doit inclure la possibilité de reconstruire les systèmes lorsque l'environnement principal ou le fournisseur n'est pas disponible.
L’acquisition elle-même doit être traitée comme un événement de résilience. Les systèmes d'entreprise, les domaines, les comptes cloud et les contrats de support peuvent changer. Un plan de basculement détaillé, des critères de restauration, une autorité de commandement et un processus d'incident conjoint réduisent les risques de transition.
17 Évaluer la concentration des personnes et des connaissances
La continuité logicielle dépend de personnes qui comprennent l'architecture, les missions, les anomalies, les clients et le jugement opérationnel. L'acheteur doit mapper les rôles aux processus critiques et identifier les points de connaissance uniques. Les organigrammes fournissent des preuves limitées ; la carte doit refléter qui résout réellement les incidents et approuve les versions.
Les décisions de rétention doivent tenir compte à la fois de l’importance technique et de l’indépendance. Les connaissances concentrées peuvent être réduites grâce au jumelage, à la documentation, à la répétition et à la succession. Les paiements de rétention sans étapes de transfert de connaissances peuvent préserver la dépendance plutôt que de la réduire.
Le modèle de transaction devrait inclure les coûts de recrutement, de rétention, de conversion d’entrepreneur et de formation. Le risque lié à une personne clé peut affecter la valorisation lorsque la capacité ne peut pas être transférée pendant la période de transition. La direction doit rendre compte des progrès réalisés par rapport aux preuves de transfert de connaissances citées.
18 Examiner l'acceptation des clients et des réglementations
Les contrats clients peuvent définir les obligations en matière de performances logicielles, de sécurité, d’audit, d’approbation et de modification. L'acheteur doit identifier les contrats qui nécessitent un consentement, un avis, une recertification ou un personnel nommé. Il doit séparer les revenus transférés automatiquement des revenus dépendant de l’acceptation du client.
Les clients gouvernementaux et d'infrastructures critiques peuvent imposer des restrictions en matière de données techniques, d'habilitation de sécurité, d'hébergement ou de chaîne d'approvisionnement. L'acheteur doit évaluer si sa propriété, son financement, son personnel et son modèle opérationnel restent éligibles. Les licences réglementaires et les droits de spectre peuvent se situer en dehors de l'entité logicielle tout en restant essentiels à la prestation de services.
Le modèle commercial devrait pondérer les probabilités des renouvellements et des consentements incertains. La contrepartie peut dépendre d’un transfert vérifié ou de revenus retenus. L'acheteur doit éviter de payer la pleine valeur pour des contrats dont les conditions d'exploitation ne sont pas transférables.
19 Relier la diligence à la valorisation
La diligence logicielle modifie la valeur en fonction des flux de trésorerie, du calendrier, du risque et de la durée de vie des options. La remédiation augmente les coûts. Les droits manquants peuvent réduire les revenus adressables. la fragilité opérationnelle peut augmenter la probabilité de panne. Un contrôle de construction faible peut retarder le développement du produit. Des preuves solides peuvent étayer des réserves d’intégration plus faibles et une plus grande confiance dans le renouvellement.
Le pont de valorisation devrait éviter la duplication des ajustements. Un coût de support récurrent fait partie des flux de trésorerie prévisionnels. Une reconstruction unique appartient aux utilisations de transaction ou d'intégration. Un défaut de droits binaires peut nécessiter une exclusion, un séquestre ou une condition plutôt qu'une prime de taux d'actualisation.
L’acheteur doit présenter des cas de base, des inconvénients et des cas graves. Chaque cas doit identifier les hypothèses opérationnelles, les preuves et les actions de gestion. La valeur finale doit refléter la maintenance continue, l'obsolescence des composants, la concentration des fournisseurs et la capacité de rafraîchir le produit.
20 Traduire les résultats en mécanismes de transaction
Les découvertes matérielles doivent avoir un propriétaire et une réponse transactionnelle. Les réponses possibles incluent une réduction de prix, une retenue, un séquestre, un complément de prix, une indemnité, une condition de clôture, un engagement, un service de transition, une novation de licence, un accord avec une personne clé ou un actif exclu.
Les conditions doivent être objectivement testables. L'exigence de fournir des sources complètes est faible sans référentiels, branches, artefacts et tests d'acceptation définis. Une condition de build peut spécifier l'environnement, les entrées, la suite de tests réussie et le package de déploiement. Une condition d'accès peut spécifier des identités, des privilèges, des clés et une connexion vérifiée.
Le processus de divulgation doit préserver les preuves versionnées. L'acheteur doit enregistrer quels artefacts soutiennent chaque représentation et qui a accepté les exceptions. Les calendriers techniques doivent être révisés par des ingénieurs et des conseillers juridiques afin que le langage juridique corresponde à la réalité opérationnelle.
21 Concevoir la salle de contrôle de fermeture
La clôture doit être gérée comme un changement opérationnel. La salle de contrôle coordonne l'achèvement légal, le transfert d'informations d'identification, la novation de fournisseur, la location cloud, les référentiels de codes, l'autorité de signature, les notifications clients, la surveillance et la couverture des incidents.
Le plan doit utiliser des critères explicites de démarrage, de maintien et de restauration. Chaque étape identifie les preuves, le calendrier, la personne responsable et la solution de secours. L'accès critique doit être testé avant que des actions irréversibles ne se produisent. Les parties doivent maintenir une couverture conjointe pendant la fenêtre à risque le plus élevé.
L'acheteur doit conserver les journaux et les instantanés de configuration. Ces dossiers établissent l’état au moment du transfert et soutiennent une enquête ultérieure. La première version post-clôture devrait suivre le processus d'assurance convenu plutôt que de devenir un test d'intégration improvisé.
22 Établir les 100 premiers jours
Les 100 premiers jours devraient stabiliser le contrôle, combler les lacunes en matière de preuves prioritaires et réduire la concentration. Les premières actions incluent la recertification des accès, la rotation des informations d'identification, les versions propres, la confirmation des dépendances, la correction du retard critique, les tests de récupération, la fidélisation du personnel et la gouvernance des fournisseurs.
Les changements d’architecture doivent suivre les preuves. Une migration immédiate de plateforme peut combiner une transition de propriété avec un changement technique et créer des risques évitables. L'équipe d'intégration doit séquencer les changements autour des fenêtres de mission, des engagements des clients et de la capacité de récupération.
Le conseil d'administration doit recevoir un tableau de bord concis couvrant la reproductibilité de la construction, les vulnérabilités critiques, l'accès aux clés, les novations de fournisseurs, les consentements des clients, les tests de récupération, le transfert de connaissances et les dépenses. L'achèvement rapporté doit nécessiter des preuves objectives.
23 Gouverner la valeur continue du logiciel
La gouvernance post-clôture doit relier la santé des logiciels aux résultats commerciaux et financiers. Les mesures d'ingénierie incluent la fiabilité du déploiement, l'évasion des défauts, l'âge de la vulnérabilité, l'intégrité de la construction, les performances de récupération et l'état de dépendance. Les mesures commerciales incluent la disponibilité du service, le renouvellement, la latence de livraison et les coûts de support.
La feuille de route du produit doit distinguer la maintenance obligatoire, les engagements clients, les mesures correctives en matière de sécurité et les investissements de croissance. Une maintenance différée peut gonfler les bénéfices à court terme tout en affaiblissant la génération future de liquidités. Les comités d’investissement devraient comprendre cette distinction.
L'acheteur doit tenir un registre de preuves des droits, configurations et fournisseurs critiques. Des changements de propriété, de licence, de support ou d'architecture peuvent modifier la thèse d'acquisition. L’assurance annuelle et les examens périodiques de l’état de préparation des transactions préservent la possibilité de refinancement ou de sortie.
24 Cas de transaction hypothétique
La cible hypothétique prend en charge 18 satellites pour des missions de communications, d’observation de la Terre et de charge utile hébergée. Sa plateforme comprend la planification de mission, la validation des commandes, le traitement de télémétrie, la dynamique de vol, l'automatisation et la livraison client. Les revenus sont générés par le biais de contrats annuels de logiciels et d’exploitation.
La diligence confirme une forte fidélisation de la clientèle et une ingénierie compétente. Il identifie également cinq risques liés aux transactions. Les versions de production nécessitent un outil commercial non documenté. Deux bibliothèques sont concédées sous licence au parent du vendeur et ne peuvent pas être transférées automatiquement. Un administrateur contrôle les principaux processus de production et de signature. La correction des vulnérabilités critiques a été reportée autour des fenêtres de mission. Un adaptateur spécifique au client contient des contributions avec des preuves d'affectation incomplètes.
L'acheteur évalue ces résultats en déduisant globalement USD 25 million de la valeur globale USD 84 million. Un complément de prix USD 6 million supplémentaire est disponible lorsque les critères de preuve définis sont remplis. La structure préserve la participation du vendeur à la remédiation tout en protégeant les liquidités de l'acheteur à la clôture.
25 Principes de décision
Tout d’abord, définir la capacité de mission acquise et son périmètre opérationnel. Deuxièmement, tracez chaque artefact déployé critique jusqu’à la source contrôlée, la construction et l’approbation des preuves. Troisièmement, séparer la propriété, l’accès, les droits et l’autorité opérationnelle. Quatrièmement, mappez la concentration des fournisseurs et des personnes à la continuité. Cinquièmement, testez la récupération et le basculement des transactions. Sixièmement, traduisez chaque dépendance non résolue en espèces, en conditions ou en protection contractuelle.
Ces principes créent un langage commun pour les équipes d’ingénierie, financières, opérationnelles et juridiques. Ils améliorent également la vitesse des transactions car les demandes de preuves et les tests d’acceptation deviennent spécifiques.
L'objectif de l'acheteur est un contrôle démontrable des résultats de la mission. Ce contrôle soutient la continuité, la confiance des clients, l’intégration et une valorisation défendable.
26 Revoir l’architecture et la dette technique
La diligence architecturale doit expliquer comment le système sépare la planification de mission, la dynamique de vol, la validation des commandes, la télémétrie, l'automatisation, l'identité, les magasins de données et les interfaces externes. L'acheteur doit identifier les limites de confiance, les domaines de défaillance, les services partagés et les composants dont le changement pourrait affecter plusieurs missions. Les diagrammes d'architecture doivent être réconciliés avec la topologie déployée, les flux réseau et la propriété du référentiel.
La dette technique doit s’exprimer par des conséquences. Un ancien langage de programmation peut rester gérable lorsque l'expertise, les tests et les chaînes d'outils sont disponibles. Un service moderne peut être fragile lorsqu’il manque d’appropriation, d’observabilité ou de récupération. L’équipe de diligence doit estimer le coût, le séquencement et le risque opérationnel de chaque élément de dette important.
La classification de la dette doit distinguer la maintenabilité, la sécurité, la performance, l'évolutivité, l'obsolescence et la conformité. Le modèle commercial doit refléter les catégories qui freinent la croissance ou la fidélisation de la clientèle. Les plans de remédiation doivent identifier les dépendances et les fenêtres de mission plutôt que de présenter un arriéré indifférencié.
27 Évaluer l’observabilité et les preuves d’incidents
La valeur du contrôle de mission dépend de la capacité à détecter et à expliquer un comportement anormal. L'acheteur doit examiner les journaux, les métriques, les traces, les alertes, les tableaux de bord, la conservation, la synchronisation de l'horloge et les enregistrements d'incidents. Il doit identifier où les données sont générées, qui peut y accéder et si les enregistrements survivent à une défaillance du système ou d'un fournisseur.
La qualité des alertes mérite un échantillonnage. Des volumes élevés d’alertes non exploitables peuvent dissimuler des événements importants. Les alertes éparses peuvent refléter une couverture limitée. L'équipe doit comparer les incidents sélectionnés avec la télémétrie enregistrée, les actions de réponse, l'analyse des causes profondes et les travaux correctifs. Des incidents répétés sans mesures correctives durables indiquent une faiblesse du contrôle.
La planification des transactions doit préserver la continuité du suivi. La migration de compte, la séparation du cloud ou le remplacement d'outils peuvent créer des périodes aveugles. Le plan de clôture doit définir quelles alertes restent actives, qui les reçoit et comment l'équipe commune gère un événement pendant la transition. Les preuves d’une surveillance stable peuvent justifier une période de transition plus courte.
28 Tester l’évolutivité et l’expansion de la flotte
Les performances historiques ne permettent pas d'établir que la plateforme peut prendre en charge la flotte prévue par l'acheteur. L'équipe doit identifier les facteurs d'échelle tels que les satellites, les contacts, le volume de télémétrie, la charge de commande, les interfaces client, les opérateurs concurrents et les sites au sol. Il devrait examiner les pics d’utilisation observés et les marges de capacité.
Les tests de charge doivent utiliser des modèles de messages et des conditions de défaillance représentatifs. Les opérations spatiales peuvent créer de courtes périodes d’activité intense autour du lancement, de la mise en service, des anomalies et des fenêtres de contact. L'utilisation moyenne peut masquer les files d'attente, les conflits de base de données ou la surcharge des opérateurs pendant ces périodes.
Le dossier de croissance doit inclure les coûts d’infrastructure, de licence, de support et de personnel. Une plate-forme techniquement évolutive peut être confrontée à des limites commerciales liées aux prix par fournisseur de satellite ou au manque de spécialistes. Le modèle d'évaluation doit aligner les revenus de croissance sur les coûts d'investissement et d'exploitation nécessaires pour les réaliser.
29 Évaluez soigneusement les fonctionnalités de l’intelligence artificielle
Les cibles peuvent utiliser l'apprentissage automatique pour la détection d'anomalies, la planification, le traitement d'images, la maintenance prédictive ou l'assistance aux opérateurs. La diligence doit identifier la décision exacte prise en charge, le propriétaire du modèle, les droits sur les données de formation, la validation, la surveillance, la surveillance humaine et la réponse aux échecs. Les descriptions marketing fournissent des preuves limitées de la valeur opérationnelle.
L'acheteur doit comparer les performances revendiquées avec une référence définie et des données de mission représentatives. Il doit examiner les faux positifs, les faux négatifs, la dérive, le recyclage, le contrôle de version et les cas extrêmes. Un modèle qui améliore la détection moyenne peut encore s’avérer inadapté aux décisions de commandement lorsque ses modes de défaillance sont opaques.
Les outils génératifs utilisés en ingénierie ou en opérations nécessitent une gouvernance sur les données sensibles, la provenance du code et l'examen des résultats. La feuille de route du produit doit séparer la valeur client démontrée de la capacité expérimentale. L'évaluation doit reconnaître les revenus liés à AI uniquement lorsque les droits, les performances, le déploiement et la conversion en espèces sont attestés.
30 Examiner les contraintes liées au contrôle des exportations et à l’accès souverain
Les logiciels, données techniques et services satellitaires peuvent être soumis à des contrôles à l'exportation, à des sanctions, à des classifications de sécurité et à des exigences d'accès souverain. L'acheteur doit cartographier les articles contrôlés, les licences, les nationalités, les emplacements, les régions cloud et les restrictions des clients. Les avocats spécialisés doivent interpréter le régime juridique applicable.
L'accès opérationnel peut être limité même en cas de transfert de propriété. Certains clients peuvent avoir besoin d'un personnel autorisé, d'un hébergement national ou d'un support séparé. La structure de propriété et de financement de l'acheteur peut déclencher un examen ou un consentement. Ces facteurs affectent la conception de l’intégration et la capacité à centraliser les opérations.
Le modèle de transaction doit inclure le personnel chargé de la conformité, les environnements séparés, le calendrier des licences et les éventuelles restrictions de revenus. Les conditions de clôture doivent porter sur les approbations nécessaires à la continuité. La direction doit éviter les assurances générales et identifier le champ d’application précis couvert par chaque autorisation.
31 Créer un dossier de preuves pour le comité d'investissement
Le comité d'investissement a besoin d'un lien concis entre les découvertes techniques et les décisions économiques. Le pack doit commencer par la capacité acquise, la dépendance aux revenus et les points de contrôle critiques. Il doit présenter la source et construire des preuves, la position des droits, la carte des fournisseurs, la résilience opérationnelle, les consentements des clients et la concentration des personnes.
Chaque découverte importante doit indiquer l'état de la preuve, les conséquences financières, le mécanicien proposé, le propriétaire responsable et le risque résiduel. Le comité doit être capable de distinguer une lacune vérifiée d'une estimation de la direction et d'une promesse de remédiation future. L’analyse de scénarios doit montrer l’effet des retards et des échecs combinés.
L'approbation doit indiquer les conditions, les pouvoirs délégués et les rapports post-clôture. L’ensemble des preuves devient alors la référence pour la gouvernance de l’intégration. Cette continuité réduit le risque que les conclusions de la diligence disparaissent après la clôture et soutient la responsabilité ultérieure en matière de création de valeur.
32 Plan de séparation du vendeur
Une exclusion nécessite un modèle de séparation couvrant les applications, l’infrastructure, les identités, les réseaux, les contrats, les données et les personnes. L'acheteur doit identifier les services qui restent chez le vendeur, les services qui sont transférés et les services qui doivent être reconstruits. Chaque ligne devrait avoir un mode d'exploitation provisoire, un état cible, un coût, une dépendance et un critère de sortie.
Les accords de services de transition doivent décrire des services mesurables et des responsabilités opérationnelles. Ils doivent identifier les niveaux de service, les obligations de sécurité, la coordination des incidents, l'accès, le contrôle des modifications, la restitution des données, les droits d'audit, la tarification et la résiliation. Un engagement général à fournir une assistance raisonnable peut laisser des besoins critiques de la mission sans réponse.
Le calendrier de séparation doit suivre les contraintes de la mission. Les modifications d’identité ou de réseau peuvent affecter les chemins de surveillance et de commande. La migration des données peut affecter l’historique et les éléments probants. La novation de fournisseur peut modifier les droits de support. Les parties doivent organiser des changements à haut risque et maintenir le retour en arrière jusqu'à ce que les critères d'acceptation soient remplis.
La préparation à la sortie doit être testée avant la fin d’un service de transition. L’acheteur doit démontrer son indépendance d’accès, de construction, de déploiement, de surveillance, de support et de récupération. Il devrait également confirmer que les comptes et les données des vendeurs peuvent être supprimés sans interrompre le service. Toute extension doit avoir une raison, un prix et un propriétaire de correction définis.
Le coût de séparation appartient au modèle de transaction. Cela comprend l'infrastructure en double, les licences temporaires, l'ingénierie de migration, les tests de sécurité, la validation client et le chevauchement des opérations. L'estimation doit distinguer les cotations engagées des hypothèses de gestion. Un plan de séparation financé et régi protège la continuité et évite que la transaction ne crée une dépendance indéfinie à l'égard du vendeur.
Le conseil d’administration devrait recevoir un tableau de bord hebdomadaire des séparations jusqu’à ce que tous les services essentiels à la mission fonctionnent de manière indépendante. Le tableau de bord doit identifier les dépendances en retard, les sorties testées, les obligations client non résolues, les coûts prévus et la prochaine action irréversible. La clôture devrait nécessiter des preuves provenant de l'ingénierie, des opérations, de la sécurité, des finances et du propriétaire du service concerné.
Annexe A Registre des preuves de diligence
Le registre des preuves doit identifier la question, l'artefact demandé, le propriétaire de la source, la version, le résultat de l'examen, l'exception, les conséquences financières et la réponse à la transaction. Il doit rester lié à la salle de données virtuelle afin que les conclusions puissent être reproduites.
Les preuves hautement prioritaires comprennent l'inventaire de production, la carte du référentiel, le résultat de la construction propre, la trace du déploiement, l'inventaire des privilèges, le calendrier des licences, le SBOM, le retard de vulnérabilité, le test de récupération, la carte de consentement du client et le plan de la personne clé. Chaque élément doit identifier les systèmes et configurations exacts couverts.
L'échantillonnage doit être basé sur les risques. L'équipe doit choisir des missions représentatives à fortes conséquences, des interfaces critiques, des versions récentes, des modifications d'urgence et des composants plus anciens. Les échantillons doivent tester à la fois la conception du contrôle et son exécution réelle.
Annexe B Méthode d'évaluation
La méthode illustrative commence par la valeur d'entreprise dérivée du modèle commercial de l'acheteur. Il ajuste ensuite les flux de trésorerie prévus en fonction des coûts récurrents de maintenance et des fournisseurs. Les coûts ponctuels d’assainissement, de séparation et de transition sont inclus dans les utilisations. Les revenus soumis au consentement du client sont pondérés en fonction de leur probabilité. Les défauts de droits et les conditions opérationnelles sont corrigés au moyen de déductions, de dépôts fiduciaires ou de contreparties conditionnelles.
L’analyse de scénarios doit combiner les risques associés. Un retard d’un fournisseur peut également retarder la résolution et l’acceptation du client. Le départ d’une personne clé peut affaiblir à la fois la continuité et le transfert de connaissances. Les inconvénients corrélés méritent un traitement explicite.
Aucun numéro hypothétique dans ce document ne représente une transaction identifiée. Le cas démontre comment les preuves peuvent être liées à l’évaluation et à la structure de la transaction.
Annexe C Clôture des tests d'acceptation
Les tests d'acceptation doivent couvrir l'accès au référentiel, la construction propre, l'exécution des tests, la signature des packages, le déploiement hors production, la restauration de la configuration, la surveillance, l'accès privilégié, le support et la récupération des fournisseurs. Les parties doivent convenir des données de test, de l'environnement, des critères de réussite et des preuves avant de signer.
Les tests doivent éviter toute interruption opérationnelle en direct. Les changements de production nécessitent l’approbation de la mission et des contrôles séparés. Un test hors production peut toujours valider la chaîne depuis la source contrôlée jusqu'à l'artefact déployable.
Les tests échoués devraient avoir des conséquences prédéfinies. Ceux-ci peuvent inclure la guérison, le séquestre, la clôture retardée, la réduction de la contrepartie ou l'exclusion d'un actif. La réponse doit être à la hauteur de l’importance opérationnelle et financière de l’échec.
Annexe D Chiffres et tableaux de décision
Progression des preuves illustratives ; les valeurs sont hypothétiques et ne représentent pas une entreprise identifiée.
Des scores plus élevés indiquent une plus grande dépendance dans le cas hypothétique.
Séquence proposée ; le calendrier réel dépend des faits de la transaction et des contraintes de la mission.
Des valeurs totalement hypothétiques ; USD millions.
Séquence proposée sous réserve des fenêtres de mission et des obligations du client.
| Preuve | Question transactionnelle | Indicateur d'acceptation | Réponse à l'écart |
|---|---|---|---|
| Inventaire du référentiel | Toutes les sources matérielles sont-elles contrôlées ? | Les composants de production sont tracés vers des référentiels nommés | Condition d’achèvement ou exclusion du champ d’application |
| Définition de construction | Un environnement propre peut-il produire un rejet ? | Construction contrôlée réussie avec des entrées documentées | Plan de retenue et de remédiation |
| Provenance | Les artefacts déployés peuvent-ils être retracés ? | Version, dépendances, approbation et signature liées | Réserve de risque et remédiation des contrôles |
| Artefacts générés | Des modèles et des générateurs sont-ils disponibles ? | Reconstruction possible à partir de sources contrôlées | Condition de licence ou de transfert d’actifs |
Exigences proposées en matière de preuves de transaction.
| Dépendance | Preuve | Exposition principale | Traitement des transactions |
|---|---|---|---|
| Code employé | Conditions d'emploi et d'invention | Écart de propriété | Cession et garantie |
| Travaux d'entrepreneur | Énoncé des travaux et mission | Modification ou transfert restreint | Mission spécifique ou indemnité |
| Logiciel commercial | Conditions de licence et de support | Non-transfert, résiliation ou révision du prix | Novation, remplacement ou déduction |
| Logiciel open source | SBOM, licence et dossier de distribution | Conformité et maintenance | Plan de guérison et gouvernance continue |
| Interface client | Historique des contrats et des cotisations | Utilisation réservée au client existant | Consentement ou valeur conditionnelle |
Proposition de classification des dépendances juridiques et opérationnelles.
| Article | USD millions | Base de preuve | Traitement |
|---|---|---|---|
| Valeur globale de l'entreprise | 84 | Modèle commercial | Valeur de départ |
| Correction et transition | -9 | Plan de construction, de vulnérabilité et de séparation | Déduction de clôture |
| Droits et dépendances | -7 | Lacunes en matière de licence et de provenance | Déduction ou séquestre |
| Concentration et fragilité | -5 | Accès et examen par la personne clé | Réserve d'intégration |
| Acceptation du client | -4 | Preuve de consentement et d’interface | Contrepartie conditionnelle |
| Valeur de rachat à la clôture | 59 | Cadre global | Résultat illustratif |
Tout à fait hypothétique ; USD millions.
| Contrôle | Preuve avant transfert | Action de clôture | Vérification après clôture |
|---|---|---|---|
| Dépôts | Liste d'accès et branches protégées | Administrateurs de transfert | Réconcilier les accès et les journaux |
| Signature | Inventaire clé et chaîne d’approbation | Faire pivoter ou réinscrire les clés | Tester la version signée hors production |
| Accès à la production | Inventaire privilèges | Révoquer les comptes réservés aux vendeurs | Recertifier l’accès des personnes et des services |
| Fournisseurs | Calendrier du contrat et du consentement | Exécuter des novations | Confirmer les contacts d'assistance et d'incident |
| Récupération | Dernier exercice et inventaire de sauvegarde | Conserver les instantanés | Exécuter une restauration contrôlée |
Contrôles proposés ; le séquençage réel dépend des contraintes de la mission.
| Mesure | Preuve du jour 30 | Preuve du jour 60 | Preuve du jour 100 |
|---|---|---|---|
| Construire le contrôle | Environnement propre établi | Produits critiques reproduits | Preuves de mise en liberté de routine terminées |
| Accéder | Administrateurs recertifiés | Comptes de service attribués | Exceptions clôturées ou acceptées |
| Vulnérabilités | Retard critique validé | Des remèdes prioritaires testés | Niveaux de service durables opérationnels |
| Fournisseurs | Dépendances critiques confirmées | Les novations et les remplacements ont progressé | Plans de gouvernance et de sortie approuvés |
| Connaissance | Rôles clés conservés | Runbooks et couplage en cours | Couverture opérationnelle indépendante testée |
Jalons de preuves proposés.
| Trouver | Effet cash | Mécanicien contractuel | Preuve pour la libération |
|---|---|---|---|
| Dépendance non transférable | USD 7 million | Séquestre ou déduction de prix | Novation exécutée ou remplacement qualifié |
| Construire la fragilité | USD 4 million | Condition de fermeture | Construction propre et test réussis |
| Dépendance à la personne clé | USD 3 million | Retenue liée à la rétention | Jalons du transfert de connaissances |
| Droits spécifiques au client | USD 4 million | Earn-out | Consentement et encaissement conservé |
Des effets monétaires tout à fait hypothétiques ; USD millions.
| Zone de décision | Preuve verte | État ambre | État rouge |
|---|---|---|---|
| Contrôle des sources | Référentiels traçables complets | Lacunes mineures contrôlées | Source critique ou historique manquant |
| Construire | Libération contrôlée répétable | Étapes manuelles avec cure financée | La construction ne peut pas être reproduite |
| Droits | Droits documentés transférables | Consentement en attente avec protection | Droit matériel indisponible |
| Opérations | Couverture indépendante avec personnel | Concentration avec transition testée | Dépendance de personne nommée sans repli |
| Récupération | Restauration récente réussie | Portée partielle ou exercice âgé | Récupération non testée ou indisponible |
Seuils de décision proposés.
Sources
- Institut national des normes et de la technologie, SP 800-218 Secure Software Development Framework version 1.1, 2022. Lire la source principale
- Institut national des normes et technologies, SP 800-161 Revision 1 Pratiques de gestion des risques de la chaîne d'approvisionnement en cybersécurité pour les systèmes et les organisations, 2022. Lire la source principale
- Institut national des normes et de la technologie, Software Security in Supply Chains Guidance, mis à jour en 2024. Lire la source principale
- Institut national des normes et technologies, Cybersecurity Framework 2.0, 2024. Lire la source principale
- Institut national des normes et de la technologie, Segment sol du satellite NISTIR 8401 appliquant le cadre de cybersécurité au commandement et au contrôle des satellites, 2022. Lire la source principale
- National Institute of Standards and Technology, SP 800-53 Révision 5 Contrôles de sécurité et de confidentialité pour les systèmes d'information et les organisations. Lire la source principale
- Administration nationale de l'aéronautique et de l'espace, Manuel d'ingénierie et d'assurance logicielle de la NASA NASA-HDBK-2203. Lire la source principale
- Administration nationale de l'aéronautique et de l'espace, SWE-042 Accès électronique au code source. Lire la source principale
- Administration nationale de l'aéronautique et de l'espace, SWE-158, évalue les logiciels pour détecter les vulnérabilités de sécurité. Lire la source principale
- Administration nationale de l'aéronautique et de l'espace, entrées logicielles de génération automatique SWE-206. Lire la source principale
- Administration nationale de l'aéronautique et de l'espace, NPR 7150.2 Exigences en matière d'ingénierie logicielle de la NASA. Lire la source principale
- Administration nationale de l'aéronautique et de l'espace, norme d'assurance logicielle et de sécurité logicielle NASA-STD-8739.8. Lire la source principale
- Administration nationale de l'aéronautique et de l'espace, norme de protection du système spatial NASA-STD-1006A. Lire la source principale
- Administration nationale de l'aéronautique et de l'espace, Guide des meilleures pratiques en matière de sécurité spatiale. Lire la source principale
- Agence de cybersécurité et de sécurité des infrastructures, Sécuriser les pratiques recommandées de la chaîne d'approvisionnement logicielle pour les développeurs, 2023. Lire la source principale
- Agence de cybersécurité et de sécurité des infrastructures, nomenclature logicielle. Lire la source principale
- Agence de cybersécurité et de sécurité des infrastructures, Secure by Design. Lire la source principale
- Agence de cybersécurité et de sécurité des infrastructures, manuels de réponse aux incidents de cybersécurité et aux vulnérabilités du gouvernement fédéral. Lire la source principale
- Agence spatiale européenne, produits logiciels pour les opérations de mission. Lire la source principale
- Agence spatiale européenne, Capacités malveillantes de la chaîne d’approvisionnement et vulnérabilités logicielles de SPACE-SHIELD. Lire la source principale
- Agence de l’Union européenne pour la cybersécurité, ENISA Space Threat Landscape 2025. Lire la source principale
- Comité consultatif pour les systèmes de données spatiales, les opérations de mission et les services de gestion de l'information. Lire la source principale
- Comité consultatif pour les systèmes de données spatiales, publications du groupe de travail sur la sécurité. Lire la source principale
- Office of Space Commerce des États-Unis, Directive de politique spatiale 5 Principes de cybersécurité pour les systèmes spatiaux. Lire la source principale
- Centre national de cybersécurité du Royaume-Uni, Cyber Security Toolkit for Boards. Lire la source principale
- Projet mondial ouvert de sécurité des applications, norme de vérification des composants logiciels. Lire la source principale
- Projet mondial ouvert de sécurité des applications, modèle de maturité de l'assurance logicielle. Lire la source principale
- La Fondation Linux, échange de données du progiciel SPDX. Lire la source principale
- Organisation internationale de normalisation, Systèmes de gestion de la sécurité de l'information ISO IEC 27001. Lire la source principale
- Coopération européenne pour la normalisation spatiale, normes de génie logiciel ECSS. Lire la source principale
