{"id":167273,"date":"2026-10-22T11:19:12","date_gmt":"2026-10-22T09:19:12","guid":{"rendered":"https:\/\/e3mag.com\/?p=167273"},"modified":"2026-10-22T11:19:17","modified_gmt":"2026-10-22T09:19:17","slug":"lightwell-et-sap-quand-un-simple-correctif-ne-suffit-pas","status":"publish","type":"post","link":"https:\/\/e3mag.com\/fr\/lightwell-und-sap-wenn-patchen-allein-nicht-reicht\/","title":{"rendered":"Lightwell et SAP : quand les correctifs ne suffisent pas \u00e0 eux seuls"},"content":{"rendered":"

L'open source est d\u00e9sormais indissociable des applications d'entreprise modernes. Cela vaut \u00e9galement pour les environnements SAP, m\u00eame si le logiciel utilis\u00e9 ne repr\u00e9sente qu'une partie de l'ensemble de la pile technologique. En effet, ces syst\u00e8mes s\u2019accompagnent de plateformes d\u2019int\u00e9gration, de d\u00e9veloppements internes, de solutions d\u2019automatisation, d\u2019interfaces, d\u2019outils de surveillance et de nombreuses autres applications, dont beaucoup reposent sur des composants open source ou en int\u00e8grent en tant que d\u00e9pendances. Il en r\u00e9sulte une cha\u00eene logistique logicielle nettement plus vaste que le produit SAP proprement dit.<\/p>\n\n\n\n

Pour la s\u00e9curit\u00e9 informatique, il s'agit d'un probl\u00e8me majeur que les processus classiques de gestion des vuln\u00e9rabilit\u00e9s ne r\u00e9solvent que partiellement. Un scanner d\u00e9tecte une version vuln\u00e9rable et le fabricant ou la communaut\u00e9 open source met \u00e0 disposition une version corrig\u00e9e. Techniquement, la faille serait ainsi corrig\u00e9e, mais sur le plan op\u00e9rationnel, l'affaire est loin d'\u00eatre r\u00e9gl\u00e9e. En effet, la nouvelle version n'est pas n\u00e9cessairement compatible avec les syst\u00e8mes existants.<\/p>\n\n\n\n

Une mise \u00e0 niveau peut modifier les API, remplacer des d\u00e9pendances transitives, provoquer des r\u00e9gressions ou n\u00e9cessiter une nouvelle certification. Dans le cas d\u2019une application critique pour l\u2019entreprise, il est donc important non seulement de savoir si un correctif est disponible, mais aussi comment l\u2019int\u00e9grer \u00e0 la version existante du logiciel. Comme de nombreuses entreprises redoutent ce risque ou ne souhaitent pas le prendre, les vuln\u00e9rabilit\u00e9s connues restent donc sans solution, s\u2019accumulent sous forme d\u2019exceptions de s\u00e9curit\u00e9 \u00e0 long terme ou n\u00e9cessitent des correctifs propri\u00e9taires co\u00fbteux et des branches (forks).<\/p>\n\n\n\n

<\/div>\n\n\n\n

Ce moment mythique nous oblige \u00e0 repenser notre fa\u00e7on de voir les choses<\/h2>\n\n\n\n

Cette \u00e9volution s'acc\u00e9l\u00e8re consid\u00e9rablement avec l'intelligence artificielle. Dans le cadre du projet Glasswing d'Anthropic, le mod\u00e8le Mythos Preview a permis de d\u00e9tecter des milliers de failles de s\u00e9curit\u00e9 dans des logiciels open source, dont pr\u00e8s de 3 900 failles de gravit\u00e9 \u00e9lev\u00e9e ou critique. L\u2019IA est capable d\u2019analyser du code \u00e0 une vitesse impossible \u00e0 atteindre avec les m\u00e9thodes manuelles traditionnelles. Cela modifie \u00e9galement la dynamique des failles \u00ab zero-day \u00bb : plus les surfaces d\u2019attaque potentielles sont identifi\u00e9es rapidement, plus la fen\u00eatre temporelle pour les corriger se referme vite. Pour une entreprise prise isol\u00e9ment, il est pratiquement impossible d\u2019\u00e9valuer et de hi\u00e9rarchiser elle-m\u00eame chaque vuln\u00e9rabilit\u00e9 d\u00e9tect\u00e9e. Cela aggrave \u00e0 son tour le probl\u00e8me du \u00ab remediation gap \u00bb. Des semaines, voire des mois, peuvent s\u2019\u00e9couler entre la d\u00e9couverte d\u2019une faille de s\u00e9curit\u00e9 et sa correction effective dans une application en production. Pendant ce temps, les entreprises se retrouvent soit avec une faille connue, soit oblig\u00e9es de g\u00e9rer leurs propres correctifs, soit confront\u00e9es \u00e0 la d\u00e9cision de proc\u00e9der \u00e0 une mise \u00e0 niveau risqu\u00e9e.<\/p>\n\n\n\n

<\/div>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Du scanner au syst\u00e8me en production : entre l'identification d'une vuln\u00e9rabilit\u00e9 et son d\u00e9ploiement, il y a l'analyse, la correction, la compilation, les tests et la validation \u2013 ce qui prend beaucoup de temps. (Source : Red Hat)<\/em><\/figcaption><\/figure>\n\n\n\n

Mais les \u201e anciennes \u201c vuln\u00e9rabilit\u00e9s restent \u00e9galement un probl\u00e8me. Log4Shell en est un exemple particuli\u00e8rement frappant. Cette faille de s\u00e9curit\u00e9 dans la biblioth\u00e8que Java Apache Log4j, tr\u00e8s r\u00e9pandue, a \u00e9t\u00e9 rendue publique fin 2021 et class\u00e9e comme critique. Les applications utilisant une version vuln\u00e9rable et non mise \u00e0 jour de cette biblioth\u00e8que ont \u00e9t\u00e9 touch\u00e9es. Dans certaines conditions, des pirates pouvaient l\u2019exploiter pour ex\u00e9cuter \u00e0 distance du code malveillant et obtenir ainsi un acc\u00e8s \u00e9tendu aux syst\u00e8mes concern\u00e9s. M\u00eame si Log4Shell est g\u00e9n\u00e9ralement corrig\u00e9 sur les syst\u00e8mes importants, les d\u00e9pendances Log4Shell obsol\u00e8tes \u2013 et donc oubli\u00e9es \u2013 dans la cha\u00eene d\u2019approvisionnement logicielle continuent de pr\u00e9senter d\u2019\u00e9normes vuln\u00e9rabilit\u00e9s.<\/p>\n\n\n\n

\u00c0 cela s'ajoute le fait qu'une mise \u00e0 jour de s\u00e9curit\u00e9 mise \u00e0 disposition ne suffit pas \u00e0 elle seule. Le chemin menant du correctif \u00e0 la mise en production est souvent sem\u00e9 d'emb\u00fbches : l'application doit \u00eatre recompil\u00e9e, des tests automatis\u00e9s et manuels doivent \u00eatre effectu\u00e9s, les d\u00e9pendances doivent \u00eatre v\u00e9rifi\u00e9es et les modifications doivent \u00eatre valid\u00e9es. Pour les applications critiques, il faut parfois compter en plus des validations techniques, des exigences de conformit\u00e9 ou des processus de changement formels. La rapidit\u00e9 des processus en aval devient donc un facteur essentiel. Une entreprise peut avoir acc\u00e8s \u00e0 une nouvelle mise \u00e0 jour de s\u00e9curit\u00e9 aussi rapidement qu\u2019elle le souhaite : si le processus interne de compilation et de d\u00e9ploiement prend plusieurs semaines, voire plusieurs mois, la vuln\u00e9rabilit\u00e9 persiste pendant tout ce temps, voire n\u2019est tout simplement pas trait\u00e9e.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Lightwell : correctif de s\u00e9curit\u00e9 au lieu d'un changement de version impos\u00e9<\/h2>\n\n\n\n

C'est pr\u00e9cis\u00e9ment cette lacune que comble Lightwell, une initiative conjointe de Red Hat et d'IBM visant \u00e0 s\u00e9curiser la cha\u00eene d'approvisionnement des logiciels open source. Ce concept s'appuie sur un principe que Red Hat applique depuis des d\u00e9cennies dans le domaine des logiciels d'entreprise : les correctifs de s\u00e9curit\u00e9 ne sont pas n\u00e9cessairement fournis via un saut de version complet, mais peuvent \u00eatre r\u00e9troport\u00e9s de mani\u00e8re cibl\u00e9e vers une version toujours prise en charge. L'objectif est d'int\u00e9grer la modification li\u00e9e \u00e0 la s\u00e9curit\u00e9 sans imposer pour autant un changement inutile au niveau des fonctionnalit\u00e9s ou de l'API. Pour les entreprises, c'est un aspect important : un backport corrige la faille de s\u00e9curit\u00e9 sans modifier automatiquement l'ensemble de la structure des d\u00e9pendances de l'application.<\/p>\n\n\n\n

La diff\u00e9rence par rapport \u00e0 un fork manuel est ici \u00e9norme. Une entreprise pourrait certes, en th\u00e9orie, copier le code source d\u2019une biblioth\u00e8que concern\u00e9e, appliquer le correctif et cr\u00e9er son propre artefact. Mais cela impliquerait \u00e9galement d\u2019assumer de mani\u00e8re permanente la responsabilit\u00e9 de cette fourche : processus de compilation, signature, d\u00e9pendances, correctifs de s\u00e9curit\u00e9 suppl\u00e9mentaires, documentation et, le cas \u00e9ch\u00e9ant, r\u00e9int\u00e9gration ult\u00e9rieure dans le code en amont. Une autre diff\u00e9rence par rapport \u00e0 la gestion traditionnelle des correctifs r\u00e9side dans ce qui se passe apr\u00e8s l\u2019application de la mise \u00e0 jour. Dans une cha\u00eene logistique logicielle moderne, il ne suffit plus de mettre \u00e0 disposition un nouveau fichier JAR. Les entreprises doivent pouvoir retracer ce qu\u2019elles utilisent, d\u2019o\u00f9 cela provient, comment cela a \u00e9t\u00e9 construit et quelles informations de s\u00e9curit\u00e9 y sont associ\u00e9es.<\/p>\n\n\n\n

<\/div>\n\n\n\n
\n

Les entreprises disposent de trois options pour corriger les vuln\u00e9rabilit\u00e9s :<\/h2>\n\n\n\n
    \n
  1. Mise \u00e0 niveau classique :<\/strong> L'application adopte une version plus r\u00e9cente de la d\u00e9pendance et accepte les efforts li\u00e9s \u00e0 la compatibilit\u00e9 et aux tests que cela implique.<\/li>\n\n\n\n
  2. Accepter le risque ou appliquer soi-m\u00eame le correctif :<\/strong> L'organisation conserve la version actuelle et met en place, si n\u00e9cessaire, sa propre solution de contournement ou son propre fork.<\/li>\n\n\n\n
  3. Backporting cibl\u00e9 :<\/strong> Le correctif de s\u00e9curit\u00e9 est port\u00e9 sur la version en production et int\u00e9gr\u00e9 dans la cha\u00eene logistique existante sous forme d'artefact contr\u00f4l\u00e9, sans qu'il soit n\u00e9cessaire de modifier l'application.<\/li>\n<\/ol>\n\n\n\n

    Le choix de la variante la plus appropri\u00e9e d\u00e9pend de l'application, du profil de risque et du mod\u00e8le d'exploitation. Lightwell \u00e9largit ainsi l'\u00e9ventail des solutions techniques en proposant une option particuli\u00e8rement pertinente pour les applications stables, durables et difficilement modifiables.<\/p>\n<\/div><\/div>\n\n\n\n

    <\/div>\n\n\n\n

    Lightwell fournit donc non seulement des artefacts corrig\u00e9s et sign\u00e9s, mais aussi des m\u00e9tadonn\u00e9es relatives \u00e0 la cha\u00eene d'approvisionnement. Celles-ci comprennent notamment les nomenclatures logicielles (SBOM), la provenance SLSA de niveau 3 ainsi que les signatures via Sigstore ou Cosign. Cela rev\u00eat une importance particuli\u00e8re pour les clients SAP, car, comme indiqu\u00e9 pr\u00e9c\u00e9demment, la d\u00e9pendance \u00e0 l\u2019open source ne s\u2019arr\u00eate pas aux limites du syst\u00e8me SAP. Dans un environnement d\u2019int\u00e9gration, les biblioth\u00e8ques Java, les composants de messagerie, les API, les conteneurs, les outils de build ou les frameworks d\u2019IA peuvent faire partie du syst\u00e8me global. Une SBOM rend ces composants visibles sous une forme lisible par machine. VEX (Vulnerability Exploitability Exchange) va m\u00eame encore plus loin.<\/p>\n\n\n\n

    Une SBOM r\u00e9pond essentiellement \u00e0 la question de savoir quels composants sont pr\u00e9sents. VEX peut fournir des informations compl\u00e9mentaires permettant de d\u00e9terminer si et dans quelle mesure un logiciel est r\u00e9ellement affect\u00e9 par une vuln\u00e9rabilit\u00e9 donn\u00e9e. Pour les entreprises soumises \u00e0 une r\u00e9glementation, cela rev\u00eat une importance cruciale. Les exigences issues de la DORA, de la directive NIS2 ou de la loi sur la cyber-r\u00e9silience (Cyber Resilience Act) renforcent la pression pour documenter de mani\u00e8re tra\u00e7able les composants logiciels, les vuln\u00e9rabilit\u00e9s et leur traitement. Lightwell met \u00e0 disposition ces informations avec les artefacts, ce qui \u00e9vite de devoir les rassembler manuellement a posteriori \u00e0 partir de diff\u00e9rentes sources.<\/p>\n\n\n\n

    Ces \u00e9l\u00e9ments v\u00e9rifiables relatifs \u00e0 la cha\u00eene d'approvisionnement et \u00e0 la construction sont \u00e9galement pertinents au regard des futures exigences europ\u00e9ennes en mati\u00e8re de certification et de conformit\u00e9, ou de celles \u00e0 caract\u00e8re volontaire, telles que l'EUCS (European Cybersecurity Certification Scheme for Cloud Services) ou l'EUCC (European Common Criteria-based Cybersecurity Certification Scheme).<\/p>\n\n\n\n

    <\/div>\n\n\n\n

    Deux versions adapt\u00e9es \u00e0 diff\u00e9rents besoins<\/h2>\n\n\n\n

    De plus, Lightwell ne se limite pas au correctif final. Ce mod\u00e8le combine un tri assist\u00e9 par l\u2019IA \u00e0 l\u2019expertise humaine en ing\u00e9nierie. L\u2019IA aide \u00e0 g\u00e9rer le flux massif de CVE en analysant les vuln\u00e9rabilit\u00e9s en quelques secondes, en \u00e9valuant leur pertinence et en proposant des correctifs possibles. Les modifications qui en r\u00e9sultent sont ensuite test\u00e9es de mani\u00e8re automatis\u00e9e et valid\u00e9es par des experts humains \u2013 plus pr\u00e9cis\u00e9ment par plus de 20 000 techniciens de Red Hat et d\u2019IBM \u2013 avant d\u2019\u00eatre mises \u00e0 disposition sous forme d\u2019artefacts. Les correctifs d\u00e9velopp\u00e9s ne sont pas seulement mis \u00e0 la disposition des clients, mais sont \u00e9galement restitu\u00e9s aux projets d\u2019origine, dans l\u2019esprit de la communaut\u00e9 open source, afin que l\u2019ensemble du secteur puisse en b\u00e9n\u00e9ficier.<\/p>\n\n\n\n

    Dans un premier temps, l'\u00e9cosyst\u00e8me Lightwell se concentre sur Maven\/Java. Cela pr\u00e9sente un int\u00e9r\u00eat particulier pour les clients SAP, car les applications Java s'approvisionnent souvent en d\u00e9pendances via des r\u00e9f\u00e9rentiels Maven et jouent un r\u00f4le dans de nombreux sc\u00e9narios d'int\u00e9gration, de middleware et d'applications propres aux clients. Dans le m\u00eame temps, Java n\u2019est qu\u2019un d\u00e9but. Lightwell doit \u00eatre \u00e9tendu \u00e0 d\u2019autres \u00e9cosyst\u00e8mes tels que PyPI, npm et Go afin de r\u00e9pondre aux exigences des secteurs r\u00e9glement\u00e9s, dans lesquels la gestion des versions fixes ou \u00ab pin\u00e9es \u00bb rev\u00eat une importance particuli\u00e8re. La solution est actuellement disponible en deux versions diff\u00e9rentes.<\/p>\n\n\n\n

    <\/div>\n\n\n\n
    \n

    Lightwell ne remplace pas :<\/h2>\n\n\n\n