secrets:S8135 wrongfully targeting module references in Terraform

Sonar Cube Cloud

We are getting comments on our Pull request scans. We run Azure Pipelines. The rule reacts to module references in our terraform code.

Hello Stine,
Thank you for your question!
Just from the screenshot it is really hard for me to understand where exactly an issue for S8135 is raised.
Can you maybe share another screenshot from SonarQube Cloud (e.g. when you click on the “See it in SonarQube Cloud” button from the screenshot)?
Is there actually a JWT in the code (or is there anything containing “eyJ” nearby)?

Thanks!
Daniel

Hi! Certainly! There is no actual JWT in the code. However when we look at it in Sonar Cube Cloud it has “inserted” it there somehow. Maybe something about the way it interprets the path to the module in Azure DevOps?

It is also something to note that this is triggering on old unchanged code. So this beta rule seems to not be refined enough. This is pure Terraform code (json), and the module references point to a URL in Azure DevOps where our modules are, so different repositories…

Thank you for your quick reply!
To me it seems that at scan time, the file was changed to include this token, maybe as part of the CI/CD that also triggers the scan?
Do you know if there are any build steps or transformation run on the code before scanning it?

I am very certain that it is not SonarQube Cloud that is injecting this token.

Please also review the token from the screenshot because it was not redacted from the (if it is a long-lived token I suggest to revoke it).

Best,
Daniel

I see what is happening. The pipeline will insert the tokens before deploying the code. It seems the Sonar Scan happens after this step, and therefore it will react to it. Is there a recommended way around this?

That makes sense!
I would suggest to do the scan as an earlier step in the pipeline, before any deployment credentials are inserted in the code to test the same code that is also checked in the version control systems.
I am not sure how exactly that would look like in your pipeline.

I’d also like to inform you that we had already created a ticket to automatically identify files that were changed and potentially not raise any secret rules on them.

We will take this community post into consideration when working on it.