{"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-and-sap-when-patching-alone-isnt-enough","status":"publish","type":"post","link":"https:\/\/e3mag.com\/en\/lightwell-und-sap-wenn-patchen-allein-nicht-reicht\/","title":{"rendered":"Lightwell and SAP: When Patching Alone Isn't Enough"},"content":{"rendered":"

Open source has become an integral part of modern enterprise applications. This also applies to SAP environments, even if the software used constitutes only a portion of the overall technology stack. This is because the systems are surrounded by integration platforms, in-house developments, automation solutions, interfaces, monitoring tools, and numerous other applications\u2014many of which are based on open-source components or incorporate them as dependencies. This creates a software supply chain that is significantly larger than the actual SAP product.<\/p>\n\n\n\n

This is a major problem for IT security, one that traditional vulnerability management processes only partially address. A scanner detects a vulnerable version, and the vendor or the open-source community provides a fixed version. Technically, this would resolve the vulnerability, but from an operational standpoint, the issue is far from resolved. This is because the new version may not necessarily be compatible with existing systems.<\/p>\n\n\n\n

An upgrade can change APIs, replace transitive dependencies, cause regressions, or require recertification. For a business-critical application, it is therefore not only important whether a fix is available, but also how it can be integrated into the existing software version. Since many companies shy away from this risk or are unwilling to take it, known vulnerabilities consequently remain unresolved, accumulate as long-term security exceptions, or require costly, proprietary patches and forks.<\/p>\n\n\n\n

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

The \"Myth Moment\" Forces a Change in Thinking<\/h2>\n\n\n\n

This trend is accelerating rapidly with the advent of artificial intelligence. As part of Anthropic\u2019s Glasswing project, the Mythos Preview model was used to detect thousands of security vulnerabilities in open-source software\u2014including nearly 3,900 vulnerabilities rated as high or critical. AI can analyze code at a pace that cannot be matched by traditional manual methods. This also changes the dynamics surrounding zero-day vulnerabilities: The faster potential attack surfaces are identified, the faster the window of opportunity for patching them closes. It is nearly impossible for individual companies to assess and prioritize every vulnerability they find on their own. This, in turn, exacerbates the problem of the remediation gap. Weeks or even months can pass between the discovery of a security vulnerability and its actual remediation in a production environment. During this time, companies are either left with a known vulnerability, must maintain their own patches, or face the decision of performing a risky upgrade.<\/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>
From the scanner to the production system: Between identifying a vulnerability and deploying a fix, there are analysis, remediation, building, testing, and approval\u2014and that takes a lot of time. (Source: Red Hat)<\/em><\/figcaption><\/figure>\n\n\n\n

But even \u201eold\u201c vulnerabilities remain a problem. A particularly striking example is Log4Shell. The security vulnerability in the widely used Java library Apache Log4j became public knowledge in late 2021 and was classified as critical. Applications that used a vulnerable and unpatched version of the library were affected. Under certain conditions, attackers could exploit this to remotely execute malicious code and thereby gain extensive access to the affected systems. Although Log4Shell is generally patched on critical systems, outdated\u2014and thus forgotten\u2014Log4Shell dependencies in the software supply chain continue to create enormous vulnerabilities.<\/p>\n\n\n\n

To make matters worse, simply releasing a security update is not enough. The path from patch to production is often arduous: the application must be rebuilt, automated and manual tests must be performed, dependencies must be checked, and changes must be approved. For critical applications, technical acceptance testing, compliance requirements, or formal change processes may also come into play. Consequently, the speed of the downstream processes becomes a key factor. No matter how quickly a company can access a new security upgrade\u2014if the internal build and deployment process takes several weeks or even months, the vulnerability remains unaddressed for that long or may not be addressed at all.<\/p>\n\n\n\n

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

Lightwell: Security Fix Instead of a Forced Version Upgrade<\/h2>\n\n\n\n

Lightwell, a joint initiative by Red Hat and IBM aimed at securing the open-source software supply chain, addresses precisely this gap. The concept builds on a principle that Red Hat has been practicing for decades with enterprise software: security fixes are not necessarily delivered via a full version jump, but can be backported specifically to a version that is still supported. The goal is to implement the security-related change without simultaneously forcing an unnecessary functional or API change. This is an important consideration for enterprises: a backport addresses the security vulnerability without automatically altering the application\u2019s entire dependency structure.<\/p>\n\n\n\n

The difference from a manual fork is enormous. While a company could theoretically copy the source code of an affected library, apply the patch, and build its own artifact, However, this would also mean permanently assuming responsibility for this fork: the build process, signing, dependencies, further security fixes, documentation, and, if necessary, later merging back into the upstream repository. Another difference from traditional patch management lies in what happens after the update is applied. In a modern software supply chain, it is no longer enough to simply provide a new JAR file. Companies must be able to track what they are using, where it comes from, how it was built, and what security information is associated with it.<\/p>\n\n\n\n

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

Companies have three options for addressing vulnerabilities:<\/h2>\n\n\n\n
    \n
  1. Classic Upgrade:<\/strong> The application will adopt a newer version of the dependency and accept the associated compatibility and testing efforts.<\/li>\n\n\n\n
  2. Accept the risk or apply the patch yourself:<\/strong> The organization will keep the existing version and, if necessary, develop its own workaround or fork.<\/li>\n\n\n\n
  3. Targeted backporting:<\/strong> The security fix is ported to the version in production and introduced into the existing supply chain as a controlled artifact, without requiring any changes to the application.<\/li>\n<\/ol>\n\n\n\n

    Which option makes sense depends on the application, the risk profile, and the operating model. Lightwell expands the range of technical solutions to include an option that is particularly relevant for stable, long-lasting applications that are difficult to modify.<\/p>\n<\/div><\/div>\n\n\n\n

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

    Lightwell therefore provides not only patched and signed artifacts, but also supply chain metadata. This includes, among other things, Software Bills of Materials (SBOMs), SLSA Level 3 provenance, and signatures via Sigstore or Cosign. This is particularly relevant for SAP customers, since, as mentioned, open-source dependencies do not end at the boundary of the SAP system. In an integration landscape, Java libraries, messaging components, APIs, containers, build tools, or AI frameworks can be part of the overall system. An SBOM makes these components visible in a machine-readable format. VEX (Vulnerability Exploitability Exchange) goes even a step further.<\/p>\n\n\n\n

    Essentially, an SBOM answers the question of which components are present. VEX can provide additional information on whether and how a piece of software is actually affected by a specific vulnerability. This is of critical importance for regulated companies. Requirements under DORA, NIS2, or the Cyber Resilience Act are increasing the pressure to document software components, vulnerabilities, and their remediation in a traceable manner. Lightwell provides this information along with the artifacts, eliminating the need to manually compile it from various sources afterward.<\/p>\n\n\n\n

    Such verifiable supply-chain and build artifacts are also relevant in light of future or voluntary European certification and compliance requirements, such as EUCS (European Cybersecurity Certification Scheme for Cloud Services) or EUCC (European Common Criteria-based Cybersecurity Certification Scheme).<\/p>\n\n\n\n

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

    Two versions for different needs<\/h2>\n\n\n\n

    Lightwell doesn\u2019t just start with the finished patch. The model combines AI-powered triage with human engineering expertise. The AI helps manage the massive flood of CVEs by analyzing vulnerabilities in a matter of seconds, assessing their relevance, and generating potential fixes. The resulting changes are then automatically tested and validated by human experts\u2014specifically, more than 20,000 engineers from Red Hat and IBM\u2014before being deployed as artifacts. However, the developed patches are not only made available to customers but are also returned to the original projects in the spirit of the open-source community, so that the entire industry benefits.<\/p>\n\n\n\n

    The Lightwell ecosystem\u2019s initial focus is on Maven\/Java. This is particularly interesting for SAP customers, as Java applications often obtain their dependencies from Maven repositories and play a role in numerous integration, middleware, and customer-specific application scenarios. At the same time, Java is just the beginning. Lightwell is set to expand to other ecosystems such as PyPI, npm, and Go to meet the requirements of regulated industries, where the use of fixed or pinned versions is particularly important. The solution is currently available in two different versions.<\/p>\n\n\n\n

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

    Lightwell is not a substitute for:<\/h2>\n\n\n\n