> Credentials are stored in lib/credentials.json. This is checked into the repo, so USE A PRIVATE REPO.

It's called a "private" repo, not a "secure" repo.

The point of a private repo is to give you control over your collaborators. It is not to provide information security. To my knowledge, Github makes no special promises about the security of private repos. The data is not encrypted on disk at Github, and Github staff can access the content of your repo.

I WOULD NOT UPLOAD SECRETS INTO A GITHUB PRIVATE REPO.

Would you put secrets into a circleci environment variable? https://circleci.com/docs/2.0/env-vars/

That might be an improvement over checking in the json file, as I suspect (from a very brief look) that that is why the json file is checked in.

If I'd decide to keep the secrets in the repo, I would have them encrypted with e.g. GnuPG and put a key in the CI's environment variables.

    # Something in lines of this...
    # TODO: Make sure the keyrings are on tmpfs, too.
    # Something like export GNUPGHOME="/run/gnupg" && mkdir -p "$GNUPGHOME"
    gpg2 -v --import <(echo "$GPG_PRIVATE_KEY")
    gpg2 --decrypt --output /run/secrets/credentials.json lib/credentials.json.gpg
    ln -s /run/secrets/credentials.json lib/credentials.json
For this I have to trust the CI, of course... And given that CI jobs run in isolated environments but on a shared hosts, there could be a way for malicious party to access the data. IIRC, there were some exploits that break out of Docker.

If you host in the cloud that offers a KMS (AWS, GCP, Azure), a slightly advanced alternative is SOPS: https://github.com/mozilla/sops (you can use that with GnuPG as well)