0

We have some use cases which leverage Cloud SDK project template for Java. Now they are already running on SAP BTP, Cloud Foundry environment. By default, it uses logback and we did not change it.

When getting dependencies with maven command mvn dependency:tree in cloud sdk project, I can see log4j-to-slf4j:jar:2.14.1 and log4j-api:jar:2.14.1 is used by SAP Spring xsuaa library and spring-boot-starter-logging.

[INFO] |  |  +- org.springframework.boot:spring-boot-starter-logging:jar:2.5.6:compile
[INFO] |  |  |  +- org.apache.logging.log4j:log4j-to-slf4j:jar:2.14.1:compile
[INFO] |  |  |  |  \- org.apache.logging.log4j:log4j-api:jar:2.14.1:compile

[INFO] +- com.sap.cloud.security.xsuaa:xsuaa-spring-boot-starter:jar:2.11.0:compile
[INFO] |  +- com.sap.cloud.security.xsuaa:spring-xsuaa:jar:2.11.0:compile
[INFO] |  |  +- org.apache.logging.log4j:log4j-to-slf4j:jar:2.14.1:compile
[INFO] |  |  |  \- org.apache.logging.log4j:log4j-api:jar:2.14.1:compile

According the [Spring official documentation][1]. Only log4j-core is affected. The log4j-to-slf4j and log4j-api jars that we include in spring-boot-starter-logging cannot be exploited on their own. From my perspective, there should be no impact on Cloud SDK project with libraries originally included.

Could you give some comments?

Jerry Zhang
  • 179
  • 3
  • 13

1 Answers1

4

This writeup of the SLF4J developers describes their situation quite well: http://slf4j.org/log4shell.html

The SLF4J API is just an API which lets message data go through.

This means it all depends on the actual logging implementation that you use. The SDK modules do not provide or expect any logging implementation.

In our CF Archetypes we use slf4j-simple for test cases and logback for productive logging, however this can be changed by the consumer of the archetype.

On Neo the runtime provides an implementation, so that the archetype does not provide any implementation.

Christoph Schubert
  • 1,089
  • 1
  • 8
  • 16