I’m trying to set up Sonarqube logging, but am having trouble finding the logs I need. For security, I need to have access and configuration changes logged. I was able to get user logins logged through the DEBUG loglevel, but can’t find any logs related to system configuration changes. I have even tried at the TRACE loglevel, but the closest I can get is parsing the raw SQL update statements on configuration changes, which is far from ideal.
Does anyone know of any resources that could help with this task? Ideally, I would like to be able to log which user made the change, which setting was changed, and what the new value is.
Alternatively, is this something that is possible with a plugin? After looking through the documentation, it didn’t seem like there were any extension points suitable for this.
- I tested on both Sonarqube 7.3 Community and an Enterprise trial
We simply don’t audit-trail that stuff. Could you share your use case? It might influence our future thinking…
Thank you for the quick response! We are looking to audit Sonarqube systems to comply with NIST 800-53 (and similar) regulations so it can be integrated into a continuous deployment pipeline.
For what it’s worth @dan: SonarQube does let you track record all incoming HTTP requests if you wish to do so. Check-out
sonar.properties. As Ann mentioned there is no functional changelog in the UI, but should you have any need to trace down a specific interaction with the SonarQube server,
access.log can give you some visibility into that.
Dan, Nico and Ann,
I think a changelog/activity section for configuration changes would be tremendously helpful. The common question of “did something change?” when there is unexpected behavior is currently hard to answer.
Especially for analysis settings that can be set from the UI as well as from the scanners, it usually requires digging into build logs and/or server logs to get any clues, and you have to know exactly what you’re looking for (this is why I differ slightly @ganncamp’s view on setting analysis settings from the UI. Version controlled scanner settings help a lot in troubleshooting).
Looking at how the configuration management tool Puppet handles changes (in the attached screenshot, for the Puppet classifier), it’s easy to get a sense of what changed and when.
This has proved invaluable for troubleshooting. Even just knowing what the settings were before changes were made makes it easy to quickly (and correctly) revert if neccesary.
+1 for a configuration changelog.
#metoo - a configuration change-log would be tremendously useful. I’ve just spent a day trouble-shooting why the code duplication measure shot up on my project despite no-one working on the files in question. It turns out that the pattern-matching for the excluded files in the
sonar-project.properties file has changed, presumably as a result of a configuration change (or version upgrade). Last month I spent a week trouble-shooting why all our CI/CD pipeline builds were failing; this turned out to be because someone had enabled the community build-breaker plug-in in SonarQube without telling anyone. Being able to see what has changed at a glance would have saved an awful lot of time and stress!