SolarWinds Orion et la compromission du système de build qui a transformé une mise à jour de confiance en risque public

Synthèse

• La campagne Orion a réussi parce que les attaquants ont compromis un processus de production logicielle, inséré SUNBURST lors des builds automatisés, et permis au mécanisme normal de signature et de distribution de SolarWinds de livrer le composant modifié. Une signature valide a authentifié le processus de publication compromis; elle n'a pas établi de manière indépendante que le code résultant correspondait à un état source approuvé.
• Moins de 18 000 clients ont pu obtenir des versions affectées, mais ce chiffre ne correspond pas au nombre d'organisations compromises lors des opérations de suivi. Des estimations publiques ultérieures ont situé les compromissions avérées ou évaluées à neuf agences fédérales américaines et à moins de cent organisations non gouvernementales, tandis que SolarWinds estimait séparément à moins de cent le nombre de clients piratés via SUNBURST.
• Le Service de renseignement extérieur russe (SVR) porte la responsabilité de l'opération d'espionnage. SolarWinds contrôlait néanmoins l'environnement de build, la provenance des versions, le chemin de signature et l'architecture produit qui ont transformé une compromission interne en code de confiance chez les clients. Les clients et les acheteurs gouvernementaux contrôlaient la segmentation, la journalisation, le durcissement des identités, les achats et la récupération. La responsabilité incombe à chaque partie pour les mesures de protection qu'elle pouvait effectivement mettre en œuvre.
• Le dossier juridique est plus étroit que le dossier opérationnel. La SEC a poursuivi SolarWinds et son responsable de la sécurité des systèmes d'information en 2023, un tribunal fédéral a rejeté la plupart des accusations en 2024, et la SEC a abandonné l'action restante avec préjudice en novembre 2025. Cette histoire ne prouve pas les allégations initiales de la SEC, pas plus qu'elle n'établit que chaque décision de sécurité des builds était adéquate; elle montre pourquoi la prévention technique, la loi sur la divulgation et la responsabilité juridique finale doivent être analysées séparément.

La mise à jour a fait exactement ce que l'infrastructure de confiance lui demandait

L'incident SolarWinds est souvent décrit comme une mise à jour logicielle empoisonnée. Cette expression décrit la méthode de livraison, mais elle peut faire paraître l'échec comme un simple logiciel malveillant caché dans un installateur. Le fait le plus important est que la mise à jour affectée a été produite et livrée par le mécanisme de publication légitime du fournisseur. Les administrateurs n'ont pas eu à désactiver la vérification des signatures, à visiter un site de téléchargement contrefait ou à accepter un exécutable non signé. Le composant hostile a été inclus dans un paquet Orion de SolarWinds et signé numériquement.

Cette différence modifie l'analyse de la responsabilité. La signature logicielle est généralement comprise comme un contrôle sur l'origine et l'intégrité en transit. Si un paquet change après signature, la vérification de signature devrait échouer. Mais la signature ne prouve pas, en soi, que la source sélectionnée pour la compilation était autorisée, que le compilateur a fonctionné dans un environnement propre, qu'un worker de build n'avait pas été modifié, ou que l'artefact correspond au code approuvé par les réviseurs. Lorsqu'un attaquant agit avant l'application de la signature, la signature peut fidèlement garantir une sortie déjà compromise.

Ladivulgation technique originale de SUNBURST par Mandianta documenté un plug-in Orion signé par SolarWinds contenant une porte dérobée. Le composant pouvait attendre jusqu'à environ deux semaines, profiler son environnement, communiquer par le biais de modèles DNS et HTTP conçus pour ressembler au trafic légitime d'Orion, et récupérer des commandes uniquement après que l'attaquant ait sélectionné une victime. L'implant initial était conçu pour être discret, sélectif et compatible avec le produit hôte. Son objectif n'était pas de casser chaque installation à la fois. Son objectif était de placer une option crédible dans de nombreux réseaux et de n'exercer qu'un petit sous-ensemble.

C'est pourquoi l'événement appartient à un registre de dépendance cloud et de continuité publique même si Orion était généralement installé sur site. Orion surveillait et gérait l'infrastructure sur les environnements sur site, cloud et hybrides. Les activités de suivi pouvaient atteindre l'identité fédérée et les ressources Microsoft 365. La relation de confiance fonctionnait comme une dépendance de service: les clients comptaient sur un produit fournisseur maintenu en continu, acceptaient les mises à jour produites par le fournisseur et plaçaient le logiciel là où il pouvait observer ou administrer des systèmes critiques. L'emplacement de l'exécutable n'éliminait pas la dépendance à l'usine logicielle distante qui le produisait.

Le principal préjudice public n'était pas non plus une panne conventionnelle. Les systèmes de messagerie et opérationnels fédéraux ne se sont pas tous arrêtés de fonctionner un jour visible. La compromission a plutôt endommagé la confidentialité, l'assurance d'identité, la confiance probatoire et la capacité de savoir quelles communications ou décisions avaient été observées. La continuité du secteur public inclut la capacité de mener les activités gouvernementales sur des systèmes dont la confiance peut être défendue. Un réseau peut rester disponible tandis que la fonction publique qu'il soutient devient stratégiquement exposée.

Ce que le dossier public établit

Le compte rendu le plus solide provient de sources ayant des motivations institutionnelles différentes: les divulgations d'incident et les dépôts réglementaires de SolarWinds; les analyses techniques de CrowdStrike et Mandiant; les archives de la CISA, de la NSA, du FBI et des agences affectées; l'examen de la réponse fédérale par le GAO; les témoignages au Congrès; et le dossier judiciaire ultérieur. Ils ne répondent pas à toutes les questions, mais établissent plusieurs faits essentiels.

Premièrement, un acteur avancé a maintenu l'accès à l'environnement de SolarWinds suffisamment longtemps pour étudier le processus de production d'Orion. Lamise à jour d'enquête de SolarWinds de mai 2021indique que l'entreprise n'a pas pu déterminer précisément quand ni comment l'entrée initiale a eu lieu. Elle fait état de preuves d'informations d'identification compromises et d'un accès persistant à son environnement de développement logiciel et à ses systèmes internes, y compris Microsoft 365, pendant au moins neuf mois avant un essai en octobre 2019. L'entreprise a réduit les voies d'entrée possibles à une faille zero-day tierce, une attaque par force brute telle que le password spraying ou l'ingénierie sociale, mais n'a pas prétendu en avoir prouvé une.

Deuxièmement, la modification hostile a été effectuée dans l'environnement de build automatisé, et non commitée en tant que modification durable dans le dépôt source d'Orion. Ce n'est pas une technicité disculpatoire. Cela identifie la frontière de confiance qui a échoué. Un réviseur comparant le dépôt avant et après un build pouvait voir du code source propre tandis que le worker de build substituait temporairement un fichier malveillant pendant la compilation. Les contrôles centrés uniquement sur la revue de code manqueraient donc la divergence de l'artefact produit.

Troisièmement, les attaquants ont testé leur capacité à modifier des builds avant de déployer la porte dérobée opérationnelle. Lespremières conclusions sur le système de build de janvier 2021de SolarWinds situaient la première activité interne suspecte connue à l'époque en septembre 2019, une modification test dans une version d'Orion en octobre 2019, l'injection de SUNBURST à partir du 20 février 2020 et le retrait du code malveillant de l'environnement en juin 2020. Des rapports ultérieurs de l'entreprise ont repoussé les preuves d'accès tout en conservant la fenêtre de test d'octobre et de distribution de mars à juin.

Quatrièmement, les versions Orion affectées ont été distribuées par les canaux normaux. Leformulaire 8-K du 14 décembre 2020de SolarWinds indiquait que les produits téléchargés, implémentés ou mis à jour pendant la période concernée contenaient la vulnérabilité et estimait que moins de 18 000 clients pouvaient avoir installé des versions affectées. Sonformulaire 10-K de 2020décrivait plus tard SUNBURST comme injecté dans des builds publiés de mars à juin 2020, indiquait que le logiciel affecté était installé sur site et soulignait que le nombre exploité était nettement inférieur au nombre de clients ayant pu installer une version affectée.

Cinquièmement, FireEye a découvert la campagne plus large en décembre 2020 en enquêtant sur sa propre intrusion. Le dossier public ne montre pas que l'assurance de publication de SolarWinds ou un programme fédéral de périmètre ait détecté le build compromis avant que les clients ne le reçoivent. Ce manque de détection importe indépendamment de la qualité de la réponse de SolarWinds après notification. Un contrôle peut bien fonctionner pendant la réponse à la crise tout en ayant échoué à faire apparaître la condition dangereuse pendant la production.

Sixièmement, le gouvernement américain a ultérieurement attribué formellement la campagne au SVR russe. L'avis conjoint d'avril 2021 de la CISAenregistre l'attribution américaine et les directives correspondantes de la NSA, de la CISA et du FBI; le Royaume-Uni a également publiquement associé le SVR à l'opération. L'attribution établit la responsabilité de l'acteur hostile et le contexte géopolitique. Elle ne détermine pas si les mesures de protection du vendeur ou du client étaient proportionnées à une classe prévisible d'attaque de la chaîne d'approvisionnement.

Trois questions importantes restent limitées. La voie d'entrée initiale chez SolarWinds n'a pas été prouvée dans la mise à jour finale de l'entreprise citée. Le dossier public ne révèle pas toutes les organisations sélectionnées pour un accès de suivi ni tous les éléments pris sur ces réseaux. Et une mise à jour affectée ne prouve pas qu'une organisation a subi une exploitation interactive. Ces lacunes exigent un langage prudent, pas une paralysie analytique.

De la reconnaissance à une porte dérobée signée

La campagne a été patiente car sa cible n'était pas seulement un serveur. C'était un processus industriel reproductible.

L'acteur a d'abord eu besoin d'accès et de compréhension. Les environnements de build contiennent des compilateurs, des magasins de dépendances, des informations d'identification, des outils d'orchestration, des interfaces de signature, des scripts de publication et de nombreux fichiers intermédiaires. Leur complexité crée des opportunités, mais une altération indiscriminée crée du bruit. Une compilation échouée, une discordance de reproductibilité, un diff de source inattendu ou un paquet mal formé pourraient alerter les ingénieurs. L'attaquant a donc dû apprendre quand les builds d'Orion s'exécutaient, quel fichier source pouvait porter l'implant, comment ce fichier atteignait le plug-in final, et comment éviter de déstabiliser le produit.

Le test d'octobre 2019 était un avertissement critique rétrospectivement. Il a montré que l'acteur validait le chemin d'injection avant d'engager la charge utile opérationnelle. Dans une conception de production sûre, une modification de test qui n'existe que pendant le build devrait encore être détectée par la comparaison d'artefacts, la surveillance isolée du builder, les contrôles de provenance ou les contrôles de publication déterministes. Le fait que le test soit passé dans une version sans exposer l'intrus a démontré que la sortie du build pouvait diverger de la source attendue et continuer.

L'analyse SUNSPOT de CrowdStrikeexplique le mécanisme. SUNSPOT surveillaitMsBuild.exe, inspectait les informations de ligne de commande pour reconnaître la solution Orion, et remplaçaitInventoryManager.cspar une variante malveillante pendant la construction du produit. Il conservait le fichier d'origine afin de pouvoir le restaurer ensuite. Il incluait des sécurités visant à éviter les échecs de build et des comportements opérationnels conçus pour permettre à l'intrus de s'arrêter proprement plutôt que de laisser une compilation manifestement cassée. La conception traitait la suspicion du développeur comme le principal danger.

Le code malveillant résultant est devenu SUNBURST à l'intérieur deSolarWinds.Orion.Core.BusinessLayer.dll. Comme la substitution a eu lieu pendant le build, le paquet final a pu passer par les étapes ultérieures de packaging et de signature comme une sortie produit ordinaire. La signature était réelle. La revendication de provenance qui la sous-tendait était incomplète.

Une fois installé, SUNBURST retardait l'exécution et vérifiait les conditions environnementales pouvant indiquer une analyse. Il générait des requêtes DNS spécifiques à la victime et permettait à l'opérateur de décider quelles balises passeraient à un commandement et contrôle plus actif. L'analyse technique complémentaire de Mandianta décrit les contrôles anti-analyse, le comportement de génération de domaines, les modes de commande et les efforts pour fondre l'état dans la configuration légitime d'Orion. La sélectivité réduisait la probabilité que 18 000 installations potentielles produisent 18 000 incidents visibles.

Pour les victimes choisies, la porte dérobée pouvait devenir un point d'entrée pour des charges utiles distinctes, le vol d'informations d'identification, le déplacement latéral et l'accès au cloud. Cette distinction entre un implant distribué et une organisation exploitée est essentielle. Une organisation qui a téléchargé un paquet affecté, une qui l'a installé sur un serveur isolé, une dont le serveur a balisé et une dont les identités ont été utilisées pour un accès de suivi occupent des catégories d'impact différentes. Les réduire à un seul chiffre produit un nombre spectaculaire mais un mauvais modèle d'incident.

Les attaquants ont supprimé SUNBURST de l'environnement de build de SolarWinds en juin 2020, des mois avant la découverte. Cet acte a limité la distribution future et supprimé les preuves en direct évidentes du système de production. Les clients ayant déjà installé des versions affectées conservaient l'implant. L'opération a donc survécu à la présence de l'acteur dans l'usine logicielle: une compromission de production a été convertie en milliers d'artefacts déployés indépendamment, chacun suivant le calendrier de maintenance et de conservation du client.

Pourquoi la revue de code et la signature de code n'ont pas suffi

L'incident Orion a révélé un écart entre des contrôles d'intégrité logicielle souvent traités comme interchangeables.

La revue de code demande si le code livré pour une version est acceptable. L'intégrité de build demande si l'artefact compilé a effectivement été produit à partir de cette source approuvée, de dépendances approuvées, d'outils approuvés et d'instructions approuvées dans un environnement non compromis. La signature demande si une clé particulière a autorisé l'artefact. L'intégrité de distribution demande si les clients ont reçu l'artefact qui a été signé. Les contrôles d'exécution demandent ce que l'artefact est autorisé à faire après l'installation. Chaque contrôle peut réussir tandis qu'un autre échoue.

Dans Orion, les preuves publiques indiquent que le dépôt de code source persistant ne portait pas la modification SUNBURST. La revue de code ne pouvait donc pas prouver que l'artefact était propre. Le système de build a incorporé la source non autorisée de manière transitoire. La signature a ensuite attaché l'autorité organisationnelle à la sortie. La distribution a livré cette sortie sans qu'un tiers ne la modifie. Ces contrôles en aval ont fait leur travail étroit, mais la décision de publication reposait sur un fait amont brisé.

C'est la version chaîne d'approvisionnement d'une déclaration véridique bâtie sur une prémisse fausse. Le paquet a été signé de manière véridique par SolarWinds. Ce que les clients en ont déduit était plus large: que le paquet représentait le produit que SolarWinds avait l'intention de publier. L'incident a brisé cette inférence.

La réponse n'est pas d'abandonner les signatures. Sans elles, les clients seraient également exposés à la compromission de miroir, à l'interception réseau et aux paquets contrefaits. La réponse est de renforcer les preuves attachées à la signature. Un processus de publication à haute assurance devrait être capable de montrer quelle révision de source, quel ensemble de dépendances, quelle chaîne d'outils, quelle identité de builder, quelle politique de build, quels tests et quelles approbations ont produit un artefact. Il devrait détecter lorsqu'un worker remplace un fichier qui n'est pas présent dans l'état de source approuvé. Il devrait empêcher la même identité d'altérer la source, la politique de build, l'artefact et la décision de signature sans contrôles indépendants.

Des builds reproductibles ou répétés indépendamment peuvent aider, mais ils ne sont pas magiques. Si des builders supposément indépendants partagent des informations d'identification, une orchestration, des dépendances ou un plan de contrôle compromis, ils peuvent reproduire la même sortie malveillante. La comparaison ne vaut que lorsque les chemins de confiance sont véritablement séparés. De même, une nomenclature logicielle peut identifier des composants sans montrer que le worker de build a inséré du code first-party supplémentaire. L'inventaire est utile; il n'équivaut pas à la provenance.

La proposition de remédiation ultérieure de SolarWinds a reconnu ce problème. Sa mise à jour de mai 2021 décrivait trois environnements de build séparés, le changement des systèmes de build, des informations d'identification distinctes et une comparaison d'intégrité entre les sorties. Lors d'un témoignage au Congrès, le PDG Sudhakar Ramakrishna a présenté cette conception comme un moyen de forcer un attaquant à compromettre plusieurs environnements hétérogènes. Letémoignage écrit au Sénatde l'entreprise est une preuve de la réponse et de l'architecture revendiquée à l'époque. Il ne constitue pas, en soi, une certification indépendante que chaque version a depuis satisfait cette conception.

Le problème du dénominateur: 18 000 était une exposition, pas une exploitation confirmée

Peu de chiffres de l'incident ont été répétés aussi souvent que 18 000. Il n'est utile que si son dénominateur est indiqué.

SolarWinds a initialement informé environ 33 000 clients Orion actifs en maintenance pendant et après la période affectée. Il a estimé que moins de 18 000 pouvaient avoir eu une installation affectée. Certains ont téléchargé mais n'ont pas installé. Certains ont installé sur des systèmes ne pouvant pas atteindre l'infrastructure de commandement et contrôle. Certains ont exécuté l'implant mais n'ont pas été sélectionnés pour une activité de suivi. Un groupe beaucoup plus restreint a communiqué avec une infrastructure ultérieure, et un groupe encore plus restreint a été activement compromis au-delà de la porte dérobée initiale.

En mai 2021, SolarWinds estimait que moins de 100 clients avaient été piratés via SUNBURST. En mars 2021, le témoignage du FBI décrivait plus de 16 000 clients publics et privés affectés, neuf agences fédérales avec compromission de suivi et moins de 100 entités non gouvernementales dans cette catégorie. Les chiffres sont compatibles si "affecté", "installé", "balisé", "ciblé" et "compromis" restent distincts.

La distinction ne rend pas l'incident petit. Une tête de pont administrative latente livrée à des milliers d'organisations est un événement systémique grave même lorsqu'un acteur étatique l'exerce de manière sélective. L'attaquant a obtenu un menu d'accès potentiel et pouvait choisir des cibles en fonction de leur valeur de renseignement. Le risque réside à la fois dans le préjudice réalisé et dans l'ampleur de l'opportunité de confiance.

Elle importe également pour la notification des clients. Un fournisseur ne devrait pas envoyer le même message à chaque classe d'exposition. Les clients doivent savoir s'ils ont simplement téléchargé un artefact, l'ont installé, exécuté, généré une balise connue, reçu une réponse de commandement et contrôle, ou montrent des preuves d'abus d'identité subséquent. Chaque état modifie les décisions de préservation, de réinitialisation des informations d'identification, de reconstruction, de notification et de continuité. Lorsque la télémétrie du fournisseur ne peut pas déterminer l'état, l'incertitude elle-même doit être communiquée.

Le dossier public montre également pourquoi l'impact ne peut pas être déduit uniquement de la télémétrie du fournisseur. Orion s'exécutait à l'intérieur des réseaux clients, de sorte que SolarWinds ne pouvait pas inspecter directement chaque installation. Les clients et les fournisseurs cloud détenaient une partie des preuves. Certaines activités de suivi ont abandonné SUNBURST et utilisé des informations d'identification légitimes ou des assertions d'authentification falsifiées, rendant un serveur Orion propre insuffisant pour prouver que l'environnement plus large était propre. La comptabilité des incidents a dû combiner les enregistrements de téléchargement du fournisseur, les observations DNS, l'investigation forensique des hôtes, les journaux d'identité et les enquêtes des organisations affectées.

Découverte et le coût d'une visibilité tardive

La découverte de FireEye est souvent célébrée comme un succès de détection, et elle l'était. C'est aussi la preuve que le système de sécurité antérieur a échoué.

Pendant des mois, les versions affectées se sont déplacées par un canal de maintenance de confiance. L'attaquant a conçu l'implant pour dormir, éviter les environnements d'analyse, utiliser un contexte de processus familier et imiter le comportement réseau légitime. Les antivirus traditionnels et les règles de périmètre étaient mal positionnés pour reconnaître un composant signé par le fournisseur effectuant une activité ressemblant à la télémétrie propre du produit. Un produit de gestion de réseau a aussi une enveloppe comportementale naturellement large. Il inventorie les systèmes, communique entre segments, détient des informations d'identification utiles et peut contacter légitimement l'infrastructure du fournisseur. Un comportement malveillant peut se cacher à l'intérieur des privilèges dont le produit a besoin.

La première réponse publique de la CISA a reflété la gravité de cette ambiguïté. Sonalerte du 13 décembrea identifié les versions affectées, et la directive d'urgence 21-01 a ordonné aux agences civiles fédérales de déconnecter les produits Orion couverts. L'ordre n'était pas simplement "installez le correctif". Un serveur de gestion déjà compromis pouvait contenir des preuves, des informations d'identification ou une persistance au-delà de la DLL d'origine. Le traiter comme une vulnérabilité normale risquerait de préserver un attaquant après avoir remplacé le fichier initial.

Leguide d'éviction ultérieur de la CISAtraitait des réseaux où l'acteur pouvait s'être déplacé dans Active Directory et Microsoft 365. L'éviction pouvait nécessiter une récupération coordonnée des identités, l'invalidation des jetons et des informations d'identification, un examen du cloud, la reconstruction des hôtes et la surveillance. Ces étapes peuvent interrompre les opérations et consommer du personnel rare même lorsque les services publics restent en ligne. Le coût de continuité d'une compromission confidentielle se mesure en partie au travail requis pour restaurer une confiance justifiée.

Lesdirectives du NCSC du Royaume-Unidistinguaient de la même manière les binaires affectés d'un impact de suivi grave. Elles conseillaient l'isolation, les vérifications de hachage et DNS, les réinitialisations d'informations d'identification, l'investigation des comptes associés au serveur Orion et l'examen d'une reconstruction complète. La cohérence globale de ces conseils montre que l'échec de confiance n'était pas confiné à l'environnement d'approvisionnement d'un seul gouvernement.

La responsabilité de détection était distribuée. SolarWinds était le mieux placé pour surveiller les workers de build, comparer les artefacts à la source approuvée, superviser la signature et identifier une provenance de publication inattendue. Les clients étaient les mieux placés pour restreindre les privilèges d'Orion, segmenter son hôte, conserver les journaux DNS et d'identité et remarquer un comportement s'écartant de leur propre environnement. Les fournisseurs d'identité cloud pouvaient détecter une utilisation anormale des jetons et des comptes entre les locataires. Les organismes gouvernementaux de coordination pouvaient agréger les rapports et émettre des actions obligatoires. Aucun observateur unique n'avait l'image complète, ce qui faisait du partage d'informations en temps opportun un contrôle fonctionnel plutôt qu'une courtoisie.

La réponse démontre également une dure vérité concernant les indicateurs. Les hachages et les domaines sont précieux pendant le triage, mais un acteur patient peut faire tourner l'infrastructure et passer à des comptes valides. L'absence d'un indicateur connu n'est pas une preuve d'absence une fois que l'intrusion est passée aux systèmes d'identité. Une réponse durable devait reconstruire le chemin d'attaque et rétablir la confiance à partir d'états connus comme étant propres.

Continuité du secteur public sans blackout visible

Le GAO a décrit la campagne comme l'une des opérations de piratage les plus vastes et sophistiquées menées contre le gouvernement fédéral et le secteur privé. Sonexamen de la réponse fédérale de 2022a constaté que les agences ont formé un groupe de coordination unifiée cyber, élaboré des orientations et des outils techniques, partagé des informations et identifié des leçons concernant la coordination, l'accès à l'information et la réponse aux incidents. La réponse a été substantielle parce que la compromission touchait la machinerie par laquelle le gouvernement comprend et administre ses propres systèmes.

Neuf agences fédérales ont été identifiées publiquement comme ayant subi une compromission de suivi. Le ministère de la Justice a déclaré que l'activité malveillante avait atteint son environnement de messagerie Microsoft 365 et qu'environ trois pour cent des boîtes aux lettres avaient potentiellement été consultées, tout en n'ayant aucune indication que les systèmes classifiés aient été affectés. Ladéclaration de janvier 2021 du DOJa correctement délimité l'impact connu. Elle n'a pas traité l'exposition des courriels non classifiés comme inoffensive et n'a pas prétendu à la compromission de systèmes pour lesquels elle manquait de preuves.

La continuité a plusieurs couches dans ce contexte.

La première est la disponibilité opérationnelle. Les agences doivent continuer à fournir des fonctions publiques tout en isolant les serveurs de gestion, en reconstruisant les hôtes, en faisant tourner les informations d'identification et en enquêtant sur les comptes cloud. Une directive d'urgence peut être techniquement nécessaire et opérationnellement perturbatrice en même temps.

La deuxième est la continuité de la confidentialité. Les responsables doivent savoir si les ébauches de politique, les informations de passation de marchés, la stratégie juridique, les calendriers ou les réseaux de contacts ont été observés. Une campagne d'espionnage peut extraire un avantage durable sans altérer ni détruire un fichier.

La troisième est l'intégrité administrative. Le rôle d'Orion dans la surveillance et la gestion des réseaux signifiait que les clients devaient remettre en question les informations fournies par un outil destiné à soutenir la confiance. Un plan de gestion compromis peut cacher l'activité, exposer des informations d'identification ou rendre les opérateurs incertains quant aux systèmes qu'ils utilisent pour enquêter.

La quatrième est la continuité de l'identité. L'avis sur les mécanismes d'authentification de décembre 2020 de la NSAexpliquait comment un accès privilégié sur site pouvait conduire à une authentification fédérée falsifiée et à un accès cloud. Une fois la confiance d'identité locale manipulée, le simple nettoyage de l'hôte Orion initial ne restaure pas la validité de chaque session ou jeton qui en découle.

La cinquième est la continuité probatoire. Les agences ont besoin de journaux DNS, de points d'extrémité, d'identité, cloud et administratifs conservés pour décider si une mise à jour téléchargée est devenue une balise ou une compromission complète. Si ces enregistrements ont expiré, les dirigeants doivent opérer sous une incertitude plus large et peuvent avoir besoin d'une remédiation plus large.

La sixième est la confiance institutionnelle. Les acheteurs gouvernementaux demandent aux employés d'utiliser une technologie commerciale partagée pour un travail public sensible. Ce modèle dépend de ce que les fournisseurs représentent avec précision les pratiques de sécurité, divulguent les incidents avec une précision appropriée et fournissent suffisamment de preuves pour soutenir la réponse. Une mise à jour signée qui transporte une porte dérobée affaiblit les hypothèses sociales et administratives dont dépendent les programmes de correctifs.

La campagne n'a pas montré que la mise à jour automatisée est intrinsèquement dangereuse. Retarder les correctifs de sécurité authentiques peut être bien plus dangereux. Elle a montré que l'assurance de mise à jour doit inclure l'environnement de développement et de build du producteur. Dire aux clients d'appliquer rapidement les correctifs tout en traitant l'usine logicielle comme un réseau d'entreprise ordinaire crée une contradiction: plus les clients deviennent sûrs d'accepter les mises à jour, plus un producteur compromis gagne en levier.

Responsabilité de SolarWinds: le contrôle de l'usine

SolarWinds a été victime d'une opération étatique délibérée. Il occupait également la position de contrôle qui rendait le mécanisme de distribution possible.

L'entreprise contrôlait l'accès à ses systèmes de développement logiciel, aux workers de build, à l'orchestration de publication, à la vérification des artefacts, au chemin de signature et au canal de mise à jour client. Les clients ne pouvaient pas déployer de surveillance des points d'extrémité à l'intérieur des builders de SolarWinds. Ils ne pouvaient pas comparer les artefacts avant signature à la source approuvée de l'entreprise, exiger un second build interne ou empêcher la clé de signature du fournisseur d'autoriser une sortie compromise. C'étaient des contrôles du producteur.

La responsabilité opérationnelle suit ce contrôle. La question pertinente n'est pas de savoir si une entreprise raisonnable pouvait garantir l'immunité contre le SVR. Aucun producteur ne peut le promettre. La question est de savoir si le processus de publication contenait des contrôles indépendants capables d'empêcher un environnement compromis de modifier silencieusement un produit signé, ou de détecter la modification avant une large distribution.

Le test d'octobre 2019 et l'opération SUNSPOT ultérieure démontrent que l'attaquant a trouvé la place pour modifier un build sans créer de divergence bloquant la publication. La longue période d'accès interne et l'échec à détecter la manipulation de production sont des faits défavorables dans une évaluation des contrôles. La sophistication de l'acteur est pertinente pour le niveau de résistance requis, mais ce n'est pas une dispense. Un fournisseur dont le produit occupe des positions privilégiées dans les gouvernements et les grandes entreprises devrait s'attendre à être ciblé par des acteurs capables et concevoir l'usine en conséquence.

La responsabilité inclut également la communication d'incident. SolarWinds a informé les clients, travaillé avec les enquêteurs, publié des informations techniques sur SUNSPOT, fourni des remédiations et financé un certain support client. Ces actions ont réduit le préjudice et fourni des preuves industrielles inhabituellement utiles. Elles doivent compter dans le bilan. La responsabilité n'est pas une recherche d'une étiquette définitivement blâmable; elle inclut à la fois les contrôles qui ont échoué et la qualité de la réponse.

Les divulgations de l'entreprise ont été prudentes sur plusieurs points importants. SolarWinds n'a pas attribué l'acteur de manière indépendante avant l'attribution gouvernementale. Elle a distingué les installations potentielles de l'exploitation de suivi confirmée. Elle a reconnu que l'accès initial restait non résolu. Ses dépôts reconnaissaient les risques de litige, d'enquête, de coût, de clientèle et de réputation. Ce sont des atouts significatifs, même si des litiges d'application ultérieurs ont contesté des aspects des déclarations de sécurité publiques antérieures de l'entreprise.

Le devoir du producteur ne s'arrête pas à l'expédition d'un binaire corrigé. SolarWinds devait prouver que le chemin de build lui-même avait changé, que l'autorité de signature ne pouvait pas bénir un artefact inexpliqué, que les informations d'identification et l'accès des tiers étaient limités, et que les preuves persisteraient assez longtemps pour enquêter sur une intrusion patiente. L'architecture revendiquée à trois builds répondait au mécanisme. L'assurance durable exige un test indépendant pour savoir si la séparation survit à une pression opérationnelle réelle.

Responsabilité du client: contraindre le produit de confiance

Les clients ne contrôlaient pas le système de build de SolarWinds, mais ils contrôlaient l'environnement dans lequel Orion était installé. Leur responsabilité commence lorsque le produit entre dans cet environnement.

Un logiciel de gestion de réseau ne devrait pas recevoir une confiance illimitée simplement parce qu'un accès large est pratique. Les clients peuvent isoler les serveurs de gestion, restreindre l'accès internet sortant, séparer les comptes de service, minimiser les privilèges permanents, protéger les informations d'identification administratives, surveiller le comportement réseau du produit et conserver les journaux en dehors du système surveillé. Le NCSC a noté qu'un serveur affecté incapable de résoudre ou d'atteindre une infrastructure externe pouvait empêcher la porte dérobée initiale de progresser. C'est un exemple concret de défense côté client limitant une défaillance provenant du fournisseur.

Les clients contrôlaient également si la confiance d'identité cloud et sur site permettait à un hôte de gestion compromis de devenir une autorité de justificatifs plus large. Des postes de travail administratifs séparés, une identité à plusieurs niveaux, une authentification multifacteur résistante au hameçonnage, une fédération restreinte, une surveillance des jetons et des plans de récupération pouvaient réduire la portée de suivi. Ces contrôles ne pouvaient pas rendre la DLL livrée bénigne, mais ils pouvaient changer les conséquences de son exécution.

Les équipes d'approvisionnement et d'architecture avaient un autre devoir: classer Orion comme une dépendance à haute conséquence. Un outil qui voit la topologie du réseau, manipule des informations d'identification administratives ou surveille des actifs critiques devrait être évalué différemment d'un utilitaire de bureau ordinaire. Les acheteurs devraient savoir quels produits peuvent se mettre à jour eux-mêmes, quelles racines de signature ils font confiance, d'où proviennent les artefacts de publication et à quelle vitesse ils peuvent isoler ou remplacer le produit sans perdre la visibilité opérationnelle.

La responsabilité du client doit néanmoins être limitée par la faisabilité. En 2020, un client ne pouvait pas reconstruire la provenance de build privée de SolarWinds à partir d'un installateur signé. La plupart des acheteurs n'avaient pas de droits contractuels ou d'accès technique pour auditer le pipeline de production. Même une excellente segmentation ne leur dirait pas si un composant signé correspondait à un état source interne approuvé. La responsabilité partagée devient évasive lorsqu'elle assigne aux clients un contrôle qu'ils ne peuvent pas exercer.

La conclusion correcte n'est donc pas que les clients étaient impuissants ou qu'ils ont causé la compromission en faisant confiance aux mises à jour. Appliquer des mises à jour signées du fournisseur est généralement un comportement de sécurité attendu. Les clients sont responsables de limiter le rayon de souffle d'un composant de confiance et de maintenir une détection indépendante. SolarWinds est responsable de l'intégrité du produit qu'il a autorisé et distribué. Ces responsabilités se chevauchent dans la réduction des risques sans devenir interchangeables.

Responsabilité gouvernementale: acheteur, coordinateur et propriétaire de la continuité

Le gouvernement fédéral n'était pas seulement une victime. Il était un acheteur majeur, un régulateur et normalisateur, un détenteur de renseignement et l'opérateur ultimement responsable des missions publiques.

Avant SolarWinds, la gestion fédérale des risques de la chaîne d'approvisionnement était déjà incomplète. Letémoignage de mai 2021 du GAOnotait qu'aucune des 23 agences civiles examinées n'avait pleinement mis en œuvre des pratiques fondamentales sélectionnées de chaîne d'approvisionnement des technologies de l'information et de la communication. Le moment importe: le gouvernement ne peut raisonnablement pas placer toute la charge sur un fournisseur tout en omettant d'inventorier, d'évaluer et de gérer en continu les logiciels critiques dont dépendent les agences.

Les agences contrôlaient le placement du produit, les privilèges des comptes de service, la sortie réseau, l'architecture d'identité, la journalisation, les exigences d'approvisionnement et la capacité de récupération. La direction d'urgence de la CISA était nécessaire en partie parce que les agences affectées devaient agir de manière cohérente et rapide. Un plan de continuité mature devrait déjà savoir où Orion est installé, ce qu'il peut atteindre, quelles informations d'identification il utilise, quelle visibilité opérationnelle disparaît lorsqu'il est déconnecté et comment remplacer temporairement cette fonction.

Le gouvernement détenait également des avantages agrégés indisponibles pour un seul client. La CISA, le FBI, la NSA, l'ODNI et les partenaires sectoriels pouvaient combiner des informations classifiées et non classifiées, corréler les rapports, publier des indicateurs et coordonner l'éviction. Le GAO a constaté que le groupe de coordination unifiée cyber a aidé à organiser la réponse, tout en identifiant des défis concernant le partage d'informations et l'accès au secteur privé. La latence de coordination a un coût public lorsque chaque organisation affectée essaie séparément de déterminer si le même fichier signé est dangereux.

L'approvisionnement est l'un des leviers préventifs les plus puissants du gouvernement. Les acheteurs peuvent exiger des attestations de développement sécurisé, des conditions de notification d'incident, la provenance des artefacts, la divulgation des vulnérabilités, la conservation des preuves, la coopération pendant la réponse et le droit d'obtenir une assurance indépendante. Ils peuvent également éviter la conformité par case à cocher qui demande si un fournisseur a un cycle de vie de développement sécurisé sans tester si un build peut diverger du code source révisé.

Le dossier politique post-incident a évolué dans cette direction. Lecadre de développement logiciel sécurisé du NISTinclut des pratiques de protection des environnements de développement, de préservation de la provenance, de vérification des versions, de réponse aux vulnérabilités et de prévention de la récurrence. Lesdirectives du NIST sur la chaîne d'approvisionnement cybersécuritéplacent le risque fournisseur à l'intérieur de la gouvernance d'entreprise plutôt que de le laisser à un questionnaire d'approvisionnement. Lemémorandum M-22-18 de l'OMBobligeait les agences fédérales à obtenir des attestations de producteur de logiciels liées aux pratiques de développement sécurisé du NIST pour les logiciels couverts.

L'attestation n'est utile que si elle est véridique, délimitée et testable. Une déclaration signée ne peut pas résoudre le même problème épistémique qu'un binaire signé si la preuve de production sous-jacente est indisponible. Les acheteurs à haute conséquence ont besoin de la capacité de demander des artefacts, des exceptions, des évaluations indépendantes et des plans correctifs. Une fausse assurance peut augmenter le risque en encourageant une confiance rapide sans fournir un moyen de vérifier la revendication.

Le dossier juridique ne fournit pas un verdict simple

La responsabilité opérationnelle et la responsabilité juridique ont fortement divergé après l'incident.

En octobre 2023, la SEC a poursuivi SolarWinds Corporation et le responsable de la sécurité des systèmes d'information Timothy Brown pour fraude et violations de contrôle. Lecommuniqué de presse du litige de la SECalléguait que les déclarations publiques exagéraient les pratiques de sécurité et minimisaient les risques connus avant SUNBURST. Ces allégations étaient importantes, mais une plainte est une plaidoirie d'avocat, pas une constatation de fait.

En juillet 2024, le tribunal de district des États-Unis pour le district sud de New York arejeté la plupart des demandes de la SEC. Le tribunal a autorisé les demandes de fraude en valeurs mobilières basées sur la déclaration de sécurité du site web de l'entreprise avant SUNBURST à se poursuivre, estimant que la plainte modifiée plaidait adéquatement des déclarations trompeuses concernant les contrôles d'accès et les pratiques de mot de passe. Il a rejeté les demandes basées sur les divulgations de risques, les formulaires 8-K de décembre 2020, les déclarations post-incident, les contrôles comptables internes et les contrôles de divulgation. La décision appliquait les normes de plaidoirie et de droit des valeurs mobilières. Elle n'a pas mené de procès sur la cause technique de SUNBURST ni déclaré le processus de build sûr.

Le 20 novembre 2025, la SEC et les défendeurs ont stipulé un rejet avec préjudice. Lecommuniqué de presse final du litigede l'agence indiquait que la décision était un exercice de discrétion et ne reflétait pas nécessairement sa position dans une autre affaire. Le rejet avec préjudice a mis fin à cette action d'application. Cela signifie que les allégations survivantes ne sont pas devenues un jugement de responsabilité final.

Cette séquence soutient quatre conclusions disciplinées.

Premièrement, la théorie originale de la SEC ne devrait pas être répétée comme un fait établi. De nombreuses demandes ont été rejetées, et aucune n'a produit de jugement au procès.

Deuxièmement, le rejet de l'affaire d'application ne devrait pas être présenté comme une preuve technique que les contrôles de build de SolarWinds répondaient à une norme adéquate en 2019 et 2020. L'affaire concernait des déclarations, des éléments, des lois et des règles de plaidoirie particuliers. Un tribunal peut rejeter une demande en valeurs mobilières alors qu'une défaillance de contrôle d'ingénierie reste documentée.

Troisièmement, la demande survivante sur la déclaration du site web avant le rejet montre que les représentations volontaires de sécurité peuvent créer un risque de responsabilité lorsqu'elles sont larges et difficiles à concilier avec les conditions internes. Les fournisseurs devraient décrire les résultats, la portée, les exceptions et les preuves d'assurance avec précision plutôt que de promettre une posture de sécurité généralisée.

Quatrièmement, l'incertitude juridique n'empêche pas une analyse de capacité de contrôle. SolarWinds contrôlait l'usine; les clients contrôlaient les limites de déploiement; le gouvernement contrôlait l'approvisionnement public et la coordination; le SVR contrôlait la campagne hostile. Les contrats, les dommages, la causalité, la juridiction et les obligations légales déterminent si cette carte opérationnelle devient un recours juridique. Aucune source utilisée ici ne soutient l'attribution d'un pourcentage de responsabilité juridique entre ces parties.

L'épisode a également révélé une tension politique. Une application agressive peut améliorer la franchise lorsque les entreprises minimisent les incidents connus. Elle peut aussi dissuader la documentation interne ou le partage volontaire de menaces si le personnel de sécurité croit que chaque préoccupation préliminaire sera ultérieurement plaidée comme fraude. Le meilleur régime de responsabilité récompense la divulgation rapide et étiquetée avec confiance tout en pénalisant les déclarations matériellement fausses prouvées selon des normes appropriées. Il ne devrait pas exiger une prévention parfaite comme prix d'être traité comme une victime.

La remédiation doit changer les preuves, pas seulement le diagramme d'architecture

SolarWinds a signalé des changements importants après la découverte: une authentification multifacteur plus large, un moindre privilège plus strict, un examen plus rigoureux des applications tierces, une surveillance renforcée, des processus de build repensés, plusieurs builders isolés, des informations d'identification séparées, une comparaison des sorties, une analyse statique, une analyse open source, des tests de pénétration et un suivi des actifs. Son partage public des détails de SUNSPOT a donné aux autres producteurs un modèle de menace concret. Ce sont des réponses pertinentes et spécifiques au mécanisme.

La revendication de remédiation la plus forte n'est pas "nous construisons maintenant à trois endroits". C'est un ensemble de preuves montrant qu'un changement de source transitoire non autorisé ne peut pas atteindre une version signée sans créer de discordance détectable. Cette preuve devrait survivre aux changements de personnel, à la pression des délais, aux correctifs d'urgence et au remplacement des builders.

Un dossier d'assurance crédible répondrait au moins à ces questions:

1. Chaque binaire publié peut-il être tracé à une révision de source approuvée immuable, un ensemble de dépendances, un compilateur et une politique de build?
2. Les workers de build sont-ils éphémères ou restaurés à partir d'un état vérifié, et leurs plans de contrôle sont-ils isolés de l'identité d'entreprise ordinaire?
3. Une seule information d'identification peut-elle modifier le build, supprimer la télémétrie et demander une signature de production?
4. Les builds séparés sont-ils véritablement indépendants, ou partagent-ils une dépendance cachée qui peut produire une compromission identique?
5. Le service de signature vérifie-t-il la provenance et la politique, ou signera-t-il n'importe quel artefact présenté par un compte autorisé?
6. Les journaux de build et de signature sont-ils écrits dans un magasin administré séparément, résistant à l'altération et conservés pendant le temps de séjour attendu d'un acteur étatique?
7. Des canaris de test ou des injections de fautes contrôlées sont-ils utilisés pour prouver qu'une variation de build non autorisée arrête une version?
8. Le fournisseur peut-il révoquer une version, informer les clients par classe d'exposition et fournir des artefacts de récupération propres sans détruire les preuves forensiques?
9. Les clients reçoivent-ils une provenance vérifiable ou seulement une signature et une assurance marketing?
10. Les exceptions sont-elles visibles pour les dirigeants et les clients dont le risque change à cause d'elles?

Ce ne sont pas des demandes de divulgation de code source ou de secrets de production sensibles à chaque acheteur. Des auditeurs indépendants, des évaluateurs gouvernementaux et des mécanismes de transparence contrôlés peuvent valider les résultats sans publier une carte d'attaque. L'objectif est une preuve proportionnée au privilège et à la portée systémique du produit.

Les clients ont besoin de preuves complémentaires. Ils devraient être capables de montrer qu'Orion ou une plateforme de gestion équivalente ne peut pas librement atteindre chaque niveau administratif; que les comptes de service sont délimités; que le trafic sortant est sur liste blanche lorsque c'est pratique; que les journaux d'identité et DNS quittent l'environnement géré; qu'un serveur de gestion compromis peut être isolé sans perdre toute conscience opérationnelle; et que la fédération cloud peut être reconstruite à partir d'une autorité connue propre.

Les acheteurs gouvernementaux devraient tester la continuité, pas seulement recevoir de la paperasserie. Un exercice sur table peut demander à une agence de déconnecter sa plateforme de gestion réseau en quelques heures, d'énumérer les informations d'identification associées, de préserver les preuves, de restaurer la visibilité avec un outil alternatif et de coordonner la réinitialisation d'identité. L'échec dans cet exercice identifie un risque public avant qu'une directive réelle n'arrive.

Une allocation pratique de la responsabilité

L'incident devient plus clair lorsque la responsabilité est assignée par capacité de contrôle plutôt que par proximité avec le titre.

Le SVR russe, selon l'attribution américaine et alliée, a planifié et mené la campagne d'espionnage. Il a choisi de compromettre un fournisseur, conçu SUNSPOT et SUNBURST, sélectionné des cibles en aval et utilisé l'accès volé. Sa culpabilité est primaire et intentionnelle.

SolarWinds contrôlait si son architecture d'accès interne limitait l'acteur, si la sortie du build devait correspondre à la source approuvée, si les builders et la signature étaient supervisés indépendamment, si un comportement de publication anormal produisait une alerte, et si les clients recevaient des preuves précises et opportunes. L'entreprise contrôlait également des parties importantes de la remédiation et de la divulgation. Son statut de victime ne supprime pas ces responsabilités; sa transparence ultérieure n'efface pas l'échec initial, mais elle peut réduire le préjudice futur.

Les clients contrôlaient le placement du produit, les privilèges, les chemins réseau, la conservation des journaux, l'escalade d'incident et la récupération d'identité. Une organisation qui a donné à Orion une portée administrative illimitée avec une surveillance externe faible a accepté plus de conséquences qu'une autre qui a isolé la plateforme. Cette différence affecte la prévention et les dommages même si aucun client n'a causé la publication malveillante.

Les fournisseurs cloud et d'identité contrôlaient la télémétrie inter-locataires et les mécanismes de détection ou d'invalidation de l'authentification falsifiée ou abusive. L'accès cloud de suivi a transformé un incident de chaîne d'approvisionnement logicielle en un incident d'identité plus large. La coopération et les journaux des fournisseurs faisaient donc partie de la restauration de la confiance.

Les dirigeants des agences fédérales contrôlaient la continuité de mission, les inventaires, les conditions d'approvisionnement et la mise en œuvre des pratiques de chaîne d'approvisionnement à l'échelle du gouvernement. La CISA et les agences partenaires contrôlaient les alertes coordonnées, les directives, les outils et la compréhension partagée des incidents. Le Congrès et les régulateurs contrôlaient la supervision et les incitations, sous réserve des limites de leur autorité statutaire.

Les dirigeants et les conseils d'administration des producteurs de logiciels contrôlent les ressources et les incitations qui déterminent si la sécurité du build est une exigence produit ou un projet interne au mieux. Un pipeline de build pour un logiciel à portée administrative fait partie de la frontière de sécurité du produit. Les décisions d'investissement à son sujet devraient être gouvernées comme les décisions sur le code livré.

La responsabilité d'aucune partie n'annule celle d'une autre. "Le client aurait dû segmenter Orion" ne répond pas à la question de savoir pourquoi un artefact non autorisé a été signé. "SolarWinds aurait dû protéger le build" ne répond pas à la question de savoir pourquoi un serveur de gestion pouvait atteindre les identités de plus haute valeur du client. "Le SVR était sophistiqué" ne répond pas à la question de savoir si une vérification de build indépendante existait. Un compte rendu mature permet aux trois affirmations d'être vraies et demande encore ce que chaque partie doit prouver maintenant.

La leçon durable: les signatures ont besoin d'une chaîne de vérité de production

La compromission SolarWinds a changé la politique de chaîne d'approvisionnement logicielle parce qu'elle a exploité une habitude qui était autrement souhaitable: obtenir les mises à jour du fournisseur, vérifier la signature et les appliquer rapidement. L'événement n'a pas rendu cette habitude irrationnelle. Il a montré que la confiance des clients avait dépassé les preuves exposées par le processus de production.

Le modèle correctif est une chaîne de vérité de production. La source approuvée devrait mener à une demande de build identifiée. La demande devrait s'exécuter dans un environnement durci et observable. Les dépendances et les outils devraient être épinglés et enregistrés. L'artefact résultant devrait être comparé à une attente indépendante. La signature ne devrait se produire qu'après des vérifications de politique et de provenance. La distribution devrait préserver l'artefact. Les clients devraient pouvoir vérifier plus que la possession de la clé de signature. Les journaux devraient rendre chaque maillon investigable après une longue période de séjour.

Ce modèle améliore également la continuité publique. Lorsqu'une version est remise en question, les agences peuvent déterminer quel artefact elles ont exécuté, quelle source et quel builder l'ont produit, quels privilèges il avait, ce qu'il a contacté et quelles identités doivent être récupérées. L'incertitude se réduit. La réponse devient ciblée plutôt qu'indiscriminée. Les services essentiels passent moins de temps à reconstruire des systèmes qui peuvent être prouvés propres et plus de temps sur ceux qui ne le peuvent pas.

SolarWinds ne devrait pas rester dans les mémoires seulement comme une entreprise qui a été piratée ou comme un symbole utilisé pour exiger une responsabilité illimitée des fournisseurs. La leçon la plus utile est institutionnelle. Un producteur de logiciels peut devenir une infrastructure pour ses clients même lorsqu'il vend un produit sur site. Son système de build peut devenir une frontière de confiance publique même lorsque les clients ne le voient jamais. Et une signature cryptographique peut être parfaitement valide tandis que la revendication organisationnelle que les gens y attachent est fausse.

La norme de responsabilité devrait découler de cette réalité. L'attaquant est responsable de l'intrusion. Le fournisseur est responsable de rendre le chemin de publication résistant, observable et honnêtement décrit. Le client est responsable de contenir le produit et de préserver des preuves indépendantes. Le gouvernement est responsable d'acheter avec ces dépendances en vue et de maintenir les missions publiques lorsque la confiance s'effondre. La campagne Orion de 2020 a traversé les quatre domaines. Une remédiation durable doit faire de même.