I use Sonarqube version developer edition v10.5 1 to scan the source code. However, I notice that the .env file is not analyzed. Does sonarqube no longer support scanning .env files?
Hey there.
We don’t currently analyze dot-prefixed files.
1 Like
Thank you for answer.
Can you tell me the reason for not analyzing dot-prefixed files?
It’s ultimately a decision made nearly 14 years ago (SONAR-1467), so I probably can’t get down to an exact “why” – but at least back then, it was rare for hidden files to be code that you cared about.
However, I don’t think it’s safe for us to assume we should now analyze all hidden files, so we have to figure out the right solution.
1 Like
Thank you for answer.
This is extremely important, mainly to .env files since developers could be mistakenly committing secrets into these files.
One way this should at least be possible is by adding specific entries to the inclusions list in the sonar-project.properties file.
i.e.: sonar.inclusions=**/.env,**/.env.*
I’ve just tested this and it does not work, but even if SonarScanner does not by default scan any files starting with . in their name I would expect the above to force Sonar to scan it.
1 Like
As a follow up I’ve performed 3 tests:
- Added
.env*to thesonar.inclusions - Renamed
.env.sampletosample.env - Renamed
.env.sampletosample.envand added*.envto thesonar.inclusions
Neither worked, meaning that the problem of Sonar not scanning .env files does not seems only related to SonarScanner not scanning files starting with . but also the fact that Sonar doesn’t have the ability to scan .env files.
1 Like
I also tried the above pattern and all of them did not work.
Hi @felipeplets
Have you checked if the .env extension is also mapped to the Secrets language?
This is the default on SonarCloud, if I am not mistaken, but it might not be on SonarQube, depending on your version.
If you have both this mapping and a file named sample.env, I believe it should be analyzed.
Denis.