Skip to main content

SonarQube SonarScanner Reference

You can set up a Security step with SonarQube SonarScanner to analyze your code repos and ensure that they are secure, reliable, readable, and modular, among other key attributes.

Important Notes​

  • STO supports repository scanning only for SonarScanner.
  • STO supports all languages supported by SonarScanner.
  • Before you scan your repo, make sure that you perform any prerequisites for the language used in your repo. If you are scanning a Java repo with more than one Java file, for example, you must compile .class files before you run the scan.
    Go to the SonarQube language reference for details about specific language requirements.

Scan types​

STO supports the following scan types for SonarQube:

  • orchestratedScan  — A Security step in the pipeline runs the scan and ingests the results. This is the easiest to set up and supports scans with default or predefined settings.
  • dataLoad  — The pipeline downloads scan results using the SonarScanner API.
  • ingestionOnly — Run the scan in a Run step, or outside the pipeline, and then ingest the results. This is useful for advanced workflows that address specific security needs. See Ingest scan results into an STO pipeline.

Required settings​

  • product_name = sonarqube
  • scan_type = repository
  • product_config_name = default — Runs a SonarQube scan with default settings.
  • policy_type — Enter one of the following:
    • orchestratedScan  — A Security step in the pipeline runs the scan and ingests the results. This is the easiest to set up and supports scans with default or predefined settings.
    • dataLoad  — The pipeline downloads scan results using the SonarScanner API.
    • ingestionOnly — Run the scan in a Run step, or outside the pipeline, and then ingest the results. This is useful for advanced workflows that address specific security needs. See Ingest scan results into an STO pipeline.
  • repository_project — The repository name. If you want to scan https://github.com/my-github-account/codebaseAlpha, for example, you would set this to codebaseAlpha.
  • repository_branch — The git branch to scan. You can specify a hardcoded string or use the runtime variable <+codebase.branch>. This sets the branch based on the user input or trigger payload at runtime.

ingestionOnly settings​

For information about setting up an ingestionOnly scan, go to Ingest scan results into an STO pipeline.

orchestratedScan and dataLoad settings​

  • product_domain — The URL of the SonarQube server.
  • product_access_token — The access token to communicate with the SonarQube server. You must create a secret for the token and use the format <+secrets.getValue("secret_name")> to reference the secret. This example references a secret created at the project level. For additional details on referencing secrets, go to Add and Reference Text Secrets.
    Go to the SonarQube docs for information about creating tokens.
  • product_project_name—The name of the SonarQube project. This is the also the target name in the Harness UI (Security Tests > Test Targets).
  • product_project_key — The unique identifier of the SonarQube project you want to scan. Look for sonar.projectKey in the sonar-project.properties file.
  • product_exclude — If you want to exclude some files from a scan, you can set the sonar.exclusions key in your SonarQube project. See Narrowing the Focus in the SonarQube docs.
  • product_java_binaries — When scanning Java, you need to set the sonar.java.binaries key in SonarQube. This is a list of comma-separated paths with the compiled bytecode that correspond to your source files. See Java in the SonarQube docs.
  • product_java_libraries — sonar.java.binaries is a comma-separated list of paths to files with third-party libraries (JAR or Zip files) used by your project. See Java in the SonarQube docs.