From Check user information API Rest SonarCloud - #4 by Colin, we know that “tokens exist at a user-level rather than an organization-level, and an organization admin doesn’t have the right to know how many tokens a user has that span many organizations”.
For organization that paid SonarCloud for private repository analysis, the practice of SonarCloud token opens security risks because:
- Organization member can login to SonarCloud and has permission to read source code from SonarCloud.
- Organization member then can create SonarCloud token, possibly for CI-based analysis (because it’s required) or for other means.
- Now, the security risk of source code leak is not only from access to GitHub account of that member or the GitHub PAT (Personal Access Token), but also SonarCloud token(!).
- Organization can’t see the access log if this token is used to access source code either because there is no access log at all.
- Organization can’t see which member that has generated the token.
- Organization don’t have the control of the token.
- The token has no expiry.
- The token doesn’t have any specific pattern, just 40 characters of hexadecimal, making it harder to exactly detect if a certain string is SonarCloud token or not (for hardcoded secret prevention).
If we find sonar.login in GitHub, we can see some hardcoded SonarCloud token.
An organization team member can commit the secret to public by mistake and the organization will not know. This is not good because usually organization only think about GitHub token and GitHub can prevent the token to be committed.
One practice that we may use is by only using one central account to generate token and use it for all CI-based analysis, but organization members still need to have access to read source code so they can review the findings. And because we can’t control how the organization members generate/use the token, then the only final option is to educate. I know educating the developers about token usage and hardcoded secret is important but the security risks of current practice of SonarCloud is something that I think many organization should know, especially if they use or consider to use paid license.
As a security tool vendor, many organizations will expect SonarCloud to do better regarding security practice. Is there anything in roadmap that will help organization have more control regarding token access? Maybe a feature to disallow token of organization members to perform certain action (e.g., read source code) is enough.
Thanks.