Discussion :

[Sandra Coret]

Les développeurs open source consacreraient moins de 3 % de leur temps à la sécurité


La dernière enquête menée par l'Open Source Security Foundation (OpenSSF) et le Laboratory for Innovation Science de Harvard auprès des utilisateurs de FOSS (Free and Open Source Software) montre que les personnes interrogées consacrent en moyenne seulement 2,27 % de leur temps total à la sécurité et n'expriment guère le souhait d'augmenter ce temps.

L'enquête menée auprès de près de 1200 personnes travaillant sur des programmes open source montre que la majorité des répondants (74,87 %) sont déjà employés à plein temps et que plus de la moitié (51,65 %) sont spécifiquement payés pour développer des logiciels open source.


Les motivations pour contribuer à un logiciel open source sont axées sur l'ajout d'une fonctionnalité ou d'une correction nécessaire, le plaisir d'apprendre et la satisfaction d'un besoin de travail créatif ou agréable. Le pourcentage de personnes interrogées qui sont payées par leur employeur pour contribuer à des logiciels open source suggère un fort soutien à la stabilité et à la durabilité des projets open source, mais remet en question ce qui pourrait arriver si l'intérêt des entreprises pour un projet diminue ou cesse.

Parmi les personnes interrogées, 45,45 % se disent libres de contribuer au FOSS sans en demander la permission, contre seulement 35,84 % il y a dix ans. Cependant, 17,48 % des personnes interrogées déclarent que leur entreprise n'a pas de politique claire sur la possibilité de contribuer et 5,59 % ne savent pas quelle est la politique de leur employeur, le cas échéant.

"Comprendre les comportements des contributeurs aux logiciels open source, en particulier en ce qui concerne la sécurité, peut nous éclairer sur la manière dont nous appliquons les ressources et l'attention aux logiciels les plus utilisés dans le monde", déclare David Wheeler, directeur de la sécurité de la chaîne d'approvisionnement des logiciels open source à la Linux Foundation. "Il ressort clairement des conclusions de 2020 que nous avons du travail à faire pour garantir que nous employons du personnel à travers la communauté pour la sécurité et pour permettre aux individus de contribuer en toute confiance aux logiciels open source".

Source : The Linux Foundation blog

Et vous ?

Combien de temps consacrez-vous à la sécurité ?

[marc.collin]

Quel type de logiciel, taille du logiciel, logiciel critique, combien de personne sur le projet, est-ce qu'il y a des personnes dédié à la sécurité...

Concernant les logiciel propriétaire combien de temps est alloué à la sécurité?

Ça manque de précision.... on dirait un texte de propagande écrit par certain mvp...

[kain_tn]

Mouais... J'ai quand même l'impression que c'est plus lié au développement informatique en général qu'à l'Open Source vs. Propriétaire en particulier.
La plupart des clients que j'ai dans ma carrière (100% propriétaires d'ailleurs) ne s'intéressent que très peu à la sécurité, souvent vue comme un frein. C'est tout un chemin de croix de leur faire prendre conscience que ça doit être considéré dès le design. Et les conséquences chez les gros clients (type bancaire) c'est souvent la mise en place d'un modèle lourd, contre-productif et paranoïaque au lieu d'éduquer les développeurs.... J'

[walfrat]

Est-ce qu'ils en ont au moins la compétence ?

En outre acquérir de la compétence en sécurité prend beaucoup de temps, sur un domaine qui pardonne peu.

Et il s'avère aussi que notre tête n'a pas un espace de stockage infini. Un développeur qui vient proposer quelque chose pour aider les autres développeur est déjà bien occupé à faire en sorte que son truc marche et qu'ils soit robuste, et aussi à le faire évoluer selon les retours utilisateurs.

[Steinvikel]

Quand j'ai découvert en C++, après avoir parcouru la norme, que des mots clés /fonctions standards... présentaient des comportement non définis, j'ai tout de suite fait un rapprochement avec une faiblesse de sécurité, mais je n'ai pour l'heure actuelle encore rien trouvé sur une hypothétique liste exhaustive de ces éléments au comportement "non déterminé".

Ensuite, rien ne remplace les notions fondamentales, et connaître des exemples de mise en oeuvre pour CHAQUE aspect de CHAQUE notion. Une fois toutes les graines placés chez la personnes, elle est à même de les cultiver pour les faire grandir et se renforcer, sachant que certaines ne nécessitent aucun effort, se développant d'elles même par un simple esprit critique au fur et à mesure des expériences vécus (voir même, vécu par procuration).

Ce serait là, le moyen pour ces grandes entreprises, de débourser un minimum sur le long terme, tout en maximisant la qualité de l'effet --> former de manière proportionné leurs employés sur la sécurité.
...dépendra ensuite la priorité accordé à cet aspect dans la tâche globale de production.

[defZero]

Combien de temps consacrez-vous à la sécurité ?

"La" sécurité, ça veut tout et rien dire à la fois.
La sécurité est un domaine à part entière dans l'informatique et pourtant elle est peut voir pas du tout enseignée en tant que tel que ce soit au niveau réseau, DB, code de bonne conduite, pattern et architecture, ... etc.
Il faudrait vraiment qu'il y est des formations spécifiques pour chaques domaines et pas que ce soit enseigné à la marge.

Je pense comme tous les professionnels que le maillon faible de tous systèmes reste "entre la chaise et le clavier", donc vous pouvez blinder tout ce que vous voulez, le but d'un système est bien que quelqu'un y accède, donc on programme tous des failles in fine .

P.S. : Et dire qu'à l'émergence du code managé (et objet), c'était plutôt vendu comme moyen de réduire les risques, délais et coups de maintenances.
On voit comme ça à bien marché, merci les gars du marketing .
...[] -> suis sortie regarder mes codes procéduraux que je peux encore lire et comprendre 10 ans après les avoir écrit .

[Bardotj]

Faudrait déjà que les moyens automatiques d'un truc aussi essentiel que la sécurité ne soit soumis a la barrière de l'argent.

Gitlab et sonaqubes ne propose les scan de sécurité que dans les version entreprises de leurs softs.

[Hackcoeur inc]

Vous avez la réponse dans l'énoncé de l'article,

qui critique? Linux Foundation

qui a pris la direction de Linux Foundation ? Microsoft

Pour le reste pas de commentaire

[deathman8683]

Que les rouages soient ouverts ou privés n'indiquent en rien le niveau de sécurité d'un logiciel, si ce n'est que la sécurité du code privé, à l'abri de la critique, peut être moins dense que du gruyère alors même qu'aucun utilisateur ne s'en rendra compte, jusqu'à la catastrophe.

Un code ouvert (le vrai, celui qui, une fois compilé, offre la dernière release publique exploitable, pas comme une partie des produits Google) peut profiter d'un audit et d'un patch de la part de n'importe quel commanditaire : une grosse boîte (par ex Red Hat), la communauté d'une distribution open source (pas ex Debian) ou encore un utilisateur individuel compétant, pour le bénéfice de tout les utilisateurs. Sauf si le patcheur profite du fait que la licence du code ne lui impose pas de devoir diffuser publiquement le nouveau code pour le garder confidentiel, dans ce cas on retombe dans le code privé.

Finalement "open" ou "privé" ce n'est qu'une question de confiance de l'utilisateur envers le développeur (ou l'équipe d'une distribution Linux) à moins que l'utilisateur soit expert en sécurité, qu'il ait le temps et la capacité de vérifier des codes ouverts et de le compiler. Mais comment est-il possible, sachant que le modèle économique de l'open source est viable, de faire confiance en les compétences d'un développeur s'il décide de cacher son code ? Il est tentant de penser que c'est pour des raisons inavouables (code bâclé, code espion, code non sécurisé) bien qu'il faut l'avouer, ce type de développeur n'est peut-être pas habilité à travailler dans le monde open source et le connaît peut-être mal ou alors préfère se simplifier la vie quitte à fournir un code moins robuste (certains codes privés sont peut être issus d'une équipe consciencieuse mais on peut seulement en avoir une vague idée vu qu'on ne peut pas vérifier le code)