Identify Azure DevOps Project Origin After Code Scan

[sonarprincipal (Sonar)]

Hi all,

We’re currently running SonarQube Community 9.9.3 in AKS to scan code from Azure DevOps.

We’re using SSO for users to sign into SonarQube and investigating locking down the scans within SonarQube to only those people with access to the originating project in DevOps. If we scan code from a DevOps project named “TEST”, then we only want people with access to the “TEST” project to be able to see the scan within SonarQube.

Currently, everyone with access to log into SonarQube has access to all scan information. This allows the source code to be viewable by anyone with access to SonarQube.

From looking at a scan in SonarQube, there doesn’t appear to be any way to identify which DevOps project that the code originally came from.

My first thought was to name the SonarQube project in a way that the DevOps project name would be included such as TEST-pipeline name. Then creating a tag with the DevOps project name “TEST” within SonarQube so that pipelines from that project can be identified within SonarQube. From there, hopefully we could use groups to lock down access to specific project tags.

Is this feasible? Does anyone know of a better way?

[ganncamp (G Ann Campbell)]

Hi,

How are you adding projects to SonarQube? If you’re importing them from a DevOps platform, then I believe you’ll be able to see that in project administration. If they’re not imported, then naming conventions are your best option.

And on a related note, you may be interested to know that in Enterprise Edition($$) we offer SCIM provisioning for Azure AD and Okta.

 
HTH,
Ann

[sonarprincipal (Sonar)]

Thank you for the recommendation.

On the DevOps side, we set up a SonarQube service connection and tied it to the Security Token that we generated on the SonarQube side. In this instance, I believe the naming convention may be the best option.

Are there any limitations to using DevOps Platform Integrations for Azure DevOps with the Community edition?