# Project environment variables in light of CodeCov leak **URL:** \ **Category:** Build Environment\ **Tags:** configuration, security\ **Created:** [April 16, 2021, 7:24am UTC](https://discuss.circleci.com/t/project-environment-variables-in-light-of-codecov-leak/39800 "2021-04-16T07:24:43Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![MichaelMarner](https://sea2.discourse-cdn.com/circleci/user_avatar/discuss.circleci.com/michaelmarner/32/22998_2.png) [@MichaelMarner](https://discuss.circleci.com/u/MichaelMarner)\ **Post date:** [April 16, 2021, 7:24am UTC](https://discuss.circleci.com/t/project-environment-variables-in-light-of-codecov-leak/39800/1 "2021-04-16T07:24:43Z")
So, in light of today’s massive [CodeCov disclosure](https://about.codecov.io/security-update/?utm_medium=email&utm_source=marketo&ajs_uid=2861519&ajs_event=Clicked%20Email&mkt_tok=MzMyLUxWWC03NDEAAAF8dJ45hWTcjAJel_5o6AuIqsnTQL6jIYP0NFpdpQ9oJ_Z-OcT4nU6DZbi2fwKhSzBjC9yR2HAIHJrEB81F2ljC1kCsPJbs8JUlu_rHH_gG), 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](https://www.jenkins.io/doc/pipeline/steps/credentials-binding/), which ensures the credentials are scoped to only that block - Solutions using, for example, [Hashicorp Vault](https://www.hashicorp.com/resources/hashicorp-live-with-vault-and-circleci-injecting-static-secrets-into-a-pipeline) still require the authentication for Vault to be stored in an environment variable. I see that the CodeCov orb has been [updated today](https://github.com/codecov/codecov-circleci-orb/commit/c0d83fd24d357fba451215c6511582ca1e36b6e5) 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. ---
**Author:** ![acorncom](https://sea2.discourse-cdn.com/circleci/user_avatar/discuss.circleci.com/acorncom/32/3183_2.png) [@acorncom](https://discuss.circleci.com/u/acorncom)\ **Post date:** [April 19, 2021, 7:52pm UTC](https://discuss.circleci.com/t/project-environment-variables-in-light-of-codecov-leak/39800/2 "2021-04-19T19:52:31Z")
> [@MichaelMarner](#): > > 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. 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 … ---
**Author:** ![acorncom](https://sea2.discourse-cdn.com/circleci/user_avatar/discuss.circleci.com/acorncom/32/3183_2.png) [@acorncom](https://discuss.circleci.com/u/acorncom)\ **Post date:** [April 19, 2021, 7:54pm UTC](https://discuss.circleci.com/t/project-environment-variables-in-light-of-codecov-leak/39800/3 "2021-04-19T19:54:44Z")
Actually, looks like it’s now doable using security contexts ([Using Contexts - CircleCI](https://circleci.com/docs/2.0/contexts/#restricting-a-context)) ---
**Author:** ![zbencz3](https://sea2.discourse-cdn.com/circleci/user_avatar/discuss.circleci.com/zbencz3/32/27384_2.png) [@zbencz3](https://discuss.circleci.com/u/zbencz3)\ **Post date:** [November 23, 2021, 12:48pm UTC](https://discuss.circleci.com/t/project-environment-variables-in-light-of-codecov-leak/39800/4 "2021-11-23T12:48:21Z")
@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.