Using Sonarqube, can I get alert when there is a CVE on a dependency ?
I track software quality on Sonarqube and I have read about the dependency check integration. But it seems quite different from the dependency track platform where notifications can be triggered when a CVE affect a previous release.
Is CVE notifications on older releases available in SonarQube (with or without plugins)
Related
I'm running Jenkins 2.319.3 with a ton of Maven Project jobs. I recently learned that "The Jenkins project recommends that users transition from the Maven job type to use Pipeline jobs or freestyle jobs" and "Note that dependency version ranges are not supported, see JENKINS-2787 for the reason."
Source: legacy Maven Integration job type
I have reviewed both Pipeline Maven Integration and their related FAQ, and cannot find any mention of whether or not version ranges are supported for the downstream dependency trigger capability.
I would be using pipeline-maven plugin version 1235.v2db_ddd9f797b to transition from my legacy Maven Integration job type projects.
Are dependency version ranges supported for the pipeline-maven plugin, to trigger a build whenever a -SNAPSHOT dependency is built?
For example, project B with a dependency on project A using version range "[1.12,2.0)" is expected to be triggered when a build of upstream project A occurs that creates version 1.13.1-SNAPSHOT of A.
What is the recommended way of upgrading the quarkus version used in an existing application?
I have taken a look at my pom.xml, since the quarkus extensions dont specify the version used, I assume that they will get updated based on the main quarkus version.
The properties which look to be relevant in the update are quarkus-plugin.version, quarkus.platform.group-id and surefire-plugin.version.
How can I decide which ones to change, and is there anything else to be aware of?
There is one important thing to know, we have:
Quarkus Core: this is the main Quarkus artifacts + all the core extensions: the quarkus-bom is the one of Core. The Quarkus Maven plugin is part of it too.
Quarkus Platform: it contains more extensions such as Camel Quarkus: the quarkus-universe-bom is the one from the Platform, it contains the Core + the additional extensions
We usually release Quarkus core then Quarkus Platform with a few days between the two as we often need a release of Camel Quarkus, which is an Apache project and organizes a 72 hours vote for each release.
In a newly created project, you have the following properties:
<quarkus-plugin.version>1.1.1.Final</quarkus-plugin.version>
<quarkus.platform.artifact-id>quarkus-universe-bom</quarkus.platform.artifact-id>
<quarkus.platform.group-id>io.quarkus</quarkus.platform.group-id>
<quarkus.platform.version>1.1.1.Final</quarkus.platform.version>
quarkus-plugin.version is the version of the Quarkus Maven plugin, it should be in line with the version of the core you use
quarkus.platform.artifact-id can right now either be quarkus-universe-bom for the whole Platform or just quarkus-bom for the Core only.
quarkus.platform.version is the version of the BOM.
Usually all these versions should be aligned. But... it could happen that we would need some quick update in the Platform and not of the core and we could then only release a new version of the platform. This hasn't happened yet to be honest.
Let's take an example of what happened today: I released Quarkus Core 1.2.0.Final but we are still waiting for Camel Quarkus to be released to release the Platform.
If you want to update early, you can change the BOM to use the quarkus-bom and update everything to 1.2.0.Final.
Or you can wait for the Platform to be released early next week and stay on the Platform quarkus-universe-bom.
We also only update the website documentation and code.quarkus.io when the full Platform is released.
It used to work to simply issue the command
mvn io.quarkus:quarkus-maven-plugin:1.4.2.Final:create
in the base project directory for it to automatically update the Quarkus versions in the project pom.xml file, but since 1.6.0.Final it errors:
project XXXXX: Unable to generate the project in a directory that already contains a pom.xml -> [Help 1]
I will create an improvement suggestion ticket at Quarkus to restore this functionality, maybe with a dedicated maven goal (like update)
I am in the midst of an initiative to convert our build.gradle files to use semantic versions. In addition to using Gradle, we also use Git and are following the Gitflow Workflow. Jenkins is used to build the projects.
Versions for released artifacts follow a MAJOR.MINOR.PATCH format. When declaring dependencies in the build.gradle file, we use dynamic versions, such as 10.0.+ (i.e. take the latest 10.0.PATCH version).
We promote our artifacts from a Release Candidates repository to a Releases repository in Nexus. The repository has its policy set to "Releases". Because of the complexity of the product (200+ projects, with many upstream and downstream dependencies), a lot of the promotion plugins available for Jenkins appear to fall short. We were thinking of having Jenkins build the master branch as a way to rename artifacts (10.0.0-rc.1-abcdefg becomes 10.0.0) and upload them to the correct Nexus repository.
I am unsure of how to handle a situation where an upstream dependency has a patch version incremented. The downstream project - a WAR - is re-built by Jenkins and bundles the new JAR, but the version of the downstream project doesn't change. When an attempt is made to upload to Nexus, it fails because only one artifact can have the same version.
Here is an example:
The Releases Nexus repository has upstream-api versioned at 10.0.0, and downstream-project versioned at 10.0.0
downstream-project depends on 10.0.+ of upstream-api
upstream-api.jar is bundled into the downstream-project.war file
The two artifacts are deployed as part of Release X of the product
When a hotfix branch has been merged into master, the upstream-api version has changed to 10.0.1
The fix means that when deployed, the product is now Release X'
downstream-project stays at 10.0.0, but is re-built because of the change in the upstream dependency
Jenkins fails to upload downstream-project-10.0.0.war to Nexus because it already exists
I could have the old artifact replaced with the new artifact, but then that means that Release X can no longer be deployed from artifacts in Nexus (eg. in the case of a rollback, or needing to replicate an issue on an older release).
How is this typically handled?
How is this typically handled?
I don’t have a universal answer here. I would assume that these are the most “common” possibilities:
Don’t distribute your dependencies with the release and continue to use dependency version declarations such as 10.0.+. The assumption is then that the software will indeed work with any 10.0.x version – at least as far as your users will tolerate it. That usually happens for free software which is distributed in source or in a package system of a Linux distribution. The dependency version declaration is only updated when there is a required improvement in the dependency, i.e., when the change is so important that your users won’t tolerate any earlier version.
Distribute your dependencies with the release and either:
Use a build number in addition to the main/semantic version number of the original code – for example 1.3.4-b3. If I’m not mistaken, then this is often being done for proprietary Windows software.
Increment the main/semantic version number when a dependency changes and make the dependency requirement explicit.
Some more General Thoughts on the Issue
I think the core issue is the dynamic dependency declaration – the 10.0.+ version declaration. What you state with this declaration is that your release will work equally well with any 10.0.x version.
If that is really the case, i.e., the bugs that are fixed by a patch in the dependency are guaranteed to never affect the release, then your release should probably simply not be rebuilt, since its functionality wouldn’t change anyway. The version of the dependency wouldn’t matter, your release could stay with the older dependency version.
More likely, though, the upstream bugfixes will also make a difference in your downstream project, i.e., they will affect the functionality of the release. In that case you should make the “new” dependency explicit in your build.gradle. Since that’s a change to your release artifact, a new release version is due.
I want to have Sonar analysis being performed on twice on the same Maven project at the same time, but different versions.
i.e. GAV details
<groupId>com.test.exm</groupId>
<artifactId>exm001</artifactId>
<version>1.5.0-SNAPSHOT</version>
AND
<groupId>com.test.exm</groupId>
<artifactId>exm001</artifactId>
<version>1.4.0-SNAPSHOT</version>
This gives the error though...
Caused by: org.sonar.api.utils.SonarException: The project is already
being analysed. at
org.sonar.batch.scan.ProjectLock.start(ProjectLock.java:55)
Please don't ask why I have snapshot 1.4.0 and 1.5.0 at the same time.
Its a legacy build thing going on in the background.
I would have thought the semaphore lock used would include the version number, not just the artifact and groupID.
I've found this defect...
https://jira.codehaus.org/browse/SONAR-2761
I could turn off sonar for the legacy stuff, but I'd sooner see if there is a fix I could make to allow Sonar to do the analysis.
In order to achieve this, you can use the sonar.branch property on the legacy version of your project.
I have a problem when I run the Issues Report Plugin on the multi-module project. I noted that the documentation indicated that the plugin is incompatible with this kind of project.
Nevertheless, I tried to run a sonar-runner dry run on one of the modules using its projectKey and projectName (retrieved from the widget Description). Unfortunately, the plugin has not retrieved metrics previously analyzed for this module. All anomalies are marked as new.
Is there a way to ensure I get the right values?
The dry run mode for SonarQube analyses on multi-module projects suffers from limitations, which are all fixed in the upcoming 3.6.1 version of SonarQube.
See the following ticket: https://jira.codehaus.org/browse/SONAR-4265
And just to be clear: the Issues Report Plugin does not export measures of metrics, it only exports issues.