As an immediate reaction to log4j, companies can follow detailed recommendations and apply existing patches and apply best practices. But in a second step you should take a general look at processes related to software supply chains.
Ultimately, Log4Shell, however security-relevant the gap may be, is “only” a faulty component in the software supply chain, ”says Udo Schneider, IoT Security Evangelist Europe at Trend Micro.
Log4Shell - Do you know your software supply chain?
The critical threat posed by the Log4Shell vulnerability naturally requires an immediate response. But in the second step, companies generally have to ask themselves questions about processes related to software supply chains and documented (?) Dependencies.
The Log4Shell vulnerability that became known a few days ago is currently on everyone's lips and is keeping security professionals around the world on their toes. The BSI speaks of an "extremely critical threat situation" because the vulnerable Log4J library is, so to speak, "the" log standard in Java environments. Accordingly, it is also used in thousands of applications and Internet services. In addition, the vulnerability is easy to abuse and, in many cases, can be exploited remotely, ultimately allowing any commands to be executed. A real nightmare from a cybersecurity point of view! As an immediate reaction, companies can follow our detailed recommendations and apply existing patches and apply best practices. But in a second step you should take a general look at processes related to software supply chains. After all, Log4Shell, however security-relevant the vulnerability may be, is “only” a faulty component in the software supply chain.
Log4Shell the faulty block
To understand software supply chains and their context, it is helpful to take a look at the “real” world, such as the manufacture of electronic products. So-called “parts lists” (BOM - Bill of Material) for assemblies are common practice. If you consider a single circuit board as an assembly, the appropriate parts list contains a list of all the components used, such as resistors, capacitors, diodes, ICs and much more. Precise parameters, manufacturers, prices, sources of supply and ultimately serial numbers or at least batch information are also saved for each component.
If there is information from the manufacturer of one of the components that certain components of a batch do not, for example, correspond to the specified temperature values, it is possible to track exactly which circuit boards (each with their own serial number) are a) affected by it and b) whether there is a need for action. If appropriate measures have to be initiated, the information as to which assemblies (due to the serial number) are affected at all is of course a huge help. In the end, this procedure with "assemblies" continues almost at will ... until you eventually end up with massive installations such as the LHC at CERN. Even with such a large machine, the failure of a tiny SMD component can cause the entire machine to fail. If, for example, defective batches become known, one must ultimately be able to verify every single resistor installed.
Software Bill of Material (SBOM)
Software supply chains, ie SBOMs, also work in exactly the same way - and back to Log4Shell specifically: Can you quickly say whether you are affected by this gap? With your own software that Log4J uses, the question may still be answered quickly. Often even SCM services such as GitHub or GitLab offer such functions directly. But what about transient dependencies? Does a third-party library you use use Log4J internally? Or worse, is a library you are using using a library that is dependent on a library (etc.) that Log4J uses? Does the purchased software of a service provider rely on Log4J? Is a cloud service that you purchase using Log4J?
SBOM content (Image: Trend Micro).
Questions about questions that need the answers, for which you need to grapple with SBOMs. Log4Shell clearly shows the problems that arise when the software supply chain is not documented. But don't be fooled. Log4Shell is certainly a kind of worst-case scenario right now. But even with simple "errors" that have no direct safety relevance, the question of whether you are affected is important!
Document dependencies
Basically, SBOMs are about the documentation of dependencies. These can be dependencies in the form of software (components) but also services, licenses, servers and much more. In the course of time, two exchange formats have emerged, especially when modeling software dependencies: CycloneDX and SPDX. Both allow the description of different software components including possible dependencies:
But the description language is not enough. Rather, the specific environment must also be described and kept up to date. Of course, these descriptions can be created manually - and sometimes, for example when you are dependent on external services, there is nothing else left to do. However, when it comes to creating descriptions for software, manual effort does not make sense. The creation and maintenance of these descriptions must take place fully automatically within the framework of the CI / CD pipeline. There are basically two approaches: The integration into the build process and the scanning of build artifacts.
CI / CD integration - build process
SBOM creation during the build process (Image: Trend Micro).
Both CycloneDX and SPDX have tools that can be integrated directly into the build process. These extract (transient) dependencies directly “at the source”. These can be libraries, executable files, but also containers or container layers. The direct integration also makes it possible to track dependencies that only exist during the build itself, but not in the finished product, for example.
CI / CD integration - build artifact
Even if the build process is not to be intervened directly, there are tools for CycloneDX and SPDX that scan the end result “afterwards”. This means that these tools extract the dependencies from the Java application, for example, and document them. Since these tools only ever see the finished result, it is quite possible that some dependencies are simply overlooked, as these can no longer be deduced from the final result.
Vulnerability monitoring
SBOM creation after the build process (Image: Trend Micro).
For companies that are only interested in vulnerability monitoring, many of these tools also offer direct correlation with vulnerability databases. This means that the output not only contains the components found, but also a list of vulnerabilities. This is comparable, for example, with the integration of snyk, Trend Micro Application Security or Trend Micro Container Security into the CI / CD pipeline.
OWASP Dependency Track
If the tracking and documentation of licenses, inventory or degree of distribution also play a role, other solutions are (additionally) available. In this environment, the OWASP (Open Web Application Security Project) dependency track tool is certainly one of the top dogs. As an open source solution, it is usually integrated into CI / CD pipelines and receives SBOM data there - either via CycloneDX / SPDX data (manual, API) or directly from the build process. In addition, Dependency Track automatically holds vulnerability data from various vulnerability databases and continuously correlates the data from (historical) builds and vulnerabilities. Matches are displayed accordingly in a dashboard or reported directly via chat and CI / CD integration or optionally also forwarded to tools for automatic correction.
Dependency Track Integration (Image: https://github.com/DependencyTrack/dependency-track )
Dependency Track is a database with which the question: "Where am I affected by Log4Shell" can easily be answered. This answer not only includes current versions of the software, but also descriptions of old versions. One possible finding can therefore be that a company is not affected in the current version (because it has been sufficiently patched), but 34 older versions are affected. If you now also track information about the number of installed versions, these are almost perfect data for a well-founded risk assessment.
Conclusion on Log4j, Log4Shell and supply chains
Ultimately, it is important to be able to answer the questions asked at the beginning: Do we (directly or in our software supply chain) use Log4J? If so, to what extent (version, distribution) are we affected by Log4Shell? The effort required to answer this question is an indicator of the extent to which you have insight into your software supply chain, or whether it is worthwhile to help out with tools.
With regard to the tools, it has to be clarified whether it is “only” about the question “am I affected”. If this is the case, tools like snyk or the options integrated in GitHub and GitLab can help. If, on the other hand, a more comprehensive insight is desired, there are other solutions for capturing and cataloging software artifacts. These are available both commercially and free of charge. From the open source camp, Dependency Track is certainly the most widespread one.
Ultimately, however, it should be noted that security vulnerabilities are an important argument for software supply chain management - but certainly not the only one!
More at TrendMicro.com
About Trend Micro As one of the world's leading providers of IT security, Trend Micro helps create a secure world for digital data exchange. With over 30 years of security expertise, global threat research, and constant innovation, Trend Micro offers protection for businesses, government agencies, and consumers. Thanks to our XGen™ security strategy, our solutions benefit from a cross-generational combination of defense techniques optimized for leading-edge environments. Networked threat information enables better and faster protection. Optimized for cloud workloads, endpoints, email, the IIoT and networks, our connected solutions provide centralized visibility across the entire enterprise for faster threat detection and response.