Évolution de la sécurité des OSPO : le modèle de Kübler-Ross appliqué à l’open source

Que trouve-t-on dans un OSPO ? Les bureaux des programmes open source se multiplient, car les faits sont là : les logiciels open source (et, j’ajouterais, les normes ouvertes) jouent un rôle majeur dans la création et la maintenance des logiciels qui font de plus en plus tourner la planète. Le rapport de la Linux Foundation, The Evolution of the Open Source Program Office (OSPO), décrit cinq étapes de développement d’un OSPO :

• Étape 0 : adopter l’open source au cas par cas

• Étape 1 : assurer la conformité OSS, gérer l’inventaire et former les développeurs

• Étape 2 : promouvoir l’usage de l’OSS et la participation à son écosystème

• Étape 3 : héberger des projets OSS et développer des communautés

• Étape 4 : devenir un partenaire stratégique de la prise de décision

Mais, pour ce qui est de la sécurité, il peut être plus instructif de s’intéresser à cinq autres étapes (à la manière du modèle de Kübler-Ross) :

• Déni : les organisations nient l’ampleur de leur dépendance à l’open source. Elles pensent peut-être en avoir conscience, mais dès qu’elles s’y penchent vraiment, elles réalisent à quel point elles s’appuient sur un vaste éventail de code et d’outils open source, en particulier dans leur pipeline de build. Consultez le 2022 Snyk Open Source Security Report pour en savoir plus.

• Colère : faute d’y avoir prêté attention, les organisations ne savent même pas quelle quantité de code open source elles utilisent. Cette colère les pousse (espérons-le) à s’informer frénétiquement et à recenser leurs projets open source, puis à prendre davantage conscience de la place centrale de l’OSS dans leur organisation.

• Négociation : c’est à ce stade que les organisations commencent à dialoguer avec la communauté OSS et à la solliciter, en tirant souvent parti des connaissances acquises grâce à une participation ponctuelle et en cherchant à inscrire cette participation dans une stratégie cohérente.

• Dépression : à ce stade, la réalité s’impose, à mesure que d’autres parties de l’organisation prennent conscience de la valeur de l’OSPO. Ce qui devrait être une bonne nouvelle, non ? Malheureusement, c’est aussi le moment où l’on réalise que les dépendances OSS font peser un risque sur toute l’organisation, surtout si l’on tient compte des vulnérabilités de sécurité.

• Acceptation : accepter pleinement que nous vivons dans un écosystème open source, c’est apprendre à y jouer un rôle de premier plan et reconnaître que l’OSPO doit être à la fois un centre d’excellence des écosystèmes ouverts et un centre d’excellence en sécurité.

D’accord, le parallèle ci-dessus est un peu tiré par les cheveux. L’essentiel, c’est que l’open source est là pour durer. Il joue un rôle très important dans la création et la maintenance de la grande majorité des logiciels, en particulier ceux que nous utilisons au quotidien. L’open source implique de céder une partie du contrôle à la communauté, en échange d’une meilleure qualité et de coûts d’exploitation réduits. Les organisations qui acceptent cette réalité et commencent à jouer un rôle de premier plan dans cette communauté deviendront des leaders du marché. La sécurité en est un élément clé.

Alors, comment les OSPO peuvent-ils jouer pleinement leur rôle, non seulement comme promoteurs de l’ouverture, mais aussi comme champions de la sécurité ? Tout d’abord, en intégrant des compétences en sécurité à l’équipe OSPO. Recrutez une personne experte en sécurité qui connaît bien les enjeux de la chaîne logistique logicielle. Participer au groupe de travail « End User » de l’Open Source Security Foundation permet de partager des informations en toute sécurité avec d’autres organisations similaires.

Les ressources récemment publiées par l’Open Source Security Foundation (OpenSSF) constituent un excellent point de départ.

• Guide concis pour développer des logiciels plus sûrs

• Guide concis pour évaluer les logiciels open source

• Guide des bonnes pratiques npm

Toutes ces ressources de l’OpenSSF aident à mieux comprendre les enjeux complexes de la sécurité de l’open source. Si vous créez un OSPO ou une fonction similaire au sein d’une organisation, quelle que soit sa taille, certains des sujets abordés dans ces guides vous seront immédiatement familiers. Votre organisation utilise probablement npm. Votre code est hébergé dans des systèmes de gestion de code source tels que GitHub. Vous utilisez des logiciels open source provenant de différentes sources, assortis de licences et d’antécédents variés. Ces guides abordent tous ces sujets et proposent des liens vers des informations plus détaillées.

Ensuite, les OSPO doivent recruter des spécialistes de la sécurité ou faire appel à des experts pour anticiper ces problèmes. Il est temps de réfléchir à la nomenclature des composants logiciels (SBOM) dans le cadre des processus de développement, de build et de déploiement. Liran Tal a publié un excellent article de blog sur les SBOM pour vous aider à démarrer.

À ce propos, il est intéressant et encourageant de voir que la législation américaine visant à sécuriser les logiciels open source utilisés pour développer et exploiter les services publics appelle à la création d’OSPO au sein des agences gouvernementales.

À une année 2023 sûre (et ouverte) !