Private pipeline's code can be seen via SonarQube project.

[kumada626]

What happened: The code in the private pipeline should not be seen by anyone other than permitted users. However, if the private pipeline use coverage feature, Screwdriver sends the private pipeline's code to SonarQube. Since SonarQube project's permission is not linked to scm's permission, the private pipeline's code can be seen by not permitted users on the scm via SonarQube project.

What you expected to happen: Private pipeline's code should not be sent to SonarQube. If users want to use SonarQube anyway, users add force enable flag for example.

How to reproduce it:

[jithine]

I think projects in sonarqube's permission can be controller, we might be making it public for all. Need to handle separately for private repositories.

cc @tkyi

[tk3fftk]

I took a look at GitHub integration of SonarQube. There is an option to sync GitHub teams in an organization with SonarQube groups. (It looks that there is not detailed information in the document about Group Mapping with GitHub.)

This feature has some limitations:

• We have to use GitHub authorization.
• User have to use GitHub organization and GitHub teams to join SonarQube groups automatically.
• In SonarQube, admin have to create groups named in the form of Organization/Team.
• I don't know how to sync permissions of GitHub org/teams especially including private repositories with corresponding SonarQube groups. It looks just adding users to groups.

[jithine]

@kumada626 @tk3fftk I believe this can be solved by making project permissions Private https://docs.sonarqube.org/latest/project-administration/project-existence/

We used to do that before, but then we removed that option.

https://github.com/screwdriver-cd/coverage-sonar/pull/41#pullrequestreview-456159325 https://github.com/screwdriver-cd/coverage-sonar/blame/7f3c20727d9d5ddcf951e8e53a48a7f7ff6710fa/index.js#L32

Perhaps what we can make projects Private by default if underlying Git repository is Private. We can then add the current user who is creating the SD Pipeline as admin user in the Sonar Project and let that user grant further access to rest of the team.

[tk3fftk]

@jithine Did you mean it's kind of sync permissions for Private Git repos and Private SonarQube projects? It may be feasible but I think it's a little vulnerable🤔

A user of SonarQube doesn't have much information about GitHub like GitHub ID (number) or other identity providers. For example, the below JSON is a response of /api/users/search?q=<my-github-account-name> API of GitHub integrated SonarQube. This API may be the only way for obtaining user information.

{"paging":{"pageIndex":1,"pageSize":50,"total":1},"users":[{"login":"hiroki-takatsuka98350","name":"Hiroki Takatsuka","active":true,"email":"<my-email>","groups":["sonar-users"],"tokensCount":0,"local":false,"externalIdentity":"<my-github-account-name>","externalProvider":"github","avatar":"305687a6d16d797401ccd42e851baf61","lastConnectionDate":"2021-10-11T07:31:32+0000"}]}

How about asking to SonarQube Enterprise support team?

[jithine]

@tk3fftk I don't think we should do any sync.

All we can do is when creating a sonarqube project we can mark it as private if Git repository is private. But we can't do anything for existing projects, maybe an offline script to adjust permissions.

[kumada626]

I understand about the proposed solution. However, in some cases, that solution is a bit cumbersome to manage permissions on SonarQube projects. It would be happy to have feature flag that prevent to send coverage info to the SonarQube if the pipeline is private.

[jithine]

It's not possible to prevent scanner from sending coverage info, since coverage calculation happens on sonar server. This is the response we got from SonarQube support as well.

It is not possible to avoid source code to be sent to SonarQube, the reason is the way analysis is done.

Let me explain you that.

On the scanner side the scanner runs the analysis and raises issues, then a report is created and sent to SonarQube.

This report contains sources, issues, coverage informations, etc...

Then this report is consumed by a background task to match issues with sources, coverage with sources, etc... many metrics are computed at this time.

So for that reason it is not possible to avoid source code to be sent to SonarQube.

However, inside SonarQube you can restrict the access to the source code to whoever you want.

For example, the private code is modified by some devs and maybe a project manager is supervising it. Then you can restrict the view of this source code only to those individuals. simply remove the browse permission at project level and grant only the desired persons for that.

[kumada626]

I see. However, if SD_SONAR_OPTS env is set in the template which is used in the private pipeline, users might send source code to the SonarQube unintentionaly. So we would like to have feature flag that prevent to execute coverage step unless the user intends to do so if the pipeline is private.

[jithine]

@kumada626 We have few options

1. Use existing SD_COVERAGE_PLUGIN_ENABLED as feature flag and make add it to build defaults if pipeline is private pipeline. (Need code change to add it to default if pipeline private, else we need to see if there is a central template then it can enforce this requirement)
2. Modify Sonar project creation flow to make the project private and add only current admin user (or all known admins) as the user with permission to view. Then let that user handle further granting for permissions to rest of the teams.

[ibu1224]

@jithine @tkyi @kumada626 and everyone

To develop with @jithine's comments (1, 2), we first need to be able to determine that it is a private pipeline.

I have come up with a first step to resolve this Issue. Please let me feedback. As soon as we get agreement, we will proceed to development.

The current system may cause source code to be sent to SonarQube without the user's intention. For example, If you are using sd template and the default SD_COVERAGE_PLUGIN_ENABLED is true.

Therefore, if you are using a private pipeline, do not send the source code until you find a solution. Below are some ideas to achieve this.

1. Create a flag that allows you to determine that it is private pipeline.

Where should flags be managed? (Metadata? Env?) I think it should be managed by environment variables.

The reason is that Metadata can be overwritten by users. In the case of ~PR, malicious users may be able to overwrite the metadata. Overriding a private flag may cause the source code to be sent. In the case of environment variables, the readonly command can be used to prevent overwriting. readonly is available in most shells.

By modifying the following part, it can be managed by environment variables.

• Environment variables are set in launch.go.
  • add new environment variables to this list. (ex: SD_PRIVATE_PIPELINE)
  • You can tell if it is private by contacting the API. This is already implemented.
  • Get pipeline objects. pipeline objects.

2022/04/12 Added
At the web meeting I heard that in the future it should be developed with 2 flow. By using the private flag it is possible. You can get it from coverage-sonar if it is set in the build's environment variable. The first step is to provide the private flag.

2. The flag created above is used in the coverage-sonar.

Temporarily prevent communication to SonarQube until SonarQube is available in the private pipeline.

Modify as follows.

• Add private flag determination to commands.txt.

This is the first step to be able to use sonarqube in a private pipeline. We need to continue to think about the flow of using SonarQube in a private pipeline.

[ibu1224]

@jithine @tkyi @kumada626 and everyone I have modified my comment in the feedback at yj. Please see again.