I'm getting security vulnerabilities for spring web jars in Sonartype scanning, leading Bamboo builds failure.
My question is how to disable the Sonar from scanning these jars? Something like, configure in Gradle, Maven or Bamboo?
We already use 2.2.* version SpringBoot, so upgrade is not considered.
Thanks in advance.
Related
I am new to the SonarQube.
I am using SonarQube to security scan my Java source code. I am also using Trivy to security scan my Docker container where I pack my Java app for deployment.
I deploy my code on JBoss and Tomcat web servers.
So, I have SonarQube to security scan my source code and Trivy to security scan my Docker image, but now I need something to security scan my code's dependencies (JARs).
Can SonarQube scan dependency Apache libraries and report which dependencies contain security flows and needs to be replaced with newer versions? If yes, how?
I think the dependency-check project is what you're after; there are Grade and Maven plugins to make using it easier and it can be integrated with SonaqQube.
You can use this Trivy plugin to convert Trivy results into SonarQube format and import it as external issues report to SonarQube: https://github.com/umax/trivy-plugin-sonarqube
I am using Gradle 5's BOM (Bill of Materials) feature. This is how I describe it for my JUnit 5 dependencies:
testImplementation(enforcedPlatform("org.junit:junit-bom:5.4.0")) // JUnit 5 BOM
testImplementation("org.junit.jupiter:junit-jupiter-api")
testRuntimeOnly("org.junit.jupiter:junit-jupiter-engine")
testImplementation("org.junit.jupiter:junit-jupiter-params")
My assumption is that providing the BOM will resolve the versions of the dependencies to 5.4.0. However, they get resolved to 5.1.1. I am not sure why. (I also request enforcedPlatform() to lock the specified version)
Inspecting JUnit 5's BOM we see that all org.junit.jupiter dependencies are listed with version 5.4.0 (resolving to 5.1.1 in the project) and all org.junit.platform dependencies are listed with version 1.4.0 which resolve correctly in the project.
I am not sure what I am missing and was hoping to get some help here. Thanks!
EDIT:
I used Sormuras response and moved all BOMs at the top of the dependencies {} block but was still not getting version 5.4.0. Then I suspected it might be coming from the Gradle Spring Dependency Management plugin that I use, so when I commented it out, I got version JUnit 5.4.0. How do I disable JUnit coming from the Gradle Spring Dependency Management plugin?
FINALLY:
I decided to use the Spring Boot Dependencies BOM directly and remove the Gradle plugin:
implementation(platform("org.springframework.boot:spring-boot-dependencies:2.0.5.RELEASE"))
I imagine the plugin was created for those version of Gradle before Gradle 5 where you couldn't use a BOM file. Now with the BOM support I can directly include it. This way my version of JUnit is as I have specified it in the enforcedPlatform() block.
I accepted Sam Brannen's answer below because he explains well how the issue occurs and what solves it and I think it's relevant for those who use older versions of Gradle.
How do I disable JUnit coming from the Gradle Spring Dependency Management plugin?
For starters, if you are using the dependency management plugin from Spring, you should not be importing the junit-bom since that results in duplicate (and potentially conflicting) management of those dependencies.
Aside from that, whenever you use the dependency management plugin from Spring and want to override a managed version, you have to do it by overriding the exact name of the version defined in the BOM used by the plugin.
This is documented in Spring Boot for Gradle and for Maven.
For Spring Boot the name of the JUnit Jupiter version is "junit-jupiter.version". You can find the names of all managed versions for Spring Boot 2.1.2 here.
So, in Gradle you would override it as follows.
ext['junit-jupiter.version'] = '5.4.0'.
You can see that I have done exactly that here.
With Maven you would override it as follows.
<properties>
<junit-jupiter.version>5.4.0</junit-jupiter.version>
</properties>
Further background information here: https://docs.spring.io/platform/docs/current/reference/html/getting-started-overriding-versions.html
JUnit 5.4.0 simplified its artifacts, and now delivered a single artifact for Jupiter - org.junit:junit-jupiter. I.e., you should simplify your Gradle file too:
testImplementation(enforcedPlatform("org.junit:junit-bom:5.4.0")) // JUnit 5 BOM
testImplementation("org.junit.jupiter:junit-jupiter")
Ensure to include JUnit's BOM before other BOMs that also refer to JUnit. First BOM wins and locks version of all later artifacts.
See this issue for a similar setup using Maven and Spring Boot: https://github.com/sormuras/junit-platform-maven-plugin/issues/29#issuecomment-456958188
Since spring-boot comes with embedded tomcat containers, I was wondering how is the patching being done. If I decide to go for using embedded approach and a security vulnerability has been found out and the tomcat community has released a patch, how do I apply that patch to the embedded tomcat container which comes with the Spring-boot.
Any help would be greatly appreciated since it will help to decide to go the traditional route of standalone tomcats v's embedded.
According to this Spring blog post, you can specify any version of Tomcat you want. As long as it's released to the Maven repo, just add the following property to your Maven build properties specifying whatever version you like: <tomcat.version>8.0.3</tomcat.version>.
See http://mvnrepository.com/artifact/org.apache.tomcat.embed/tomcat-embed-core for versions currently available in Maven Central.
I have a project where I use Spring Boot 1.1.2.RELEASE which uses Spring 4.1.5, and Spring HATEOAS 0.10.0.RELEASE which uses Spring 4.0.9. This causes some dependency problems like the infamous java.lang.ClassNotFoundException: org.springframework.beans.factory.SmartInitializingSingleton.
I dug into the POM of spring-hateoas and found that there are different profiles defined, one of them being spring41 which depends on Spring 4.1.5. Is it possible to select this profile in my <dependency> section, or do I have to exclude the Spring dependencies?
Automatically selecting a profile for a build isn't easy. You can enable it by default in your personal settings.xml but that breaks the build for everyone who doesn't have the same file.
You can't enable a profile in the POM of the project.
With Maven 3.3, you can add the profile to ${maven.projectBasedir}/.mvn/maven.config. Since this file is part of the project, it's easy to share. You can use the Maven Enforcer plugin to make sure everyone uses a Maven version with actually uses the file.
If you can't use 3.3, then your best bet is to exclude the dependencies. If you have a parent POM, then you can use a dependencyManagement element to do it for all POMs in the reactor build.
Is Spring tightly coupled with Maven ? Most of the examples in the internet shows Spring and Maven to configure spring dependent jars, this post explains so many cons of Maven. All commercial projects are should to be using only this combination ?
Please explain
Thanks
Both of them serve different purposes, Spring examples use Maven because maven is highly adopted as a build, dependency management framework. That has nothing to do with Spring coupling with Maven. Spring is a framework to build enterprise applications and Maven is a build and deploy tool.
You can use Gradle, ivy or even manually download the libraries instead of relying on Maven as the dependency management framework.
No. You can use whatever you want to build your Spring-based app. BTW, all the Spring tutorials show examples using Gradle (that Spring also uses internally).
What is true, though, is that Spring jars are available from the Maven central repository and the Spring repository, and that their dependencies is thus described in a Maven pom.xml file. But nothing prevents you from downloading the required jars manually and add them in the classpath.