I am developing a custom python package, for this I was interested in logging the package at different stages. In order to achieve this I was using “Logging” module in python as the logger. When I ran the package through the Sonarqube for the code smells and security hotspots, I found that there was one security hotspot raised which was due to logging instantiation. Below is the code, that depicts my logging instantiation:
Below I attach the image showing the security hotspot issue from Sonarqube:
I had gone through the rules that were specified by Sonarqube regarding this, but still I was not able to solve this issue.
So, I could you please help me to solve this. or Is it a false positive issue?
I am looking for best practices to log within in the rules of Sonarqube.
Must-share information (formatted with Markdown):
Sonqrqube version : 220.127.116.11735
The goal is not to fix the issue (prevent it from being raised), but to guide you in reviewing your code and deciding for yourself. As noted in the documentation:
What is a Security Hotspot?
A Security Hotspot highlights a security-sensitive piece of code that the developer needs to review. Upon review, you’ll either find there is no threat or you need to apply a fix to secure the code.
Vulnerability or Hotspot?
The main difference between a hotspot and a vulnerability is the need of a review before deciding whether to apply a fix:
- With a Hotspot, a security-sensitive piece of code is highlighted, but the overall application security may not be impacted. It’s up to the developer to review the code to determine whether or not a fix is needed to secure the code.
- With a vulnerability, a problem that impacts the application’s security has been discovered that needs to be fixed immediately.
I hope this makes sense – they are a little different than the “Issues” concept you might be used to in SonarQube (Bugs, Vulnerabilities, and Code Smells) where if we’ve done our job right in reporting them, something needs to be fixed.