Transformation digitale: chronique d’une faillite annoncée?

Eric Filiol est scientifique de formation. Après 22 ans dans l'armée de terre française, où il a toujours fait de la recherche et de l’opérationnel, il a travaillé dans le domaine des technologies de l’information et dans le monde du renseignement. Titulaire d’un diplôme d’ingénieur en cryptologie (BESSSI), d’un doctorat en mathématiques appliquées et informatique de l’Ecole Polytechnique et d’une habilitation à diriger des recherches (HDR) en informatique de l’Université de Rennes, il possède également des qualifications OTAN dans le domaine du renseignement et d’Info Ops. Il est actuellement consultant expert dans le domaine de la protection de l'information et des systèmes.

© Pixabay

Depuis environ quatre ans, le monde industriel et les activités des services organisent leur «transformation digitale» à marche forcée pour certains, avec une relative réticence pour d’autres.

Qu’est-ce que la transformation digitale? Il s’agit en fait du processus d'adoption et de mise en œuvre de la technologie numérique par une entreprise afin de créer de nouveaux produits, de nouveaux services et opérations, de modifier ceux existants, en traduisant les processus d'entreprise dans un format numérique (passage au tout logiciel en fait).

Le CIPS (Chartered Institute of Procurement & Supply[1]) en donne une définition précise:

«Pratique consistant à redéfinir les modèles, les fonctions, les opérations, les processus et les activités en tirant parti des avancées technologiques pour créer un environnement commercial numérique efficace – un environnement dans lequel les gains (opérationnels et financiers) sont maximisés, et les coûts et les risques sont minimisés.»

Certains très grands constructeurs ne considèrent plus la voiture que comme le «véhicule» de captation de données

Si, dans beaucoup de cas, la motivation est de moderniser des activités traditionnelles dans l’espoir de les rendre à la fois plus efficaces et plus rentables, certaines entreprises y voient l’occasion de nouveaux Eldorados autour de la data. En effet, la transformation digitale, dont l’épine dorsale est le passage vers le tout logiciel ou du moins vers sa prééminence, cette transformation permet non seulement de capter plus efficacement la donnée mais aussi de la traiter rapidement et d’en faire un produit rentable. Un cas actuel, parmi les plus emblématiques mais aussi les plus préoccupants, est celui de l’industrie automobile. Certains très grands constructeurs, en particuliers européens, ne considèrent plus la voiture que comme le «véhicule» de captation sans précédent de données au profit d’une activité principale qui sera centrée sur la revente des données.

Cette transformation digitale s’accompagne d’un développement sans précédent des technologies cloud (cloud publics dans le plus grand nombre de cas, clouds privés pour les plus avisées des entreprises).

Le principal problème est que l’industrie logicielle actuelle va très mal par son incapacité désormais à maitriser la sécurité logicielle, la qualité du développement et les chaines de production (software supply chain). La transformation digitale aura pour effet, dans les prochaines années, de faire exploser[2] une production logicielle déjà à la peine avec des conséquences potentiellement graves sur la sécurité, la disponibilité et la fiabilité des activités qui en dépendent… du moins si aucune prise de conscience sur certains risques n’intervient de manière obligatoire (imposée par des lois et des réglementations sévères) et contrôlée de manière impitoyable par les Etats.

Détaillons ces risques et voyons quelles mesures efficaces doivent être prises rapidement.

Pénurie de développeurs… compétents

Cette pénurie a pris, surtout depuis la crise COVID, des proportions inquiétantes[3]. La transformation digitale va l’accélérer. Les raisons de cette pénurie sont multiples. Mais les principales sont une rémunération en berne, en tout cas ne correspondant pas à la qualification requise, un manque de considération, un management direct qui n’est souvent pas à la hauteur (rares sont les managers techniques qui ont gardé un lien avec la technique suffisant pour comprendre leurs équipes voire tout simplement ce en quoi consiste réellement le développement), un manque de féminisation qui devient handicapant[4]…

Mais le plus préoccupant est la dégradation des compétences des développeurs actuels et surtout ceux qui sont formés de nos jours. Être un bon développeur, capable de mettre en code des problèmes complexes, de manière efficace, est une compétence qui devient de plus en plus rare car elle demande une formation exigeante. La proportion des développeurs suffisamment compétents pour garantir la sécurité, la fiabilité, la frugalité, l’efficacité (notamment énergétique) des produits qu’ils développent s’amenuise d’année en année.

La faute principale en est à l’enseignement supérieur. Rares sont les cursus de formations (ingénieurs, développeurs) qui forment sérieusement à la formalisation puis l’algorithmique, à la programmation sécurisée et aux bons langages. Il est vrai que, pour ces derniers, la pression du monde industriel qui veut de plus en plus de développeurs, formés rapidement, influe de manière préjudiciable sur les cursus de l’enseignement supérieur. Alors que les systèmes d’exploitation sont majoritairement écrits en C et en C++, par exemple, ces deux langages sont de moins en moins (bien) enseignés au profit de langage plus rapides à enseigner comme Java ou Python[5]. Je suis toujours consterné de voir des programmes écrits comportant des failles de base ou qui sont lents et gourmands en ressources (temps exécution et mémoire) parce qu’algorithmiquement faibles.

De nos jours, 95% du développement logiciel consiste à faire du lego avec des briques vues comme des boites noires et les 5 autres% à concevoir ses propres briques… pour ceux des développeurs qui savent encore le faire (combien d’entre eux copient une bonne partie des codes qu’ils développent sur des sites comme stackoverflow.com, sans se poser de question sur la qualité de ces bouts de codes?). Le problème est que de moins en moins de développeurs savent et comprennent ce qu’il y a réellement dans les briques qu’ils manipulent (50% des ressources dockers contenaient des failles en 2020[6]) ou prennent le temps de se poser la question.

Sans une révolution dans les cursus d’enseignement vers plus de vertu dans le développement ou une (re)formation (upskilling) au sein même des entreprises, la situation ne fera qu’empirer. Les entreprises doivent aussi valoriser la qualité et la sécurité du développement.

Effondrement de la sécurité logicielle, explosion du nombre des failles

Conséquence de la situation précédente (absence de formation suffisante en programmation sécurisée) en partie, le nombre de failles – souvent critiques – augmente très régulièrement (en gros 25% par an) dont près de 30% sont critiques, voire très critiques. La qualité des processus de développement est très insuffisante chez pratiquement TOUS les acteurs du développement logiciel et les grands éditeurs. La seule exception notable concerne les secteurs à très fortes réglementation de sécurité (comme l’aéronautique), dans lesquels toute carence se traduit par des risques intolérables.

Microsoft nous a habitué, avec ses logiciels, à acheter des passoires et nous a fait accepter l’idée d’attendre les prochaines rustines qui boucheront les trous de sécurité qui seront découverts (souvent à l’issue d’une attaque). Tous les autres éditeurs lui ont emboité le pas. Tant que les Etats n’adopteront pas des réglementations contraignantes, ne poursuivrons pas les éditeurs (au civil voir au pénal[7]) et n’infligeront pas des amendes conséquentes, l’incurie continuera[8].

Le nombre de hackers augmente plus vite que le nombre de bons développeurs

Parallèlement et de manière étonnante, les compétences et les outils pour trouver ces failles (et les revendre plutôt que les corriger) se sont développés de manière rapide et importante. Techniques de fuzzing, de reverse engineering sont de mieux en mieux maitrisées par un nombre croissant de hackers dans le monde. Un produit comme Ghidra (outil libre de reverse engineering et de décompilation puissant publié par la NSA en 2019, permet un développement de compétences sans précédent en rétro-ingénierie logicielle). Avant Ghidra, le produit phare du marché (IDA Pro) était tellement cher que peu de gens pouvait y accéder. Le résultat est que le nombre de hackers capables d’analyser un programme, d’en trouver les failles augmente plus vite que le nombre de bons développeurs.

Faiblesse des processus et de la supply chain

L’industrie logicielle fonctionne autour du concept de software chaîne d'approvisionnement logicielle (software supply chain). Cela décrit une chaîne d'approvisionnement constituée des composants, des bibliothèques, des outils et des processus utilisés pour développer, construire et publier un artefact logiciel.

Les éditeurs de logiciels créent le plus souvent des produits en assemblant des composants logiciels libres et commerciaux. Ils sont tenus d’établir et de fournir une nomenclature logicielle détaillant (SBOM ou Software Bill of Materials) l'inventaire des composants utilisés pour construire un logiciel. Elle est analogue à une liste d'ingrédients sur un emballage alimentaire: alors que vous pouvez consulter une étiquette pour éviter les aliments susceptibles de provoquer des allergies, les SBOM peuvent aider les organisations ou les personnes à éviter d’utiliser ou d’intégrer des logiciels qui pourraient représenter un risque de sécurité.

Or, dans les faits, cette pratique est loin d’être généralisée et les tentatives de légiférer sur le sujet (essentiellement aux USA) ont relativement échoué. La gestion de la faille critique affectant le bout de code Log4j présent dans un très grand nombre de logiciels et environnements[9] illustre avec éclat l’impact d’un manque de traçabilité dans un développement logiciel. A ce jour, nombreuses sont les sociétés qui n’ont toujours pas achevé de gérer la faille Log4j qui date pourtant de 2021[10]. Et de nombreuses autres failles ne sont toujours pas gérées de manière satisfaisante[11].

L’article de Thomas Depierre résume parfaitement la situation (et le fait que l’industrie du logiciel utilise éhontément du logiciel libre pour lequel elle ne s’investit pas mais duquel elle tire de scandaleux profits).

Le second aspect important est le déploiement automatisé de ressources logicielles au sein des chaines de développement continu (chaine CI/CD)[12]. Cela concernait essentiellement le cloud mais de grandes infrastructures informatiques comportant des étages de développement logiciel sont également concernées. Là encore, à ce jour, les processus de passage en production ne sont pas à la hauteur des enjeux de sécurité: manque de formation, manque de définition, de documentation et de contrôles des processus, pression du delivery sur les contrôles de sécurité (qui sont vus comme un frein… ) Depuis deux ans, le gouvernement américain et l’Europe ont fait un effort de production documentaire significatif mais sans réel application par l’industrie logicielle[13].

Le troisième aspect est l’absence de sécurisation de la chaine de distribution logicielle. L’attaque de SolarWinds, révélée fin 2020, en est la parfaite et désespérante illustration[14]. Il est navrant de constater que la protection des ressources logicielles délivrées aux clients, ou de celles développées en interne ne font pas encore l’objet de la plus élémentaire protection ou d’une protection totalement désuète. J’ai encore constaté récemment, chez de très grands éditeurs, l’usage de fonction comme MD5 (dépréciée depuis près de 20 ans) pour contrôler l’intégrité de firmware[15] lors de processus de mise à jour. C’est totalement inadmissible.

Alors que les Etats (USA, Europe) tentent de mettre de l’ordre dans tout cela, l’industrie logiciel mondiale fait encore la sourde oreille. Là encore, sans mesure réglementaire coercitive, point de salut.

Conclusion

Quel avenir pour la transformation digitale? Il est difficile de le dire, mais il est important de comprendre que nous sommes à la croisée des chemins. Celle-ci impacte maintenant de manière tellement profonde la vie des citoyens et les fondements même de nos sociétés qu’il est urgent de regarder la réalité en face.

Il y a deux voies: celle qui consiste à penser que les IA génératives (comme ChatGPT) sont la solution et que ces IA écriront le code à la place des développeurs, feront les contrôles… bref remplaceront les humains, en se berçant d’illusions qu’elles s’amélioreront continuellement. Les premiers résultats scientifiques ont plutôt tendance à prouver le contraire.[16] Est-ce un pari raisonnable?

L’autre voie consiste à accompagner la transformation digitale par des réglementations fortes, contraignantes qui doivent s’imposer aux entreprises et éditeurs. Le marché ne peut plus dicter sa voie et les Etats doivent reprendre leur rôle prééminent. Autrement dit, la raison et la sécurité (des Etats, des citoyens) doit l’emporter sur les profits. Vaste programme.

---

Notes de bas de page

[1] https://www.cips.org/intelligence-hub/member-only/procurement-technology-digitalisation-guide

[2] Le mot explosion n’est pas exagéré. Ainsi sur le cloud Google, ce ne sont pas moins de 50 000 mise à jour quotidienne (fonctionnelles, de sécurité) qui peuvent être poussées soit près de 5 millions de de lignes de code par jour. Voir par exemple https://www.frenchweb.fr/ovhcloud-renonce-a-son-partenariat-avec-google-cloud/436740 [3] Voir par exemple pour les USA https://www.revelo.com/blog/software-developer-shortage-us ou https://www.forbes.com/sites/forbestechcouncil/2021/06/08/is-there-a-developer-shortage-yes-but-the-problem-is-more-complicated-than-it-looks/ et pour l’Europe https://www.cbi.eu/market-information/outsourcing-itobpo/software-development-services/market-potential

[4] Ayant enseigné la programmation et l’algorithmique pendant de nombreuses années, j’ai pu constater que les développeurs femmes apportaient souvent une vision plus mature et plus rigoureuse dans l’activité de développement que leurs camarades masculins. Force est de constater que le monde des développeurs, majoritairement masculin, manque souvent de maturité et de rigueur.

[5] Il est assez consternant que parmi les langages les plus “à la mode”, figurent ceux qui ont un impact écologique le plus mauvais (python par exemple). Voir l’étude publiée sur https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/paperSLE.pdf

[6] Voir par exemple https://link.springer.com/chapter/10.1007/978-3-030-71017-0_22, ou https://www.csoonline.com/article/570137/half-of-all-docker-hub-images-have-at-least-one-critical-vulnerability.html et https://uploads-ssl.webflow.com/609ccd86b14ba6e17f9fbce4/643ba6fc599bb82bfdea2456_Red_Kangaroo.pdf

[7] Les cas Solarwinds et Progress Software pourraient bien marquer un (heureux) précédent. Voir https://www.cpomagazine.com/cyber-security/what-the-secs-investigation-of-solarwinds-means-for-cisos-and-cybersecurity-disclosures/ et https://www.computerweekly.com/news/366555303/US-SEC-launches-probe-into-mass-MOVEit-breach [8] Il faut rester toutefois assez pessimiste sur la volonté des Etats de réellement changer les choses car la présence de failles récurrentes permettent aussi aux Etats de pouvoir rentrer dans des systèmes informatiques. Ainsi depuis près de 10 ans le marché des failles dites 0-Day (failles connues mais volontairement non corrigées pour les revendre au plus offrant, en particulier les services de renseignement) se développe de plus en plus : en 2015 sept entreprises dont la plus connue est zerodium (voir http://zerodium.com/program.html) occupaient ce marché. En 2023, ce sont au moins douze sociétés. A noter que le marché de ces failles est couvert par les accords de Wassenaar, accord gérant le contrôle des exportations d'armes conventionnelles et de biens et technologies à double usage (https://www.wassenaar.org). Voir https://cyberlaw.stanford.edu/publications/changes-export-control-arrangement-apply-computer-exploits-and-more. In fine, il est toujours plus facile d’invoquer l’incompétence des développeurs (et de ne rien faire pour qu’ils le soient moins) que de tenter d’introduire sciemment des failles.

[9] Actuellement curl (autre ressource libre présente dans de nombreuses applications pour la gestion des protocoles de communication réseau) illustre la même problématique.

[10] Voir https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-279a et https://www.darkreading.com/cloud/cybercriminals-can-earn-potentially-200k-monthly-exploiting-log4j-in-proxyjacking-attacks et le talk suivant https://pretalx.com/media/hack-lu-2023/submissions/USNSEZ/resources/HackLU-slidedeck-v04-light3reduced-Final_c52EhVv.pdf

[11] Voir https://www.csoonline.com/article/569717/the-state-of-application-security-what-the-statistics-tell-us.html

[12] L'approche CI/CD permet d'augmenter la fréquence de distribution des applications grâce à l'introduction de l'automatisation au niveau des étapes de développement des applications et passage en production. Les principaux concepts liés à l'approche CI/CD sont l'intégration continue, la distribution continue et le déploiement continu. Plus précisément, l'approche CI/CD est supposée garantir une automatisation et une surveillance continues tout au long du cycle de vie des applications, des phases d'intégration et de test jusqu'à la distribution et au déploiement. [13] Voir en particulier https://www.nccoe.nist.gov/sites/default/files/2021-10/03-jmartin-SAFECode-6-Pillars-of-DevSecOps.pdf, https://dodcio.defense.gov/Portals/0/Documents/Library/DoD%20Enterprise%20DevSecOps%20Strategy%20Guide_DoD-CIO_20211019.pdf, https://csrc.nist.gov/pubs/sp/800/204/d/ipd et https://csrc.nist.gov/Projects/ssdf et https://www.enisa.europa.eu/publications/good-practices-for-supply-chain-cybersecurity

[14] Voir également les rapports de l’ENISA https://www.enisa.europa.eu/publications/info-notes/supply-chain-attacks, https://www.enisa.europa.eu/publications/threat-landscape-for-supply-chain-attacks

[15] Un firmware est un bout de logiciel critique permettant à un système informatique de communiquer avec le matériel sur lequel il est installé. En contrôler l’intégrité consiste à vérifier qu’aucun attaquant ne l’a modifié (durant le cycle de vie de ce logiciel ) pour y introduire une ou plusieurs fonction malveillantes permettant ensuite de réaliser une attaque. [16] Voir par exemple https://www.sciencedirect.com/science/article/pii/S1877050921022134 ou https://www.theregister.com/2023/04/21/chatgpt_insecure_code/