Over the next few weeks we will be rolling out a new feature called secret masking. This will obscure environment variables from projects and contexts, and prevent them from being echoed out in users’ builds. We’ve just started the incremental rollout to all users, and over the next few weeks, this feature will be live on all of our resource/executor types.

What does this change for me?

With secret masking, if you inadvertently echo, or print, your environment variable or context, we substitute it with XXXXX. Before the build logs are printed out by the UI, CircleCI scans the logs’ output to ensure there are no secrets printed that match against the names of project or context environment variables.

Why did you build it?

Our customers have asked for safeguards against accidental secret exposure, and we’re happy to now be able to provide this additional level of protection. We see it as a crucial step forward for proactive and intelligent security measures. Inadvertent secret leaking can be a sizable concern in open source projects, for example, which have many unknown contributors, or in large companies with many people working on repositories. In both of these scenarios, the cost of accidentally leaked secrets is high.

Security tips for using secret masking

From a permissions perspective in CircleCI, users with access to builds are considered trusted. For this reason, secret masking pairs well with restricted contexts as it limits the set of trusted users who are allowed to authorize access to a restricted group of contexts. If a user already has access to your source code and can inject malicious commands, then secret masking will not provide a surefire defense against the commands that those users are running.

Secret masking works well in a model where there is trust for the actor involved. There are times where builds scripts can easily and accidentally get mixed up in commits and output build secrets. While secret masking is effective at preventing people from inadvertently printing out secrets, it will not stop anyone from employing SSH and running the echo manually. It also won’t prevent someone from writing or using the secret and uploading the value elsewhere.

If you are dealing with untrusted actors, it is much more secure to switch to a fork model and pass none of the secrets, or restrict the actors allowed to run a job with the secrets injected.

By using restricted contexts and secret masking together, you can achieve sizable security improvements by preventing intentional and unintentional secret leaking.

A few gotchas to be aware of:

  • Secrets below 4 characters will not be masked.
  • Secrets with the values true, TRUE, false, FALSE will not be masked.
  • This does not prevent secrets from being displayed when you SSH into a build.

If you don’t see secret masking already available for your team, you should gain access to it over the next few weeks. Once enabled, you’ll have it automatically available. In the meantime, if you leak a secret, please rotate your secrets as quickly as possible.

First access

If you’d like your team to be first on the access list, sign up here: https://forms.gle/ncmgri9bWSHSLh2k9.