Code Analysis

• Code Reliability: Detect bugs that will impact end-user functionality
• Application Security: Detect vulnerabilities and hotspots that can be exploited to compromise the program
• Technical Debt: Keep you codebase maintainable to increase developer velocity

Code Analysis in the Pipeline

• Follow the directions in Deploying an App
  • Deploy the Spring Boot Microservice template
  • Name the new repo something like sonar-java
  • Be sure to run the CI pipeline for your project, and confirm that it runs the Sonar scan stage

• Use the Developer Dashboard to open the SonarQube dashboard

• Go to the Projects page

  You should see your project in the list, such as bwoolf1.sonar-java.

  

  The project summary shows several characteristics meansured in the app:

  • The quality gate passed
  • Several issues were found, catagorized by type
    • 2 bugs for a C rating
    • 0 vunerabilities for an A rating
    • 17 code smells but an A rating
    • None of the code was tested
    • None of it is duplicate code
  • It scanned 1.5k lines of code written in Java, a small program (XS, S, M, L, XL)

• In the Projects list, click on the project name (such as bwoolf1.sonar-java) to open your project

  The project overview shows more detail about how many issues were found in the app

  • Reliability: 2 bugs for a C rating
  • Security: 1 security hotspot but an A rating
  • Maintainability: 17 code smells, 2 hrs of technical debt but an A rating
  • Coverage: 7 unit tests
  • Duplications: 0 duplicated blocks

Examine the issues

• In the Reliability pane of the project’s Overview page, click on the “2” to open the Issues page

  The Issues page, filtered for bugs, shows two issues. Both concern “synchronized” methods.

  

• In the Issues list, click on either issue to see where the issues appeared in the code

  The Issues detail shows the soure code file for the Java class. The issue descriptions are embedded after the mark and reset method signatures.

  

• In either issue, press the See Rule button.

  SonarQube displays the details of its “Overrides should match their parent class methods in synchronization” rule.

  Now you need to investigate to figure out why the code violates this rule.

  Want to see if you can track down the problem before seeing the solution? What to fix is pretty obvious—the Rule explains what to do—but tracking down why takes some effort.

  ---

  Here’s the solution:

  The error is not in the file’s parent class, ResettableHttpServletRequest, but in its embedded class, SimpleServletInputStream, which extends javax.servlet.ServletInputStream. The Javadocs for ServletInputStream show that it extends java.io.InputStream. The original Java 1.0 Javadocs show that these methods in InputStream are indeed synchronized:

  public synchronized void mark(int readlimit)
  . . .
  public synchronized void reset() throws IOException
  Copy to clipboardCopied!

  More recent Javadocs haven’t shown these signatures for years, but the compiler says the class is still defined that way. There’s some debate about whether mark and reset really need to be synchronized. But SonarQube doesn’t judge, it just reports: Since the superclass defined the method signatures as synchronized, SonarQube is warning that the subclass is supposed to do so as well.

Examine the other issues

• In the SonarQube dashboard, go back to the Issues page

• Click on the “1” above Security hotspots

  The issue warns to “Make sure that command line arguments are used safely here.”

  

  SonarQube considers any class that has a public static void main(String[] args) method to be a potential vulnerability. As the rule explains, “Command line arguments can be dangerous just like any other user input. They should never be used without being first validated and sanitized.” This method passes them through unchecked, which is risky.

• Back in the Issues page, click on “17” code smells

  SonarQube found issues such as:

  • Remove this unused import ‘java.lang.System.lineSeparator’.

  • Move constants to a class or enum.

  • This block of commented-out lines of code should be removed.

    None of these break your app’s functionality, but they do make the code more difficilt to maintain.

Give it a try

Add a quality gate to SonarQube

• Use the Developer Dashboard to open the SonarQube dashboard

• To create and install a new quality gate, first log in to SonarQube

• Go to the Quality Gates page

• Make a copy of the default gate named Sonar way, give it a name like better gate {your initials}, i.e. better gate bw

• Add a condition, Bugs is greater than 0

• Add your project to this gate

• Back in the OpenShift console, on the Application Console > Builds > Pipelines page, press Start Pipeline

• After the Sonar Scan stage completes, go back to the SonarQube dashboard and take a look at your project

Add a stage to Jenkins

• In the local Git repo that contains your source code (e.g. sonar-app-bw), edit the file named Jenkinsfile

• After the stage called Sonar Scan, insert this stage:

  stage("Quality Gate") {
      timeout(time: 1, unit: 'HOURS') {
      // Parameter indicates whether to set pipeline to UNSTABLE if Quality Gate fails
      // true = set pipeline to UNSTABLE, false = don't
      waitForQualityGate abortPipeline: true
  }
  Copy to clipboardCopied!

• Push the change to the server repo, which runs the pipeline again, and the Quality Gate stage fails

Fix the code

• Edit the class com.ibm.cloud_garage.logging.inbound.ResettableHttpServletRequest

• Edit the methods mark and reset to make them both synchronized

public synchronized void mark(int i) {
. . .
public synchronized void reset() throws IOException {
Copy to clipboardCopied!

• Push the change to the server repo, which runs the pipeline again, and this time the Quality Gate stage passes

• Check the project in SonarQube and see that it now has 0 bugs and has now passed

Conclusion