Travis CI Security Advisory: Secured Environment Variables
blog.travis-ci.com
Travis CI Security Advisory: Secured Environment Variables
1–10 of 38 posts
Re: Travis CI Security Advisory: Secured Environment Variables
#2Secrets in environment variables is such a bad security anti-pattern, and it seems to be getting more popular.
Re: Travis CI Security Advisory: Secured Environment Variables
#3Secrets in environment variables is such a bad security anti-pattern, and it seems to be getting more popular.
What is a better pattern?
Re: Travis CI Security Advisory: Secured Environment Variables
#4While I love travis for what it is, this is a foreseeable result here.
At the very least they need to add a failsafe that checks all outgoing logs for any secure tokens and replaces them with '*' or something.
If you sign up to play a game of whack-a-mole you will lose eventually.
Re: Travis CI Security Advisory: Secured Environment Variables
#5Secrets in environment variables is such a bad security anti-pattern, and it seems to be getting more popular.
What is a better pattern?
I'd love to know, too. Best as I can tell, the only really secure option is to read them in from STDIN.
Depending on how the process is running, it may also be reasonably secure to read the secrets from files. But getting this right is tricky, and really prone to human error: all it takes is one errant chmod/chown to remove the security.
Honestly, given the challenges of those options, keeping secrets in environment variables seems like a reasonable compromise to me.
Re: Travis CI Security Advisory: Secured Environment Variables
#6Secrets in environment variables is such a bad security anti-pattern, and it seems to be getting more popular.
What is a better pattern?
I've seen secrets stored in special files, or personally I prefer something like https://www.vaultproject.io/, which may still use environment variables, but they can potentially be passed in in a more secure, controlled way.
Re: Travis CI Security Advisory: Secured Environment Variables
#7While I love travis for what it is, this is a foreseeable result here. At the very least they need to add a failsafe that checks all outgoing logs for any secure tokens and replaces them with ' *' or something. If you sign up to play a game of whack-a-mole you will lose eventually.
That's actually exactly what the stated mitigation they've implemented is, if I've read it correctly. Though they're working on building it into their VM images in order to reduce the memory overhead of the filter.
Re: Travis CI Security Advisory: Secured Environment Variables
#8Secrets in environment variables is such a bad security anti-pattern, and it seems to be getting more popular.
What is a better pattern?
Encrypt the data at rest with an encryption appliance (HSM). Or use a key management service[0][1] to store encryption keys that can be used to decrypt your at-rest data.
Re: Travis CI Security Advisory: Secured Environment Variables
#9Re: Travis CI Security Advisory: Secured Environment Variables
#10When I submitted a pull request to a random open source project, I was surprised to see a travis build kick off immediately.
Is there a chance for rogue pull requests to contain (build) code that dumps out travis environment secrets? I didn't explore this but obviously the code is being built by scripts that are part of the commit.