Create Security hotspots for certificate files

Rules and Languages
,
1

We just identified an issue in one project where (against any guidelines) devs put several certificate files in the code repository. While tracking this down I wondered why SonarQube does not flag this as an issue. Hardcoded passwords and keys are flagged as Security Hotspot, I would have hoped there is also rules that identify and flag typical certificate files (like e.g. *.pfx files). But it seems there is not? The pfx files are also not listed in the “Code” Tab in the SonarQube project. Looks like the .net scanner is not collecting these files.

Question 1)
Is there any way how we can configure such files to be flagged?

Question 2)
Could this be added as feature to automatically detect and flag such files as hotspots?

2

Hey @rkg!

It sounds to me like it would be a good idea to consider adding this file extension to your .gitignore file to help prevent sensitive certificate files from being tracked in version control.

I’m not sure we’ve ever gone so far in SonarQube as to raise issues saying “this entire file should not be checked into source control” – but I’ll still pass along the feedback. Today, that kind of check isn’t possible with SonarQube.

4

Hi, in theory, I agree with you, that would be good. In practice we have a lot of different independent teams working on independent projects and I provide central tooling for all of these. I don’t have control over 100 gitignore files :wink: But I have control over Security Tools which could flag this ideally.
In my opinion this fits in the secret detection category very well, its just another type of secret.

Alternatively, a generic feature which could be configured to flag files based on Regex or other rules, including some default suggestions, could be a good idea, too. I could think of possible other files for which this could be useful.

6

Hello @rkg,

I think it would make sense to detect when certificate files containing private keys or other sensitive data are pushed to a repository. It is important that we do not store or disclose the contents of these files; rather, we should simply notify users that such files should not be stored in a Git repository.
We recently added a rule similar to this but specific to Java Keystore: Java Keystore files should not disclose cryptographic private keys

I am considering a more generic rule, tentatively titled: “Certificate files should not disclose cryptographic private keys”.

I could think of possible other files for which this could be useful.

Could you share any additional file types or scenarios you have in mind?

Thanks
Alex

8

Hi,
yes that sounds good.

Some ideas:

  • JAVA Keystore would have been one of the other examples.
  • All kind of typical private certificate/key filetypes would be interesting, like *.pem, *.key, *.crt, *.p12, *.pfx,
  • Typical SSH private keys like id_rsa, id_dsa
  • Possibly could also flag *.env files as hotspot for review as often secrets are stored there (though, this might need some consideration as it may contain other values as well and might not fit into this rule directly)
  • Thinking even more generic possibly: Files named *credentials*.* or *secrets*.*, would catch potentially e.g. credentials.yml files or others
  • typical product specific files for widely used products/systems like .aws/credentials, .vault-token, …

Probably a lot more possibilities here

Greetings

Ralf

1 Like