Our internal Security guys have asked for a way to get an email or message to a teams channel for anytime someone changes the status of a security issue or hotspot.
Basically what they want is, if someone marks something as accepted, or false positive, without fixing it, they want a notification to review it.
I could use a PowerAutomate workflow with a webhook to detect events and trigger a teams message like I already do for Azure monitor alerts, but the problem is that SonarQube server only generates an event when the quality gate state changes.
Does anyone have an suggestions about another way to do this?
The only thing coming to mind is periodically doing an API query of all issues and hotspot states, storing them in a DB, and then alerting if open or to_review, changes to another state, for issues of type Security, or hotspots. This seems a bit much, and I’m hoping there is a better way, or some way that it could be enabled to send a webhook on ALL issue status changes.
Two things come to mind here, neither of them elegant.
The first is permissions: Lock everyone out of accepting issues except the Security folks. When a dev wants to accept an issue, they’ll need to contact Security to have it done.
The second is issue ownership. Create an account (a local one?) in SonarQube that ties to security.folks@my.co and assign all the relevant issues to it. Then sign the account up for notifications on “Changes in issues/hotspots assigned to me” and SonarQube will handle sending the emails. The only hard part is catching and assigning new issues, but we already have webhooks that run after an analysis so that part is relatively straightfoward.
Is there a way to lock people out of all security issues, but still let them administer maintainability, or reliability?
“Security Hotspots” are their own thing permissions wise, but I don’t see a way to lock them out of only Security type “issues”. Seems very weird to me that hotspots are their own thing, but security issues are classified like any other issue, and are somehow different to hotspots.
Ideally there would be some flexibility in saying only a certain group could administer Security issues, or better yet, Security issues worse than a certain rating.
To be honest, the industry has matured, but our permissions structure has not. The current structure is based on the thought that “You trust your developers or you don’t.” Security Hotspots, as a concept, came along later, with a more nuanced understanding. That’s why they have a separate permission.
This is flagged for PM attention, but I wouldn’t hold my breath on anything changing soon.