Discussion :

[Sandra Coret]

41 % des entreprises n'ont pas une grande confiance dans la sécurité de leurs logiciels open source, leur utilisation généralisée entraînant des risques importants

Selon un nouveau rapport de la société de sécurité des développeurs Snyk et de la Fondation Linux, Le projet moyen de développement d'applications comporte 49 vulnérabilités et 80 dépendances directes (code open source appelé par un projet).

De plus, le temps nécessaire pour corriger les vulnérabilités des projets open source n'a cessé d'augmenter, faisant plus que doubler, passant de 49 jours en 2018 à 110 jours en 2021.

"Les développeurs de logiciels ont aujourd'hui leurs propres chaînes d'approvisionnement -- au lieu d'assembler des pièces de voiture, ils assemblent du code en patchant ensemble des composants open source existants avec leur code unique. Si cette situation entraîne une augmentation de la productivité et de l'innovation, elle a également créé des problèmes de sécurité importants", explique Matt Jarvis, directeur des relations avec les développeurs chez Snyk. "Ce rapport, le premier du genre, a trouvé de nombreuses preuves suggérant une naïveté de l'industrie quant à l'état actuel de la sécurité des logiciels libres. En collaboration avec la Fondation Linux, nous prévoyons d'exploiter ces résultats pour éduquer et équiper davantage les développeurs du monde entier, leur permettant ainsi de continuer à construire rapidement, tout en restant en sécurité."

Parmi les autres résultats, seuls 49 % des organisations disposent d'une politique de sécurité pour le développement ou l'utilisation des logiciels libres (et ce chiffre n'est que de 27 % pour les moyennes et grandes entreprises). Tandis que 30 % des organisations sans politique de sécurité des logiciels libres reconnaissent ouvertement que personne dans leur équipe ne s'occupe directement de la sécurité des logiciels libres.

La complexité de la chaîne d'approvisionnement est également un problème, plus d'un quart des répondants à l'enquête indiquent qu'ils sont préoccupés par l'impact sur la sécurité de leurs dépendances directes. Seuls 18 % se disent confiants dans les contrôles qu'ils ont mis en place pour ces dépendances et 40 % de toutes les vulnérabilités ont été découvertes dans des dépendances transitives.

Source : Snyk

Et vous ?

Trouvez-vous ce rapport pertinent ?
Qu'en est-il au sein de votre entreprise ?

Voir aussi :

La Maison Blanche, la Fondation Linux, OpenSSF et 37 entreprises technologiques ont annoncé un plan de sécurité des logiciels Open Source en 10 points, et un financement de 150 millions de dollars

Les vulnérabilités Open Source constituent des menaces pour la sécurité : 85 % des bases de code utilisent des composants dépassés, et 88 % des composants qui ne sont pas de la dernière version

Les développeurs Open source consacreraient moins de 3 % de leur temps à la sécurité, selon une nouvelle enquête de l'Open Source Security Foundation (OpenSSF) et du Laboratory for Innovation Science

[herr_wann]

Et quel pourcentage des entreprises n'ont pas une grande confiance dans la sécurité de leurs logiciels tout court ?

Quand on voit le nombre de boites milliardaires qui ne contribuent pas un centime et ne prennent même pas le temps d'auditer le code

Le beurre, l'argent du beurre...

[walfrat]

Et surtout quel pourcentage de gens ont la compétence pour déployer correctement les logiciels en questions ?

Une partie non négligeable des leaks de données l'ont été parce que des base de données était directement exposées aux Web avec les logins/mdps par défaut je rappelle.

[grunk]

Je fais 1000x plus confiance à une lib opensource reconnue utilisée par des dizaines de milliers de dév que le truc interne développé par Jean-Michel au 3ème (pardon à tous les Jean-Michel )
Evidemment qu'il ne faut pas utiliser le premier truc trouvé sur internet mais quand on sait choisir correctement ses dépendances c'est pour moi gage de qualité , surtout sur des problématiques complexe comme la crypto.

[marsupial]

Il y a un rapport pour le logiciel libre mais existe-t-il un rapport pour les logiciels fermés ? Pour l'instant, il y a un partout entre les 2 : Solarwinds contre log4J. D'autant plus qu'auditer du code libre est bien plus simple que le code fermé. Pour avoir fait un peu de recherche de failles logiciels, je dirai que code libre comme code fermé comportent le même type de failles mais qu'il est plus facile de les trouver dans les logiciels libres et donc de les corriger. Solarwinds l'a prouvé, une faille dans du code fermé a des conséquences dévastatrices car non-rendu public comme pour le logiciel libre même si log4J démontre que nul n'est infaillible.

De plus, dans le logiciel libre, on n'est pas tributaire du bon vouloir d'un éditeur pour appliquer un correctif et qui souvent, pour ne pas dire toujours, a une priorité : le fric avant la qualité.

Pour conclure, un développeur est un être humain sujet à commettre des erreurs bêtes comme ne pas encadrer les contraintes du langage involontairement donc n'importe quel code source est faillible. Exemple : java script ne gère que les dates depuis 1970 et à l'époque je n'ai trouvé aucun site web traitant cette limite afin d'éviter les bugs, donc les failles, donc les exploitations. J'en ai fait part à Ziff Davis et à developpez.com entre autres. Les CERT Java et C sont nés de cette impulsion à respecter les spécificités des langages.

PDF CERT C

[vanquish]

Et surtout quel pourcentage de gens ont la compétence pour déployer correctement les logiciels en questions ?

Une partie non négligeable des leaks de données l'ont été parce que des base de données était directement exposées aux Web avec les logins/mdps par défaut je rappelle.

En même temps si la procédure d’installation où les fichiers de configuration fournis par défaut laissent tout ouvert, c'est qu'il y a un gros "je-m'en-foutisme" sur la sécurité de la part des développeurs.
On pouvait trouver cela, il y a 20 ans. Plus aujourd'hui.
Et si elle se niche même dans ces choses évidentes (la première règle étant de laisser la plus faible surface d'attaque par défaut), quid du reste de leur programme.

Ceci dit, cela n'a rien à voir avec l'open/private source.
Dans ce domaine précis, on trouve de bon et de mauvais élèves des 2 cotés.

[vanquish]

D'autant plus qu'auditer du code libre est bien plus simple que le code fermé. Pour avoir fait un peu de recherche de failles logiciels, je dirai que code libre comme code fermé comportent le même type de failles mais qu'il est plus facile de les trouver dans les logiciels libres et donc de les corriger.

Ca c'est certainement vrai, le reste me parait plus caricatural.

Solarwinds l'a prouvé, une faille dans du code fermé a des conséquences dévastatrices car non-rendu public comme pour le logiciel libre même si log4J démontre que nul n'est infaillible.

Le fait qu'une faille soit rendue plublic n'a rien à voir avec le fait le code soit ouvert ou fermé, mais dépend de QUI trouve la faille.

Un White Hat la divulguera au développeur que le code soit ouvert ou fermé, puis au monde si le développeur ne fait rien dans un délais raisonnable.
Un Black Hat la taira dans tous les cas.

Si la NSA ou NSO Group trouvent une faille dans open-ssl, pas certain qu'ils la révèle. C'est pas le genre de la maison.

De plus, dans le logiciel libre, on n'est pas tributaire du bon vouloir d'un éditeur pour appliquer un correctif et qui souvent, pour ne pas dire toujours, a une priorité : le fric avant la qualité.

Cela existe, mais il ne faut pas caricaturer non plus.
D'abord, c'est rare, mais on a vu des développeurs open-source volontairement véroler leur travail.
Ensuite la plupart de grand éditeurs commerciaux ont mis en place des système de primes pour inciter les hacker à les aider à trouver les failles. La confiance des utilisateurs leur est indispensable pour vendre.
Le plus souvent ce qui freine la mise en place d'un patch, c'est la compatibilité ascendante ou parce qu'il est intrinsèque à un protocole (Netbios 1 ou 2 ne sont pas corrigeables).
On trouve le même problème dans l'open. Parfois des versions N+1 ont eu beaucoup de mal à prendre leur envol parce qu’incompatible avec la version N.
Et dans ce cas, il est vrai que si un organisme à but non lucratif (ce qui est le cas de beaucoup de projet open sources) peut se permettre ce genre de lenteur, ce n'est effectivement pas le cas d'une société commerciale.

Je m'excuse pour l'opposition commercial/open source, mais je ne vais pas faire une périphrase à chaque fois, même si je dois choquer quelques intégristes.
Je pense que tout le monde aura compris mon propos (à défaut d'être d'accord).

[marsupial]

Je suis d'accord que corriger une faille ne se fait pas forcément simplement. Mais on trouve plus facilement des conflits entre white hats et entreprises commerciales sur des failles non corrigées 3, 4 ou 6 mois après la divulgation aux personnes concernées qui amènent à des situations de publication de la faille, PoC entraînant des cris d'orfraie de la part des sociétés. Ce n'est malheureusement pas rare (on lit régulièrement des actualités sur developpez qui relatent ce cas de figure) même si les programmes de bug bounty font part d'une bonne volonté de la part des éditeurs. Mais justement, des sociétés comme Microsoft ralent contre Google Project Zero, Apple aussi; alors que mon point de vue est que 3 mois pour corriger une faille de la part des ces grands acteurs sont amplement suffisant. Il a fallu 15 jours et 4 patchs pour log4J et il n'y a pas eu de conflits avec les white hats qui validaient les patchs. Et ils s'agit d'une petite équipe. Alors MS et Apple ont largement les moyens de faire de la qualité si l'option pécuniaire n'était pas privilégiée.

Et j'ai peut-être ouvert le débat sur ce sujet de manière caricaturale mais la situation est tellement névralgique que je trouve inadmissible que des groupes dégageant des dizaines de milliards de bénéfice à l'année (ce ne sont pas des philanthropes) puissent avoir un niveau de qualité aussi bas mettant en dangers les utilisateurs dans leurs produits bien assez chers.

[redcurve]

Je suis d'accord que corriger une faille ne se fait pas forcément simplement. Mais on trouve plus facilement des conflits entre white hats et entreprises commerciales sur des failles non corrigées 3, 4 ou 6 mois après la divulgation aux personnes concernées qui amènent à des situations de publication de la faille, PoC entraînant des cris d'orfraie de la part des sociétés. Ce n'est malheureusement pas rare (on lit régulièrement des actualités sur developpez qui relatent ce cas de figure) même si les programmes de bug bounty font part d'une bonne volonté de la part des éditeurs. Mais justement, des sociétés comme Microsoft ralent contre Google Project Zero, Apple aussi; alors que mon point de vue est que 3 mois pour corriger une faille de la part des ces grands acteurs sont amplement suffisant. Il a fallu 15 jours et 4 patchs pour log4J et il n'y a pas eu de conflits avec les white hats qui validaient les patchs. Et ils s'agit d'une petite équipe. Alors MS et Apple ont largement les moyens de faire de la qualité si l'option pécuniaire n'était pas privilégiée.

Et j'ai peut-être ouvert le débat sur ce sujet de manière caricaturale mais la situation est tellement névralgique que je trouve inadmissible que des groupes dégageant des dizaines de milliards de bénéfice à l'année (ce ne sont pas des philanthropes) puissent avoir un niveau de qualité aussi bas mettant en dangers les utilisateurs dans leurs produits bien assez chers.

3 mois pour corriger mais vous n'en savez rien dans des systèmes complexe corriger une faille peut ne pas être possible sans refonte d'autres éléments au tour. En outre il est plus simple de corriger vite fait quand ta licence est en mode "on s'en balek", quand tu as des clients tu vas prendre 2 semaines à traiter le problème 6 mois à vérifier que tu n'as rien casser ailleurs, sans compter que si ton soft sert de base à d'autres faut tester rapidement des centaines voire des milliers de softs et le plus de combinaison possible.

Log4J est un tout petit software...

[smarties]

Personnellement, quand je développe un service web open source je m'occupe que de la sécurité au niveau de l'identification en générant les erreur adéquates.
J'expose que le port web sous docker et si c'est sur la machine je donné juste les instructions pour installer.

Pour le reste, il y a fail2ban ou crowdsec (que je précise dans les instructions d'installation), la configuration de la partie HTTPS ou autre protocole sécurisé qui est à la charge de la personne qui installe.

Ca ne sert à rien de réinventer la roue quand il y a des outils open source qui fonctionne bien depuis longtemps et très largement utilisés.

[Bruno]

La DARPA s'inquiète de la fiabilité du code open source, il fonctionne sur tous les ordinateurs de la planète et assure le fonctionnement des infrastructures critiques, selon Dave Aitel de la NSA

Alors que la DARPA, bras de recherche de l'armée américaine, s'inquiète de la fiabilité du code open source, et dit vouloir comprendre l’écosystème technologique le plus important de la planète, certains analystes trouvent exagéré de dire que, le code open source fonctionne sur tous les ordinateurs de la planète et assure le fonctionnement des infrastructures critiques.

« Attendez une minute, littéralement tout ce que nous faisons est sous-tendu par Linux », déclare Dave Aitel, chercheur en cybersécurité et ancien scientifique en sécurité informatique de la NSA. « C’est maintenant que les gens le réalisent », soutient-il. « Il n'est pas exagéré de dire que le monde entier est construit sur le noyau Linux, même si la plupart des gens n'en ont jamais entendu parler. »

Selon un nouveau rapport de la société de sécurité des développeurs Snyk et de la Fondation Linux, 41 % des entreprises n'ont pas une grande confiance dans la sécurité de leurs logiciels open source, leur utilisation généralisée entraînant des risques importants. Une grande partie de la civilisation moderne dépend aujourd'hui d'un corpus toujours plus vaste du code open source, car il permet d'économiser de l'argent, d'attirer des talents et de faciliter de nombreuses tâches.

« Les développeurs de logiciels ont aujourd'hui leurs propres chaînes d'approvisionnement. Au lieu d'assembler des pièces de voiture, ils assemblent du code en patchant ensemble des composants open source existants avec leur code unique. Si cette situation entraîne une augmentation de la productivité et de l'innovation, elle a également créé des problèmes de sécurité importants », explique Matt Jarvis, directeur des relations avec les développeurs chez Snyk.

Le noyau Linux est l'un des tout premiers programmes qui se chargent lorsque la plupart des ordinateurs sont allumés. Il permet au matériel de la machine d'interagir avec le logiciel, régit l'utilisation des ressources et constitue la base du système d'exploitation. Il s'agit de la brique de base de la quasi-totalité du cloud computing, de pratiquement tous les superordinateurs, de l'ensemble de l'internet des objets, de milliards de smartphones, etc.

Mais le noyau est également open source, ce qui signifie que tout le monde peut écrire, lire et utiliser son code. Et cela inquiète sérieusement certains experts en cybersécurité. Sa nature open source signifie que le noyau Linux - ainsi qu'une foule d'autres logiciels critiques open source - est exposé à des manipulations hostiles d'une manière que nous comprenons encore à peine.

S’il est vrai que c'est une technologie essentielle à notre société, il n’en est pas moins vrai que, au vu de ce qui précède, ne pas comprendre la sécurité du noyau signifie que nous ne pouvons pas sécuriser les infrastructures critiques. Aujourd'hui, la DARPA veut comprendre la collision du code et de la communauté qui fait fonctionner ces projets open source, afin de mieux comprendre les risques auxquels ils sont confrontés.

L'objectif est de pouvoir reconnaître efficacement les acteurs malveillants et les empêcher de perturber ou de corrompre un code open source d'une importance cruciale avant qu'il ne soit trop tard. Le programme SocialCyber de la DARPA est un projet de plusieurs millions de dollars, d'une durée de 18 mois, qui associera la sociologie aux récentes avancées technologiques en matière d'intelligence artificielle pour cartographier, comprendre et protéger la grande communauté de logiciels libres et le code qu'elles créent.

Ce projet est différent de la plupart des recherches antérieures, car il combine l'analyse automatisée du code et des dimensions sociales des logiciels libres.

Fonctionnement du programme SocialCyber

La DARPA a passé un contrat avec de multiples équipes de ce qu'elle appelle des « exécutants », notamment de petits ateliers de recherche en cybersécurité dotés de compétences techniques approfondies. L'un de ces exécutants est Margin Research, basé à New York, qui a constitué une équipe de chercheurs très respectés pour cette tâche. Margin Research se concentre sur le noyau Linux en partie parce qu'il est si grand et si critique que réussir ici, à cette échelle, signifie qu’il est possible de réussir partout ailleurs.

L'objectif est d'analyser à la fois le code et la communauté afin de visualiser et de comprendre enfin l'ensemble de l'écosystème. Le travail de Margin permet de déterminer qui travaille sur quelles parties spécifiques des projets de logiciels libres. Par exemple, Huawei est actuellement le plus grand contributeur au noyau Linux. Un autre contributeur travaille pour Positive Technologies, une entreprise russe de cybersécurité qui, comme Huawei, a été sanctionnée par le gouvernement américain, explique Aitel. Margin a également cartographié du code écrit par des employés de la NSA, dont beaucoup participent à différents projets open source.

« Ce sujet me fait frémir », dit d'Antoine à propos de la quête pour mieux comprendre le mouvement open-source, « parce que, honnêtement, même les choses les plus simples semblent si nouvelles pour tant de personnes importantes. Le gouvernement vient tout juste de se rendre compte que nos infrastructures critiques utilisent un code qui pourrait être littéralement écrit par des entités sanctionnées. En ce moment même. »

Ce type de recherche vise également à trouver le sous-investissement - c'est-à-dire les logiciels critiques exécutés entièrement par un ou deux volontaires. SocialCyber s'attaquera également à d'autres projets open source, comme Python qui est « utilisé dans un grand nombre de projets d'intelligence artificielle et d'apprentissage automatique », note le rapport. « L'espoir est qu'une meilleure compréhension permettra de prévenir plus facilement une future catastrophe, qu'elle soit causée par une activité malveillante ou non. »

Le département de la Défense des États-Unis abrégé par DoD a des dépendances critiques vis-à-vis des logiciels libres tout au long de sa chaîne d'approvisionnement, y compris les systèmes d'exploitation, les systèmes de virtualisation et les hyperviseurs, ainsi que les chaînes d'outils pour le développement de logiciels. L'utilisation de logiciels libres par le ministère de la Défense permet de réduire les coûts, d'améliorer la maintenabilité et d'attirer des développeurs talentueux, mais elle crée également une surface d'attaque sans précédent, dans laquelle de nombreux éléments et chemins logiciels fiables sont exposés à des manipulations hostiles. Les manipulateurs peuvent tirer parti de l'ensemble des mécanismes sociaux et des incitations qui rendent l'écosystème sociotechnique du logiciel libre si précieux.

L'armée américaine veut comprendre le logiciel le plus important de la planète

« L'écosystème des logiciels libres est l'une des plus grandes entreprises de l'histoire de l'humanité », explique Sergey Bratus, responsable du programme DARPA à l'origine du projet. « Il est passé du statut d'enthousiaste à celui d'entreprise mondiale, formant la base de l'infrastructure mondiale, de l'Internet lui-même, des industries critiques et des systèmes essentiels à la mission, un peu partout », ajoute-t-il. « Les systèmes qui font fonctionner notre industrie, les réseaux électriques, la navigation, les transports ».

Cependant, il existe de nombreux Menaces sur l'open source. En effet, si le mouvement open source a donné naissance à un écosystème colossal dont nous dépendons tous, nous ne le comprenons pas entièrement, affirment des experts comme Aitel. Il existe d'innombrables projets logiciels, des millions de lignes de code, de nombreuses listes de diffusion et de nombreux forums, ainsi qu'un océan de contributeurs dont l'identité et la motivation sont souvent obscures, ce qui rend difficile de les tenir pour responsable.

Cela peut être dangereux. Par exemple, des pirates ont discrètement inséré du code malveillant dans des projets de logiciels libres à de nombreuses reprises ces dernières années. Des portes dérobées peuvent longtemps échapper à la détection et, dans le pire des cas, des projets entiers ont été confiés à des acteurs malveillants qui profitent de la confiance que les gens placent dans les communautés et dans le code des logiciels libres. Parfois, les réseaux sociaux dont dépendent ces projets sont perturbés ou même pris en charge. Le suivi de tout cela a été principalement - mais pas entièrement - un effort manuel, ce qui signifie qu'il n'est pas à la hauteur de la taille astronomique du problème.

Selon Bratus, nous avons besoin de l'apprentissage automatique pour digérer et comprendre l'univers en expansion du code. Ce qui implique des astuces utiles comme la découverte automatique de vulnérabilités ainsi que des outils pour comprendre la communauté des personnes qui écrivent, corrigent, mettent en œuvre et influencent ce code. L'objectif ultime est de détecter et de contrer toute campagne malveillante visant à soumettre du code défectueux, à lancer des opérations d'influence, à saboter le développement, voire à prendre le contrôle de projets open source.

Pour ce faire, les chercheurs utiliseront des outils tels que l'analyse des sentiments pour analyser les interactions sociales au sein des communautés open source telle que la liste de diffusion du noyau Linux, ce qui devrait permettre d'identifier qui est positif ou constructif et qui est négatif et destructeur. Les chercheurs veulent savoir quels types d'événements et de comportements peuvent perturber ou nuire aux communautés de logiciels libres, quels membres sont dignes de confiance et s'il existe des groupes particuliers qui justifient une vigilance accrue. Ces réponses sont nécessairement subjectives. Mais à l'heure actuelle, il existe peu de moyens de les trouver.

Les experts s'inquiètent du fait que les angles morts des personnes qui gèrent les logiciels libres rendent l'ensemble de l'édifice propice aux manipulations et aux attaques potentielles. Pour Bratus, la principale menace est la perspective de voir un « code non fiable » gérer les infrastructures critiques. Une situation qui pourrait réserver des fâcheuses surprises.

L'opportunité SocialCyber de l'AIE vise à explorer les capacités à détecter et à contrer les opérations cybersociales qui peuvent cibler les communautés de développeurs de logiciels libres. SocialCyber cherche à explorer des méthodes hybrides qui combinent des analyses du code source, des artefacts de communication liés au développement et des activités multimodales de médias sociaux liées au développement de logiciels libres afin de protéger l'intégrité de l'infrastructure de logiciels libres essentielle au DoD.

Source : DARPA

Et vous ?

Quel est votre avis sur le sujet ?

Ne serait-il pas exagéré de dire que les ordinateurs du monde entier sont construits sur le noyau Linux ?

Voir aussi :

41 % des entreprises n'ont pas une grande confiance dans la sécurité de leurs logiciels open source, leur utilisation généralisée entraînant des risques importants

La Maison Blanche, la Fondation Linux, OpenSSF et 37 entreprises technologiques ont annoncé un plan de sécurité des logiciels Open Source en 10 points, et un financement de 150 millions de dollars

Les vulnérabilités Open Source constituent des menaces pour la sécurité : 85 % des bases de code utilisent des composants dépassés, et 88 % des composants qui ne sont pas de la dernière version

Les développeurs Open source consacreraient moins de 3 % de leur temps à la sécurité, selon une nouvelle enquête de l'Open Source Security Foundation (OpenSSF) et du Laboratory for Innovation Science

[gabriel21]

Tiens le monde capitaliste et l'armée américaine s’aperçoivent que le logiciel libre, ce n'est pas juste des ressources à piller pour faire rapidement des logiciels.
Qu'utiliser des logiciels libres n'affranchit pas l'organisation d'avoir de bons architectes logiciels, des séries de test...
Que la revue de code et l'analyse du code en profondeur (surtout pour les infrastructures critiques) ne sont pas options.

Bon pour l'armée américaine, je suis médisant, elle est parfaitement consciente de cette situation et ceci depuis de nombreuses années. Son principal problème est que les politiques américain de tout bord d'ailleurs (pas la peine de rire, nous avons les mêmes en France) voient la sécurité informatique comme la dernière chose importante. Ils préfèrent de loin exhiber leur dernier porte avions à 20 milliard de dollars pièce (10 de prévu) ou leur chasseurs de dernière génération. Hors si l'on regarde bien, le rapport de la DARPA arrive maintenant, à l'heure où les administrations américaines finalisent leur budget pour l'année prochaine. Il s'agit donc pour l'armée américaine de fournir des raisons qui pourraient pousser le congrès à valider des budgets important pour la cyberdéfense, sans pour autant rogner sur le budget de fonctionnement ou celui de l'armement. La DARPA reste avant tout une organisation de recherche et non pas une organisation opérationnel. Son but est la compréhension ou la découverte en vue d'une utilisation par les unités opérationnelles. Après avoir financer de très nombreuses recherches matériels dont certaines sont intégrés dans les dernières unités construite, elle veut se réorienter sur des recherches plus logicielles. La pertinence de ce choix est à mettre en perspective avec les objectifs fixés à l'armée américaine et les problématiques remisent au gout de jour par les derniers conflits et notamment celui en Ukraine où très vraisemblablement de grosses batailles numérique se sont produites.

Certaines décisions politique prisent par les USA ont fait rejaillir le problème en le rendant public.

Maintenant une grosse partie des logiciels open source sont entre les mains de sociétés ou d'associations américaines. Ce qui veut dire qu'a court ou moyen terme, des décisions pénalement applicable, y compris pour les associations, risquent d'apparaître du type : interdiction à des personnes de tel ou tel pays de participer voir de télécharger, ou comme pour le matériel, interdiction aux entreprises et administrations américaines d'installer et d'utiliser tel ou tel produit open source.

[ManPaq]

Depuis les restrictions, la Russie est encouragée à violer les droits d'auteur et brevets afin d'entretenir un code de substitution efficace. La DARPA redoute t'elle un retour des sources dans son giron sous forme de logiciels libres où la part de chacun serait indiscernable et peut être meilleure qu'à l'origine du capitalisme soucieux de la propriété. Le problème dans l'économie est celui de la circulation de l'information sans le biais du profit, la propriété doit être la garantie du revenu maximisé et non la source d'un conflit d'intérêt où l'information est déformée au profit de la rentabilité.
Comment connaître les intentions du code sinon en le laissant libre mais réglementé, le danger provient davantage de l'intérêt né d'un conflit que de sa vocation économique respectueuse des lois du marché, même libre: Libre n'est pas synonyme de dérèglementé ni de gratuit.

[tabouret]

Bon pour l'armée américaine, je suis médisant, elle est parfaitement consciente de cette situation et ceci depuis de nombreuses années. Son principal problème est que les politiques américain de tout bord d'ailleurs (pas la peine de rire, nous avons les mêmes en France) voient la sécurité informatique comme la dernière chose importante. Ils préfèrent de loin exhiber leur dernier porte avions à 20 milliard de dollars pièce (10 de prévu) ou leur chasseurs de dernière génération. Hors si l'on regarde bien, le rapport de la DARPA arrive maintenant, à l'heure où les administrations américaines finalisent leur budget pour l'année prochaine. Il s'agit donc pour l'armée américaine de fournir des raisons qui pourraient pousser le congrès à valider des budgets important pour la cyberdéfense, sans pour autant rogner sur le budget de fonctionnement ou celui de l'armement. La DARPA reste avant tout une organisation de recherche et non pas une organisation opérationnel. Son but est la compréhension ou la découverte en vue d'une utilisation par les unités opérationnelles. Après avoir financer de très nombreuses recherches matériels dont certaines sont intégrés dans les dernières unités construite, elle veut se réorienter sur des recherches plus logicielles. La pertinence de ce choix est à mettre en perspective avec les objectifs fixés à l'armée américaine et les problématiques remisent au gout de jour par les derniers conflits et notamment celui en Ukraine où très vraisemblablement de grosses batailles numérique se sont produites.

Tu as tout resumé.