Set project link on first scan

bitbucket
sonarcloud

(ESD) #1

I noticed that bitbucket have this API https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/{username}/{repo_slug}/properties/{app_key}/{property_name}

While I haven’t yet figured out what property_name(s) sonarcloud uses. A PUT request to https://api.bitbucket.org/2.0/repositories/itmindsdk/sonar-ng-test/properties/sonarcloud/{???} should be able to set the project link value.

Now I’d suggest that when a scanner uploads an analysis to sonarcloud if the project doesn’t already exist, sonarcloud should call the bitbucket API setting the project link value.
This should set the correct project link for the repo and start displaying code quality stats when the first scan is completed.

image


(ESD) #2

In the mean time if you could supply me with the property names then I can call the API myself from a pipeline script.


(Julien Henry) #4

Hi @Snebjorn

When SonarCloud receives an analysis report, the authentication in action is the SonarCloud one (thanks to the token). Anyone can submit an analysis in its own SonarCloud organization and create new projects.

How can we know for sure that the analysis report we are receiving:

  • really correspond to the Bitbucket Cloud project it says?
  • was authorized by the Bitbucket Cloud project owners?

The scanner uses environment variables to know the team/repository/branch the project belong to. But this is not trustable. Anyone can fake an analysis (even on Bitbucket Pipelines) to pretend it come from a different repository (even a private one).

The only way we have found so far is to require the binding to be done separately from the analysis: the link should be configured in Bitbucket Cloud project administration page (so obviously you are a Bitbucket Cloud project admin), and the drop down is populated based on your SonarCloud authentication (you can only bind with SonarCloud projects you are admin of).

I know this is far from being perfect, and we are working on improving that.

Regarding the possibility to store the binding on Bitbucket side instead of SonarCloud side (using the /properties storage) we discovered this possibility late in the development, and it has the opposite security concern: any Bitbucket Cloud admin could set the value, and pretend that the Bitbucket Cloud project is bound to a SonarCloud project he is not admin of, or even a private SonarCloud project he can’t normally access.


(ESD) #5

Thanks for replying.

Okay seems the matter is a bit more complicated than I first assumed. But good to know you’re working on improving it :slight_smile: