Hey folks, just wanted to share a little automation win from our latest migration project. We've been rolling out SonarQube across our dev teams, and one recurring pain point was that security hotspots were just sitting there unassigned after scans. The manual process of figuring out who "owned" which piece of code was a real time-sink.
I whipped up a Python script that ties into our Git history and the SonarQube API to auto-assign new hotspots. It basically looks at the last significant contributor for the flagged file and assigns the hotspot to them. It’s cut down our initial triage time massively.
Here’s the core idea of how it works:
- It pulls the list of new security hotspots from the SonarQube API (using the `hotspots/search` endpoint).
- For each hotspot location (file path), it uses Git blame (via a simple subprocess call) to find the last main author for that line/block.
- Then, it uses the `hotspots/assign` endpoint to assign that hotspot to the corresponding user in SonarQube (assuming their emails match up).
A couple of things we had to watch for:
- You need to handle service accounts or bulk commits (like massive reformats) – we added a filter to skip authors with "bot" or "noreply" in their email.
- SonarQube user emails need to match the Git commit emails, or you'll need a mapping table.
- We run this script as a post-processing step in our CI pipeline right after the SonarQube scan completes.
It’s not perfect, but it gets about 90% of assignments right and the team loves that they get notified about their own security issues directly. It really improved engagement with the hotspot review process.
If anyone’s interested, I can share the Git mapping logic snippet. It’s been a game-changer for us in terms of data quality and workflow automation around our code reviews.
- Kev