Licences logicielles en contrats de défense : COTS, audits et DFARS

La conformité des licences logicielles est traitée comme une formalité d'achat dans la plupart des organisations. Dans le contrat de défense, c'est quelque chose de plus proche d'une obligation réglementaire, avec des conséquences financières, juridiques et de sécurité qui se cumulent sur chaque programme qu'un industriel exécute simultanément. Un seul accord d'entreprise mal appliqué entre un réseau classifié et un réseau non classifié, une bibliothèque sous licence GPL intégrée à un livrable sans divulgation des sources, ou une licence de serveur comptée par socket au lieu de par cœur peuvent chacun générer des demandes de régularisation à six ou sept chiffres de la part d'un éditeur menant un audit, une demande d'action corrective de la DCSA, ou une décision défavorable en matière de propriété intellectuelle qui réinitialise le niveau de droits d'un livrable.

La complexité est structurelle. Les industriels de la défense opèrent sur plusieurs domaines de sécurité, soutiennent des dizaines de programmes sous des contrats différents, et déploient des logiciels COTS dans des configurations — clusters virtualisés, enclaves cloud gouvernementales, systèmes de mission outre-mer — pour lesquelles les éditeurs de licences n'ont pas conçu leurs métriques de décompte pour les gérer proprement. Le cadre DFARS des droits logiciels ajoute une couche d'obligations propres au gouvernement au-dessus des conditions de licence commerciales standard. L'incorporation d'open source dans les livrables déclenche des exigences de divulgation que la plupart des équipes logicielles ne rencontrent que lorsqu'un responsable de la sécurité du programme les signale avant une livraison.

Cet article couvre l'ensemble du paysage technique et réglementaire : les motifs d'exposition aux licences propres aux programmes de défense, l'architecture d'inventaire COTS, les clauses DFARS sur les droits, la préparation des preuves d'audit, l'outillage de conformité open source, les méthodes d'optimisation des licences et les exigences de séquestre logiciel pour les systèmes critiques pour la mission.

Exposition aux licences logicielles dans les programmes de défense

Les industriels de la défense sous-estiment systématiquement l'exposition aux licences logicielles, car les budgets de programme tiennent compte du coût d'achat des licences mais rarement du coût de gestion de la conformité aux conditions auxquelles ces licences sont concédées. L'écart entre achat et conformité s'élargit à chaque programme qui réutilise un outil COTS sur un nouveau contrat sans vérifier si la licence existante autorise cet usage.

Motifs de sous-estimation du périmètre

Le motif de sous-estimation le plus fréquent concerne les métriques de licence par serveur et par processeur. Les éditeurs de logiciels d'entreprise sont passés du licenciement par serveur au licenciement par processeur puis par cœur au fil des générations de produits. Un industriel qui a acheté en 2018 une licence de base de données par serveur et qui a migré la charge de travail vers un nouveau serveur multi-sockets en 2024 peut aujourd'hui être non conforme sans avoir modifié le logiciel du tout — le changement de matériel a augmenté le nombre de processeurs, ce qui a modifié l'obligation de licence sous les règles modernes de décompte par facteur de cœur. Peu de chefs de programme suivent ce lien entre les cycles de renouvellement d'infrastructure et les changements de métriques de licence.

Le décompte des licences fondé sur les utilisateurs présente un motif de sous-estimation différent. Les licences par utilisateur nommé dans les environnements classifiés sont fréquemment surdéployées, car les titulaires d'habilitation tournent entre les programmes. Un utilisateur qui termine son travail sur le programme A et passe au programme B a toujours son compte actif dans les systèmes logiciels du programme A jusqu'à ce que quelqu'un le retire administrativement. Les outils SAM qui comptent les comptes utilisateurs actifs plutôt que les utilisateurs actifs authentifiés rapporteront plus de postes déployés qu'il n'en est réellement utilisé, ce qui gonfle l'écart de conformité apparent — mais les organisations qui ne comptent que les sessions simultanées peuvent se découvrir non conformes pendant les périodes de pic où les nombres d'utilisateurs s'envolent.

Licenciement cloud dans le cloud gouvernemental

Le licenciement dans les environnements GovCloud (enclaves IL4, IL5, IL6) introduit une catégorie d'exposition aux licences que la plupart des équipes d'achat sur site ne sont pas outillées pour gérer. Les licences COTS commerciales standard n'autorisent fréquemment pas un déploiement dans un environnement hébergé par un tiers sans avenant cloud. Les éditeurs qui détectent un déploiement dans un locataire cloud gouvernemental — par la télémétrie IP, les journaux d'utilisation fournis pendant un audit ou les rapports de revendeurs — traitent le déploiement comme une exigence de licence distincte du droit sur site. Les industriels de la défense qui ont migré des charges de travail sur site vers des environnements cloud IL5 avec des licences perpétuelles existantes sans vérifier les droits de déploiement cloud portent une exposition de conformité non divulguée sur chaque programme affecté.

Pour une vision plus large de la façon dont les contrôles de la chaîne d'approvisionnement logicielle interagissent avec le licenciement, consultez notre analyse des pipelines de défense à application des SBOM, qui couvre les exigences de transparence des composants en aval qui découlent de la même posture de conformité.

Gestion de l'inventaire des licences COTS

Un inventaire des licences COTS est le fondement de tout programme de conformité logicielle. Il comporte deux composants qui doivent être maintenus en synchronisation : la base de données des droits (les licences que l'industriel a achetées) et la base de données des déploiements (le logiciel réellement installé et utilisé). L'écart de conformité est la différence entre les deux. Gérer cet écart exige à la fois des données exactes et un processus de résolution des écarts.

Choix de l'outil SAM pour les environnements de défense

Les outils de gestion des actifs logiciels doivent satisfaire à des exigences qui éliminent de la réflexion la plupart des produits grand public ou uniquement SaaS. Pour les réseaux classifiés, l'outil SAM doit :

• Fonctionner entièrement sur site, sans télémétrie de rappel vers des points de terminaison externes
• Prendre en charge la découverte par agents sur les points de terminaison Windows et Linux sans exiger d'accès Internet pour les mises à jour des agents
• Produire un inventaire découvrable dans des formats exportables (CSV, SPDX ou XML) sans intermédiaires cloud
• Maintenir des instances de découverte distinctes pour chaque domaine de sécurité (non classifié, CUI, classifié) sans fuite de données entre domaines
• Normaliser les noms et versions de produits par rapport à une bibliothèque de licences hors ligne mise à jour par des supports contrôlés

Les outils qui répondent à ces exigences incluent généralement des déploiements sur site de plateformes SAM d'entreprise. La capacité de normalisation par la bibliothèque de licences est particulièrement importante : la sortie brute de découverte liste des centaines de variantes de produits et de chaînes de version qui doivent être résolues en identités de produits canoniques avant que la comparaison des droits ait un sens.

Découverte automatisée face à inventaire manuel

La découverte automatisée est plus exacte et plus cohérente que l'inventaire manuel pour les logiciels de points de terminaison, mais elle a des angles morts dans les environnements de défense : les logiciels installés sur des systèmes non connectés au réseau (postes de travail classifiés autonomes, systèmes déployés, équipements de banc d'essai), les logiciels embarqués dans le firmware ou livrés dans le cadre d'une intégration de plateforme, et les logiciels qui ne s'exécutent que pendant des phases de mission précises et ne sont pas actifs quand les balayages de découverte tournent. L'inventaire manuel complète la découverte automatisée pour ces catégories, en s'appuyant sur des procédures d'inspection documentées et des relevés physiques périodiques des systèmes non connectés.

Architecture de la base de données des droits de licence

La base de données des droits doit stocker, pour chaque enregistrement de licence :

• Nom et version du produit (normalisés sous la forme canonique de l'éditeur)
• Métrique de licence (par poste, par cœur, par serveur, simultanée, unité d'abonnement)
• Quantité de droits et unité de mesure correspondant à la métrique
• Justificatifs de droits : numéro de bon de commande, numéro de facture, numéro de série du certificat de licence, référence d'annexe ELA
• Programme et contrat que la licence soutient (pour l'affectation des coûts et la traçabilité d'audit)
• Restrictions de périmètre de déploiement (sur site uniquement, avenant cloud inclus, réseau classifié autorisé)
• Date de renouvellement ou statut perpétuel
• Tout avenant d'usage gouvernemental ou conditions d'avenant fédéral particulières

La requête de réconciliation qui produit le rapport d'écart de conformité doit joindre la base de données des droits à la base de données de découverte sur l'identité de produit normalisée et additionner les déploiements par rapport aux droits par unité de métrique. Les écarts où les déploiements dépassent les droits exigent un triage immédiat : confirmez que le nombre de déploiements est exact, puis achetez des droits supplémentaires ou retirez les installations non autorisées.

Clauses DFARS sur les droits logiciels

La partie 227 des DFARS établit le cadre dans lequel le gouvernement des États-Unis acquiert des droits sur les logiciels développés au titre de contrats de défense ou utilisés pour leur exécution. Pour les industriels de la défense, les clauses applicables diffèrent selon que le logiciel est commercial (régi par DFARS 227.7202) ou non commercial (régi par DFARS 227.7103 et la clause contractuelle associée DFARS 252.227-7014).

DFARS 252.227-7014 : droits sur les logiciels non commerciaux

DFARS 252.227-7014 s'applique aux logiciels développés spécifiquement au titre d'un contrat de défense avec un financement gouvernemental, en tout ou en partie. La clause établit quatre niveaux de droits standard :

• Droits illimités : Le gouvernement peut utiliser, reproduire, modifier, diffuser ou divulguer le logiciel sans restriction. S'applique aux logiciels développés entièrement à la charge du gouvernement.
• Droits à usage gouvernemental (GPR) : Un niveau transitoire pour les logiciels développés avec un financement mixte. Le gouvernement peut utiliser le logiciel à toute fin gouvernementale mais ne peut pas le diffuser à des parties commerciales pendant la période GPR (généralement cinq ans). À l'expiration de la période GPR, les droits deviennent illimités.
• Droits limités : S'applique aux logiciels développés entièrement à frais privés. Le gouvernement ne peut utiliser le logiciel qu'à des fins internes au gouvernement et ne peut pas le diffuser à des tiers sans le consentement de l'industriel.
• Droits de licence spécifiquement négociés : Tout arrangement de droits qui sort des niveaux standard, consigné dans un avenant de licence propre au contrat. Utilisé pour les situations hybrides que les niveaux standard ne résolvent pas proprement.

La détermination du financement — développement à la charge du gouvernement, à frais privés ou mixte — est l'aspect le plus contesté des revendications de droits. Les industriels doivent tenir des enregistrements de financement détaillés pour chaque composant logiciel au moment du développement pour étayer leurs revendications de droits lors d'une revue des droits sur les données techniques.

Transmission des licences de logiciels commerciaux

Pour les logiciels COTS, DFARS 227.7202-1 impose au gouvernement de n'acquérir que les droits prévus par l'accord de licence commerciale standard de l'éditeur, sous réserve que ces conditions soient compatibles avec le droit fédéral et non autrement prohibées. Cela signifie que l'accord de licence de l'éditeur COTS est transmis au client gouvernemental sans modification par le cadre des droits DFARS — le gouvernement ne peut pas invoquer les dispositions de droits illimités contre un éditeur COTS dont les conditions standard restreignent l'usage gouvernemental.

Pour les donneurs d'ordre principaux, cela crée une obligation de transmission en aval : lorsque des logiciels COTS sont incorporés dans un système livrable, le donneur d'ordre doit identifier les composants COTS, joindre ou référencer leurs conditions de licence commerciales, et veiller à ce que le gouvernement comprenne qu'il reçoit les conditions de l'éditeur, et non un droit découlant des droits DFARS. Ne pas identifier les composants COTS ni revendiquer leur statut de licence commerciale pendant l'exécution du contrat peut amener le gouvernement à revendiquer plus tard des droits illimités sur la base du défaut DFARS — un litige coûteux à plaider.

Comprendre comment les droits logiciels interagissent avec le cadre plus large du guide complet de l'achat de défense aide les industriels à structurer leur stratégie de propriété intellectuelle avant l'attribution du contrat, quand le levier de négociation est le plus élevé.

Préparation aux audits d'éditeurs et de la DCSA

Un audit de licences logicielles peut être engagé par un éditeur commercial exerçant ses droits d'audit au titre d'un accord de licence d'entreprise, ou par la DCSA dans le cadre d'un examen d'habilitation d'installation qui inclut l'évaluation des contrôles de sécurité de l'information. Les deux types d'audit diffèrent par leur périmètre et leur autorité, mais exigent tous deux le même dossier de preuves fondamental.

Préparation du dossier de preuves d'audit

Le dossier de preuves d'audit doit être préparé en amont et maintenu dans un état où il peut être produit dans le délai de préavis spécifié dans l'accord de licence — fréquemment 30 jours, parfois aussi court que 10 jours ouvrables. Le dossier doit inclure :

• Certificats de droits de licence pour tous les produits couverts par le périmètre d'audit
• Bons de commande et factures renvoyant à chaque produit et version, couvrant tous les achats de licences pour la période rétroactive que l'auditeur spécifie (généralement de trois à cinq ans)
• Annexes d'accord de licence d'entreprise (ELA) avec dates d'effet, listes de produits couverts et nombres d'utilisateurs autorisés
• Rapports de découverte de l'outil SAM datés de moins de 30 jours de la demande d'audit, montrant les versions de produits déployées et les quantités
• Feuille de réconciliation associant droits détenus et déploiements pour chaque produit du périmètre
• Avenants d'usage gouvernemental ou suppléments fédéraux qui modifient les conditions commerciales standard
• Registres de déclassement pour les logiciels retirés du service pendant la période d'audit

Méthodologie de réconciliation des licences

La méthodologie de réconciliation utilisée pour préparer les preuves d'audit doit être cohérente et documentable. Pour les licences par poste, la méthodologie doit utiliser des décomptes d'utilisateurs actifs authentifiés sur une période de mesure définie (généralement la période d'usage de pointe de 90 jours précédant l'audit), et non un instantané à une date unique. Pour les licences par cœur, la méthodologie doit documenter le nombre de cœurs physiques de chaque serveur ou cluster de machines virtuelles exécutant le logiciel, en appliquant le tableau de facteur de cœur publié par l'éditeur lorsqu'il s'applique. Pour les licences par abonnement, la méthodologie doit tenir compte de la période d'usage actif, et non du seul instantané actuel, car les régularisations rétroactives s'appliquent à l'usage historique qui a dépassé les nombres de droits pendant la durée de l'abonnement.

Constats d'audit fréquents dans les environnements de défense

Les audits des industriels de la défense révèlent de manière constante un ensemble de constats récurrents qu'un programme de conformité bien conçu élimine de façon proactive :

• Installations sans licence : Logiciel découvert sur des points de terminaison sans enregistrement de droits correspondant — typiquement installé par des utilisateurs individuels pour leur commodité sans approbation d'achat.
• Application erronée de la métrique de licence : Licences par utilisateur utilisées dans des environnements par processeur, ou licences simultanées comptées comme s'il s'agissait de licences par utilisateur nommé.
• Lacunes de mise à jour de version : Logiciel mis à jour vers une nouvelle version majeure sans achat de droits de mise à jour au titre d'un accord de maintenance arrivé à expiration.
• Déploiement cloud sans avenant cloud : Licences sur site appliquées à des déploiements cloud gouvernementaux alors que les conditions de l'éditeur exigent un droit d'usage cloud distinct.
• Justificatifs de droits manquants : Licences achetées et installées il y a des années sans conservation du certificat de licence ou du bon de commande, laissant l'industriel incapable de prouver ses droits.

La dimension chaîne d'approvisionnement de la conformité des licences logicielles se relie directement aux contrôles plus larges de gestion des risques de la chaîne d'approvisionnement en défense que les programmes de défense doivent mettre en œuvre — un logiciel non autorisé est à la fois un manquement à la conformité et un risque de sécurité.

Conformité des licences open source

Le logiciel open source (OSS) incorporé dans les livrables de défense crée des obligations de conformité d'une nature différente des obligations de licence COTS. La non-conformité COTS crée une responsabilité financière envers l'éditeur. La non-conformité OSS — en particulier la violation des conditions de licence copyleft — peut créer une obligation de divulguer le code source propriétaire à tout destinataire du logiciel, y compris le gouvernement, qui peut alors être dans l'impossibilité de restreindre la divulgation ultérieure.

Risque de copyleft GPL/LGPL dans les livrables de défense

Les licences GPL version 2 et GPL version 3 imposent une exigence de copyleft : toute œuvre dérivée ou œuvre combinée distribuée à un tiers doit être concédée sous les mêmes conditions GPL et accompagnée (ou assortie d'une offre de fourniture) du code source correspondant complet. Pour un industriel de la défense livrant un système logiciel au gouvernement, la livraison est un événement de distribution qui déclenche l'obligation de divulgation GPL pour tout composant sous licence GPL incorporé dans le livrable.

Le risque pratique n'est pas la divulgation de code utilitaire anodin — c'est la divulgation d'implémentations algorithmiques propriétaires qui se trouvent être liées statiquement à une bibliothèque GPL. Si un module d'algorithme de ciblage d'un industriel est compilé dans le même binaire qu'une bibliothèque de traitement de données sous licence GPL, les dispositions de copyleft de la GPL peuvent exiger la divulgation de toute l'œuvre combinée, y compris l'algorithme de ciblage, lorsque le binaire est livré. Que ce résultat soit exigé dépend de la version précise de la GPL, de la méthode d'intégration (liaison statique face à dynamique) et des faits d'usage du composant GPL — mais le risque doit être évalué avant la livraison, et non découvert lors d'une revue de sécurité ultérieure.

La LGPL (Lesser GPL) applique une règle de copyleft plus souple qui permet à un logiciel propriétaire de lier dynamiquement une bibliothèque LGPL sans déclencher le copyleft sur le code propriétaire. La liaison statique à une bibliothèque LGPL comporte néanmoins un risque. La frontière entre l'usage sûr par liaison dynamique et l'incorporation statique à risque doit être évaluée au niveau de la configuration de build, et non au niveau du code source.

Intégration de l'analyseur de licences

Les analyseurs de licences — FOSSA, Black Duck (Synopsys), SCANOSS et outils sur site comparables — automatisent l'identification OSS et la détection des licences sur les dépôts de code, les artefacts de build et les images de conteneurs. L'intégration au pipeline CI/CD applique la politique de licences au point où l'OSS est introduit : lorsqu'un développeur ajoute une nouvelle dépendance, l'analyseur identifie la licence, la vérifie par rapport à la politique de licences approuvée et bloque le build si la licence est classée à risque élevé sans exception documentée.

Pour les dépôts classifiés, l'analyseur doit fonctionner en mode isolé (air-gapped) contre une base de données de composants maintenue localement — les API de recherche de licences dans le cloud ne sont pas disponibles sur les réseaux classifiés. La base locale doit être mise à jour selon un cycle de maintenance contrôlé et horodatée par version, afin que les résultats d'analyse soient reproductibles et auditables. La sortie de l'analyseur pour chaque livraison doit être archivée dans la ligne de base technique du programme, car les obligations de divulgation OSS sont évaluées par rapport aux composants inclus dans chaque livraison précise, et non par rapport à l'état actuel du codebase.

Obligations de divulgation OSS

Lorsqu'un contrat de défense exige la livraison d'un SBOM (Software Bill of Materials, nomenclature logicielle), l'inventaire OSS produit par l'analyseur de licences alimente directement la sortie SBOM. Le format d'éléments minimaux NTIA et la spécification SPDX exigent tous deux une identification des licences au niveau du composant que l'analyseur fournit. Mais le SBOM est un document de divulgation, et non un certificat de conformité — l'industriel doit en outre veiller à ce que toutes les obligations de divulgation de copyleft soient satisfaites, dans une étape distincte de la production du SBOM. Produire un SBOM exact qui liste un composant GPL sans divulguer les sources satisfait l'exigence de transparence, mais pas l'obligation de licence.

Stratégies d'optimisation des licences

La conformité des licences est le plancher. L'optimisation des licences est le plafond — l'effort systématique pour réduire les coûts de licence en éliminant le gaspillage, en réaffectant les droits plus efficacement et en substituant des alternatives moins coûteuses là où les exigences techniques le permettent. Dans les environnements de contrat de défense, avec des programmes importants de longue durée et des cycles d'achat lents, des économies significatives s'accumulent grâce à une optimisation qui n'apparaîtrait jamais dans une vue à un seul programme.

Récupération des licences inutilisées

La récupération de licences est le processus de reprise des licences attribuées à des utilisateurs ou des systèmes qui ne sont plus des consommateurs actifs. Les outils SAM qui suivent la fréquence d'utilisation — et non le seul nombre d'installations — identifient les licences attribuées mais non utilisées sur une période définie (généralement 60 à 90 jours). Ces licences sont candidates à la récupération et à la réaffectation à des utilisateurs actifs qui en ont besoin. Dans les grands environnements d'industriels de la défense, les campagnes de récupération restituent de manière constante 15 à 25 pour cent des licences par poste déployées dans les catégories d'outils de productivité et d'ingénierie d'entreprise, ce qui représente une économie de coût substantielle au renouvellement.

Implications de licence de la virtualisation

La virtualisation crée simultanément des opportunités et des risques d'optimisation des licences. L'opportunité : consolider les serveurs physiques réduit le nombre de cœurs physiques sur lequel les licences par cœur doivent être appliquées, ce qui peut réduire l'obligation de licence. Le risque : les fonctions de migration de machines virtuelles (migration à chaud, clustering haute disponibilité) peuvent faire migrer une VM exécutant un logiciel licencié vers un hôte avec plus de cœurs physiques, augmentant l'obligation de licence sans intervention humaine. Gérer ce risque exige soit de configurer des politiques de migration des VM pour restreindre les mouvements à des pools d'hôtes déjà licenciés, soit d'acheter suffisamment de licences pour couvrir l'ensemble du domaine de migration — une approche que les éditeurs préfèrent parce qu'elle supprime la charge de gestion des politiques de migration.

Analyse de substitution hybride commerciale/open source

Pour les catégories d'outillage non classifiées et non critiques pour la mission — environnements de développement, outils de documentation, systèmes de suivi de projets, plateformes d'analyse de données — les alternatives open source aux produits commerciaux satisfont fréquemment les exigences fonctionnelles à un coût nettement inférieur. Une analyse de substitution compare le coût total de possession de la licence COTS actuelle (redevances de licence, coûts de support, coûts de formation, coûts d'intégration) au coût total de possession d'une alternative OSS (coût d'implémentation, contrat de support si nécessaire, formation, intégration). L'analyse doit aussi évaluer les conditions de licence de l'alternative OSS pour confirmer que la substitution n'introduit pas une nouvelle obligation de conformité de copyleft.

Les décisions de substitution dans les environnements de défense exigent une évaluation de sécurité supplémentaire : les produits OSS utilisés dans des environnements classifiés doivent être approuvés pour l'usage sur des systèmes classifiés via le processus d'accréditation approprié, ce qui ajoute du délai et du coût au projet de substitution que la seule comparaison des coûts de licence ne capte pas.

Séquestre logiciel et continuité

Le séquestre logiciel est un mécanisme de continuité qui protège la capacité du gouvernement — et de l'entrepreneur — à maintenir et à modifier un logiciel sur mesure si le développeur d'origine n'est plus en mesure de le prendre en charge. Pour les programmes de défense à longue durée de vie opérationnelle (15 à 30 ans pour de nombreux programmes de plateformes), la probabilité que le développeur logiciel d'origine reste disponible et accepte de prendre en charge le logiciel pendant toute la durée du programme n'est pas élevée. Le séquestre traite ce risque en garantissant l'accès au code source et aux éléments de compilation lorsque des événements déclencheurs définis se produisent.

Exigences de séquestre pour les logiciels de défense sur mesure

Les contrats de défense pour les logiciels sur mesure critiques pour la mission incluent de plus en plus des clauses de séquestre qui précisent :

• L'agent de séquestre (un fournisseur de services de séquestre commercial désigné, et non un organisme gouvernemental)
• Le calendrier des dépôts — en général à l'attribution du contrat pour le dépôt initial, puis mis à jour à chaque jalon de version majeure et annuellement par la suite
• Les exigences de contenu du dépôt : code source de tous les composants sur mesure, scripts de compilation, spécifications des dépendances tierces, documentation de l'environnement de compilation (versions des compilateurs, versions des outils de compilation, fichiers de configuration)
• Les exigences de tests de vérification — le droit du bénéficiaire de tester le dépôt pour confirmer qu'il est complet et compilable
• Événements déclencheurs de libération du séquestre : insolvabilité du fournisseur, cessation de la prise en charge du logiciel, manquement substantiel à l'accord de maintenance, ou défaillance de l'entrepreneur

Tests de vérification des dépôts de séquestre

Un dépôt de séquestre qui n'a jamais été testé est un document juridique, et non un actif utilisable. Les tests de vérification confirment que les éléments déposés sont complets et suffisants pour reconstruire le logiciel sans référence aux systèmes internes du développeur. Un test de vérification pertinent reconstruit l'environnement de compilation à partir des spécifications déposées, installe les dépendances déposées, exécute les scripts de compilation sur le code source déposé et lance une suite de tests fonctionnels sur l'artefact de compilation résultant. Toute lacune du dépôt — une dépendance manquante, une version d'outil de compilation non documentée, un chemin codé en dur vers un système interne du développeur — apparaît lors des tests de vérification et peut être corrigée par un dépôt supplémentaire avant que le séquestre ne soit nécessaire dans un scénario de continuité réel.

Événements déclencheurs de libération du séquestre

La libération du séquestre est régie par les définitions des événements déclencheurs dans l'accord de séquestre et doit être engagée par une procédure de demande formelle. Les événements déclencheurs les plus courants dans les accords de séquestre de logiciels de défense sont l'insolvabilité du fournisseur (dépôt de bilan ou nomination d'un administrateur), le rachat du fournisseur par un concurrent qui abandonne le produit, la cessation du support de maintenance, et le manquement substantiel à l'accord de maintenance logicielle qui reste non corrigé après la période de notification et de remise en état. La procédure de demande de libération comprend en général une notification écrite à l'agent de séquestre identifiant l'événement déclencheur, une période d'attente pendant laquelle le développeur peut contester la libération, et une décision neutre si la libération est contestée. Les entrepreneurs doivent examiner leurs accords de séquestre pour confirmer que les définitions des événements déclencheurs sont suffisamment précises pour être invoquées sans litige — des définitions vagues créent une ambiguïté qui ralentit l'accès aux éléments déposés précisément lorsque la rapidité compte le plus.