Les temps ont changé dans l'industrie des logiciels. Les méthodes de management et meilleures pratiques utilisées il y a tout juste 10 ans ne suffisent plus pour se protéger des nouvelles menaces, notamment celles profitant de vulnérabilités inconnues. Aujourd'hui, les éditeurs peuvent même être contraints de retirer des produits rentables du marché.
Qu'est-ce qui a changé entre-temps ? Auparavant, chaque ligne de code était écrite intégralement, mais aujourd'hui, on fait davantage d'assemblage que d'écriture. Les développeurs créent ainsi des patchworks de composants tiers open source et commerciaux (les fameuses « bibliothèques ») d'origines et fonctions variées. Un certain nombre de règles et d'obligations doivent être respectées afin de pouvoir les utiliser en toute légalité. Ces règles constituent la licence des logiciels. En outre, avec le temps, des vulnérabilités sont découvertes, mettant alors en péril les entreprises ne faisant pas le nécessaire pour les mettre à jour ou résoudre les problèmes constatés.
Les risques concernant la sécurité et la conformité des composants open source et commerciaux atteignent des proportions incontrôlables, et menacent l'intégrité même de la chaîne d'approvisionnement de logiciels. La moitié du code au sein de la plupart des logiciels commerciaux provient d'éléments tiers. Cependant, la majorité des ingénieurs n'assurent aucun suivi de ces composants, et ignorent leurs obligations légales ou les vulnérabilités qu'ils peuvent contenir.
Un séjour dans l'inconnu
Pire, la plupart des responsables des logiciels n'ont aucune idée de ce qui se trame en coulisses. Et s'ils ignorent quels composants sont utilisés, il leur est impossible de garantir la mise en œuvre des processus et automatisations adaptés pour faire face aux risques auxquels ils sont exposés. Les dirigeants doivent donc absolument échanger avec leurs directeurs techniques, responsables de la sécurité et développeurs afin de comprendre où ils en sont vis-à-vis de la sécurité et de la conformité des composants utilisés.
Le secteur bancaire et financier
Tout ceci est particulièrement important dans le secteur bancaire et financier. Il va sans dire qu'une industrie gérant des centaines de milliards de dollars doit se tenir à l'abri des nouvelles menaces. Auparavant, les logiciels étaient développés ligne par ligne et fichier par fichier par des développeurs internes. Dans certains cas, quelques composants externes étaient introduits dans le produit.
Généralement par le biais d'un contrat commercial. Il était très facile pour les entreprises de savoir ce qu'elles avaient elles-mêmes écrit et ce qu'elles avaient acquis, étant donné qu'elles disposaient de documents, ainsi que de clés des licences à gérer. Mais au cours des dix dernières années, l'industrie des logiciels a énormément changé. La tendance est désormais à l'utilisation de grandes quantités de composants tiers, en particulier ceux venant du monde de l'open source. La disponibilité de millions de composants de haute qualité et gratuits permet aujourd'hui de créer des produits dont le code provient à plus de 50 % d'individus externes.
Tout ceci est arrivé trop vite pour que les dirigeants aient le temps d'adapter leurs meilleures pratiques. La plupart d'entre eux ignorent comment assurer la conformité de leur organisation vis-à-vis des réglementations. En outre, en l'absence du système adapté pour superviser les centaines de milliers de composants tiers utilisés (la « nomenclature »), impossible de savoir si l'on est affecté par une nouvelle vulnérabilité. Les attaques menées récemment sur le secteur financier ciblaient entre autres les composants open source OpenSSL et Struts 2. Bien que la plupart des organisations étaient sûres d'être affectées par ces vulnérabilités, elles étaient incapables de découvrir rapidement le produit concerné ou l'emplacement exact de la faille...
L'heure est à la sensibilisation
Il n'existe pas de solution miracle pour réussir. Cependant, quelle que soit l'approche choisie, il faudra mettre en place un programme de sensibilisation afin que chacun comprenne ce qu'implique l'utilisation de logiciels open source et tiers. Toute personne chargée de créer ou de gérer un logiciel devrait au moins avoir une connaissance passive des licences open source et des obligations de conformité, ainsi qu'une idée des processus et exigences de son entreprise. En effet, le déploiement ou la distribution de logiciels implique souvent de suivre une longue liste d'obligations (inclure des remerciements dans les fenêtres d'à propos, partager le code source utilisé pour développer l'application, etc.). Cependant, des données récentes montrent que la plupart des organisations échouent même sur les points de conformité de licences les plus basiques.
Comité de révision des composants open source
Quels que soient le niveau de sensibilisation et le temps réservé dans le calendrier de développement, certaines questions resteront sans réponse de la part des ingénieurs. Dans de pareils cas, un Comité de révision des composants open source (OSRB) pourra gérer les demandes d'assistance, et définir des stratégies favorisant une bonne utilisation de ces logiciels. En dépit de leur appellation, ces comités sont souvent chargés de gérer à la fois des composants tiers commerciaux et open source. Les OSRB regroupent généralement des membres des équipes juridiques, de développement, de sécurité, etc. En outre, ils peuvent aussi bien être des groupes peu organisés d'individus se réunissant ponctuellement que des équipes dédiées et parfaitement structurées.
Meilleures pratiques et obligations
Les connaissances obtenues doivent notamment permettre de confirmer le respect des meilleures pratiques et obligations. Il est en effet très important de confirmer que chaque application soit utilisée correctement et que sa situation en matière de licence soit connue. Les entreprises doivent également s'assurer d'utiliser la version la plus récente de chaque produit afin d'éviter toute vulnérabilité. La gestion des composants bien connus comme l'OpenSSL (dont les vulnérabilités sont révélées régulièrement) est un paramètre important pour rester en sécurité. Il est également essentiel de découvrir tous les éléments embarqués ainsi que les moins fréquents. Ce niveau de détail permet d'éviter les risques liés à chaque nouveau composant découvert.
Le secteur financier se doit également de suivre les réglementations et certifications de leurs produits. Nombre de ces éléments nécessitent une connaissance totale de l'auteur des logiciels et de la façon dont ils ont été assemblés. En effet, les chaînes d'approvisionnement se sont fortement allongées ces 10 dernières années, et il n'est pas toujours possible de tout documenter ou résoudre rapidement. Les entreprises peuvent même parfois se retrouver responsables de l'ensemble des problèmes de vulnérabilité et de conformité hérités de leurs partenaires en amont. En d'autres termes, elles sont les ultimes responsables.
En sensibilisant leurs développeurs, en assurant la bonne découverte de leurs dépendances tierces, et grâce à une gestion en continu de ces dépendances et de leurs potentielles vulnérabilités, les organisations pourront maîtriser les problèmes de sécurité et de conformité de leurs produits. En outre, elles seront plus à même de tirer parti des avantages de l'open source au-delà de la seule réduction des coûts.