IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Sécurité Discussion :

La DARPA s'inquiète de la fiabilité du code open source


Sujet :

Sécurité

  1. #1
    Communiqués de presse

    Femme Profil pro
    Rédacteur technique
    Inscrit en
    mai 2018
    Messages
    1 505
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 32
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mai 2018
    Messages : 1 505
    Points : 47 878
    Points
    47 878
    Par défaut La DARPA s'inquiète de la fiabilité du code open source
    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.

    Nom : title-card-logo-black.png
Affichages : 983
Taille : 23,8 Ko

    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
    Publication de communiqués de presse en informatique. Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  2. #2
    Membre confirmé
    Profil pro
    Inscrit en
    juin 2006
    Messages
    128
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2006
    Messages : 128
    Points : 541
    Points
    541
    Par défaut
    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...

  3. #3
    Membre chevronné
    Profil pro
    Inscrit en
    juin 2009
    Messages
    655
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 655
    Points : 2 132
    Points
    2 132
    Par défaut
    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.

  4. #4
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Lead dév - Architecte
    Inscrit en
    août 2003
    Messages
    6 608
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Lead dév - Architecte
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 6 608
    Points : 19 693
    Points
    19 693
    Par défaut
    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.
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  5. #5
    Expert confirmé Avatar de marsupial
    Homme Profil pro
    Retraité
    Inscrit en
    mars 2014
    Messages
    1 491
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : mars 2014
    Messages : 1 491
    Points : 5 799
    Points
    5 799
    Par défaut
    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
    Repeat after me
    Le monsieur lutte pour la défense des libertés individuelles et collectives

    Repeat after me...

  6. #6
    Membre chevronné

    Profil pro
    Chef de Projet / Développeur
    Inscrit en
    juin 2002
    Messages
    548
    Détails du profil
    Informations personnelles :
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Chef de Projet / Développeur
    Secteur : Santé

    Informations forums :
    Inscription : juin 2002
    Messages : 548
    Points : 1 764
    Points
    1 764
    Par défaut
    Citation Envoyé par walfrat Voir le message
    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

  7. #7
    Membre chevronné

    Profil pro
    Chef de Projet / Développeur
    Inscrit en
    juin 2002
    Messages
    548
    Détails du profil
    Informations personnelles :
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Chef de Projet / Développeur
    Secteur : Santé

    Informations forums :
    Inscription : juin 2002
    Messages : 548
    Points : 1 764
    Points
    1 764
    Par défaut
    Citation Envoyé par marsupial Voir le message
    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.


    Citation Envoyé par marsupial Voir le message
    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.

    Citation Envoyé par marsupial Voir le message
    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).
    --
    vanquish

  8. #8
    Expert confirmé Avatar de marsupial
    Homme Profil pro
    Retraité
    Inscrit en
    mars 2014
    Messages
    1 491
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : mars 2014
    Messages : 1 491
    Points : 5 799
    Points
    5 799
    Par défaut
    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.
    Repeat after me
    Le monsieur lutte pour la défense des libertés individuelles et collectives

    Repeat after me...

  9. #9
    Membre extrêmement actif
    Profil pro
    Inscrit en
    juin 2010
    Messages
    782
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2010
    Messages : 782
    Points : 962
    Points
    962
    Par défaut
    Citation Envoyé par marsupial Voir le message
    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...

  10. #10
    Membre chevronné
    Homme Profil pro
    Développeur
    Inscrit en
    août 2003
    Messages
    759
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : août 2003
    Messages : 759
    Points : 2 055
    Points
    2 055
    Par défaut
    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.

  11. #11
    Chroniqueur Actualités
    Avatar de Bruno
    Homme Profil pro
    Rédacteur technique
    Inscrit en
    mai 2019
    Messages
    917
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : mai 2019
    Messages : 917
    Points : 10 949
    Points
    10 949
    Par défaut La DARPA s'inquiète de la fiabilité du code open source
    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. »

    Nom : open source.png
Affichages : 8067
Taille : 13,0 Ko

    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.

    Nom : darpa.png
Affichages : 2448
Taille : 15,5 Ko

    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
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  12. #12
    Membre expérimenté Avatar de gabriel21
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    février 2007
    Messages
    399
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : février 2007
    Messages : 399
    Points : 1 442
    Points
    1 442
    Par défaut
    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.
    "Les cons, ça ose tout. C'est même à ça qu'on les reconnaît." Michel Audiard - Les tontons flingueurs

Discussions similaires

  1. Réponses: 0
    Dernier message: 10/03/2022, 11h07
  2. Réponses: 1
    Dernier message: 20/12/2021, 15h53
  3. Réponses: 0
    Dernier message: 29/04/2021, 17h42
  4. Réponses: 1
    Dernier message: 17/04/2019, 22h28
  5. Réponses: 0
    Dernier message: 19/07/2017, 18h54

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo