Project environment variables in light of CodeCov leak

Build Environment
,
1

So, in light of today’s massive CodeCov disclosure, I was wondering what CircleCI can do to reduce the impact of this kind of vulnerability.

Apart from environment variables, what other mechanism can we use in CircleCI projects to store credentials?

  • Jenkins has withCredentials, which ensures the credentials are scoped to only that block
  • Solutions using, for example, Hashicorp Vault still require the authentication for Vault to be stored in an environment variable.

I see that the CodeCov orb has been updated today to at least check the shasum of the uploader script, so this particular attack will no longer be possible. But more generally, how can credentials/secrets be scoped so they are only accessible for certain jobs (eg a deploy job in a larger pipeline), or even a single step in a job.

There’s no need for the test job in a pipeline to have access to any credentials relating to deployment, and yet environment variables can only be set at the project level.

2 Likes
2

This would be lovely. I’ve asked about it years ago (back in CircleCI 1 days) as currently, anyone with PR access can gain access to all environment variables due to SSH access. It’d be nice to reduce that level of access …

3

Actually, looks like it’s now doable using security contexts (Using Contexts - CircleCI)

4

@acorncom yes, I agree that security contexts would help with restricting visibility for users not part of the special group, but I assume that would not help with securing the secrets from a Codecov style attack where the script on the Codecov side was altered and because that has access to the environment variables, it can pass it on to the attacker. I hope I wasn’t missing something, and the original question here still needs a followup/solution.