Commentaire : Pendant des années, nous avons essayé d'aborder la sécurité au niveau de l'entreprise ou de l'organisation. Le nouveau projet Alpha-Omega semble adopter une véritable approche à l'échelle de l'industrie, et c'est prometteur.
La sécurité a toujours été un investissement peu sexy qui a tendance à avoir plus de sens avec le recul qu'avec la planification. Plus récemment, alors que les failles de sécurité sont devenues la norme quotidienne plutôt que l'exception occasionnelle, les entreprises et les projets open source ont commencé à faire de la sécurité une priorité, bien qu'elle fasse sans doute encore défaut dans nos processus de développement de logiciels.
Couverture de sécurité à lire absolument
Le problème de cette approche est qu'elle reste atomisée, fragmentée. Comme indiqué dans un article récent de ZDNet, "L'état de la sécurité est extrêmement inégal dans l'industrie, avec une assez bonne sécurité chez certains des meilleurs fournisseurs, mais la grande majorité... manque d'investissements de sécurité de base." Cela manque le point. La sécurité n'est pas quelque chose qu'une entreprise ou un projet peut faire seul. C'est intrinsèquement une affaire de communauté.
C'est pourquoi je trouve encourageantes certaines nouvelles récentes de la Linux Foundation (LF)… précisément parce qu'il ne s'agit pas de la Linux Foundation. Ou pas exclusivement, bien sûr.
L'actualité derrière l'actualité
Deux choses ont été annoncées. Premièrement, l'Open Source Security Foundation (OpenSSF), qui opère sous la LF, a ajouté 20 autres membres à sa liste. Que font ces membres ? Apparemment, ils "aident à identifier et à corriger les vulnérabilités de sécurité dans les logiciels open source et à développer des outils, des formations, des recherches, des meilleures pratiques et des pratiques de divulgation des vulnérabilités améliorés". En pratique, bon nombre de ces entreprises veulent simplement signaler leur souci de la sécurité, mais le vrai bien vient également de ces organisations.
Par exemple, je suppose que si l'OpenSSF compte maintenant 60 membres au total, la réalité probable est que quelques membres clés (pensez à Google et Microsoft dans ce cas) assigneront des développeurs à collaborer étroitement avec d'autres membres d'OpenSSF pour améliorer la sécurité autour de certains projets open source pour éviter des scénarios comme la vulnérabilité Log4j.
En d'autres termes, certaines organisations peuvent se permettre d'investir dans la sécurité et disposent des ressources expertes pour le faire. Tout le monde en profite lorsqu'il partage ouvertement ces informations dans un forum communautaire.
Le deuxième aspect de l'annonce LF est sans doute encore plus intéressant. OpenSSF a également annoncé le projet Alpha-Omega, un projet qui tente d'identifier toutes les bibliothèques et packages de logiciels open source les plus critiques et les plus fondamentaux au monde, de les auditer et de les prendre en charge si nécessaire. À partir de la version :
"Le projet améliore la sécurité de la chaîne d'approvisionnement OSS mondiale en travaillant avec les responsables du projet pour rechercher systématiquement de nouvelles vulnérabilités non encore découvertes dans le code open source et les corriger. "Alpha" travaillera avec les mainteneurs des projets open source les plus critiques pour les aider à identifier et à corriger les vulnérabilités de sécurité et à améliorer leur posture de sécurité. "Omega" identifiera au moins 10 000 projets OSS largement déployés dans lesquels il pourra appliquer une analyse de sécurité automatisée, une notation et des conseils de correction à leurs communautés de responsables open source."
Financé par un montant initial de 5 millions de dollars de Microsoft et Google, et soutenu par l'Université de Harvard et la LF, ce recensement des projets open source aide les entreprises à assembler leur nomenclature logicielle, comme l'exige le décret exécutif américain. Comme l'ont noté les auteurs du recensement, les listes qu'ils ont compilées "représentent notre meilleure estimation des packages FOSS [logiciels libres et open source] les plus largement utilisés par différentes applications, compte tenu des limites de temps et du large, mais non exhaustif , les données que nous avons agrégées."
C'est un début impressionnant pour un travail indispensable, et il n'est pas axé sur les projets logiciels d'une organisation en particulier.
Et c'est la vraie nouvelle. Pas le décret exécutif. Pas l'implication de Google/Microsoft. Pas même la LF qui s'attaque aux initiatives interprofessionnelles. Non, la vraie nouvelle est que la sécurité est plus importante que n'importe quelle organisation commerciale comme la LF. Ces 10 000 projets open-source que la LF aide à cataloguer ? La plupart ne relèvent pas de la compétence de la LF. Ou de Google. Ou de Microsoft. Ou [insérer le nom de toute organisation].
La sécurité concerne tout le monde, mais nous avons essayé de nous y attaquer au coup par coup. D'après un article rédigé par le responsable du projet Alpha-Omega et professeur à Harvard, Frank Nagle, beaucoup de travail est nécessaire pour améliorer la posture de sécurité des logiciels open source à travers les projets. Par exemple, il n'y a pas de schéma de nommage standard pour les projets open source, ce qui prête à confusion :"Il n'y a pas d'organisme centralisé pour coordonner les noms des composants FOSS, et il peut donc y avoir plusieurs composants qui ont le même nom mais qui ne sont pas le même composant." Nous avons montré que les développeurs open source peuvent résoudre rapidement les problèmes lorsqu'ils apparaissent (peut-être plus rapidement que n'importe qui d'autre), mais pouvons-nous nous unir pour structurer les projets de la même manière afin d'éviter certains problèmes de sécurité inutiles ?
Alpha-Omega est un bon début pour essayer de résoudre ces problèmes dans l'ensemble de l'industrie, plutôt qu'au coup par coup. Après Heartbleed, nous avions des ambitions similaires pour résoudre nos problèmes de sécurité. Espérons que cette fois ce soit vraiment différent... et communautaire.
Divulgation :je travaille pour MongoDB mais les opinions exprimées ici sont les miennes .
Lien source