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

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Sandra Coret

6PARTAGES

12  0 
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de gabriel21
Membre chevronné https://www.developpez.com
Le 17/07/2022 à 11:25
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.
12  2 
Avatar de herr_wann
Membre confirmé https://www.developpez.com
Le 15/07/2022 à 9:18
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...
7  0 
Avatar de walfrat
Membre émérite https://www.developpez.com
Le 15/07/2022 à 9:26
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.
6  0 
Avatar de grunk
Modérateur https://www.developpez.com
Le 15/07/2022 à 9:34
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.
5  1 
Avatar de marsupial
Expert éminent https://www.developpez.com
Le 15/07/2022 à 10:21
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
3  0 
Avatar de marsupial
Expert éminent https://www.developpez.com
Le 15/07/2022 à 12:47
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.
2  0 
Avatar de redcurve
Membre extrêmement actif https://www.developpez.com
Le 15/07/2022 à 16:11
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...
2  0 
Avatar de vanquish
Membre chevronné https://www.developpez.com
Le 15/07/2022 à 11:32
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.
1  0 
Avatar de vanquish
Membre chevronné https://www.developpez.com
Le 15/07/2022 à 11:58
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).
1  0 
Avatar de smarties
Expert confirmé https://www.developpez.com
Le 16/07/2022 à 18:46
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.
0  0