Skip to content

SonarSource/sonar-text

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

SonarText: detect BIDI Characters Vulnerabilities and Leaking Secrets

Build Status Quality Gate Status Coverage

This SonarSource project is a static code analyzer made to detect:

  • BIDI Characters Vulnerabilities
  • Leaking Secrets/Tokens

It is a component of the Sonar Clean Code solution. It is embedded in SonarLint, SonarQube, and SonarCloud. This component helps you prevent the leakage of secrets even before you push them into your repository thanks to SonarLint.

Features

  • 140+ secret patterns supported and detected by 90+ rules
  • detection of BIDI characters that could lead to attacks
  • detection of secrets in all files indexed by Sonar products

Build

Prerequisite

  • Java 17

Simple build skipping integration tests.

./gradlew build

Apply code formatting.

./gradlew spotlessApply

Update rule description

Update all rule descriptions.

./gradlew ruleApiUpdate

There are also tasks: ruleApiUpdateSecrets, ruleApiUpdateText and ruleApiUpdateDeveloperSecrets, ruleApiUpdateEnterpriseSecrets ruleApiUpdateEnterpriseText for updating Secrets, Text, Developer Secrets and Enterprise Text and Secrets rule descriptions.

Generate new rule description

To fetch static files for a rule SXXXX from RSPEC, execute the one of following commands:

./gradlew ruleApiGenerateRuleSecrets -Prule=SXXXX
./gradlew ruleApiGenerateRuleText -Prule=SXXXX
./gradlew ruleApiGenerateRuleDeveloperSecrets -Prule=SXXXX
./gradlew ruleApiGenerateRuleEnterpriseSecrets -Prule=SXXXX
./gradlew ruleApiGenerateRuleEnterpriseText -Prule=SXXXX

Generate files to include new secrets

After the change, addition or removal of secret specifications, this script can be run to generate the Java classes that are needed for the inclusion or deletion of these secrets and to update static RSPEC files.

As we use the enforcer plugin to define the file size of the build, this can lead to test failures after adding new secret specifications. The <minsize> and <maxsize> can be changed in sonar-text-plugin/build.gradle.kts (search for enforceJarSize).

If the static RSPEC files are currently not merged on master, it is possible to specify a branch to fetch the files from. This can be done by adding the name of the branch as an argument to the script, like shown below. Use this feature with caution, due to a limitation of the underlying library in the rule api, not all branch names are supported, and it's not clear which ones do work.

./secretSpecificationInclusionGenerator.sh
./secretSpecificationInclusionGenerator.sh branchName

Verify Regexes

The Regular Expressions provided in the secrets specification should be verified to avoid catastrophic backtracking and other issues. Currently, the Sonar products don't scan YAML files for Regex problems. To avoid potential problems the SecretsRegexTest was prepared for validating regexes. There is a simple way to validate all specification files and a single one. Currently, tests are disabled, as the issues need to be reviewed first.

There is also a way of running this check from the command line.

./gradlew --rerun-tasks :sonar-text-plugin:test --console plain --tests SecretsRegexTest.shouldValidateSingleFile -Dfilename=google-oauth2.yaml

License

Copyright 2021-2024 SonarSource.

SonarQube analyzers released after November 29, 2024, including patch fixes for prior versions, are published under the Sonar Source-Available License Version 1 (SSALv1).

See individual files for details that specify the license applicable to each file. Files subject to the SSALv1 will be noted in their headers.