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.
- 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
Prerequisite
- Java 17
Simple build skipping integration tests.
./gradlew build
./gradlew spotlessApply
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.
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
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
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
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.