loading...
Cover image for Secure code review: Part 2 - Never store secrets as code

Secure code review: Part 2 - Never store secrets as code

brianverm profile image Brian Vermeer ๐Ÿง‘๐Ÿผโ€๐ŸŽ“๐Ÿง‘๐Ÿผโ€๐Ÿ’ป ใƒป2 min read

Code reviews are hard to do well. Particularly when youโ€™re not entirely sure about the errors you should be looking for! The DevSecOps approach pushes security testing left so that vulnerabilities can be found and fixed earlier, in the design, development, or CI/CD stages of the workflow. Itโ€™s always a good idea to check for security issues in code that you review. In case you donโ€™t know what to look for, check out this series to give you pointers for your next code reviews!

Never store secrets as code/config

Itโ€™s all too easy to store credentials, tokens or other secrets as variables or constants, because hey โ€” weโ€™re just testing it to make sure itโ€™s working. But just as easily this code makes its way into your code repository because you forgot to remove it. We urge you to make sure thereโ€™s nothing sensitive in the code you look through. If youโ€™re using a git-based code repository, there are a bunch of great tools available, like git-secrets, that can statically analyze your commits, via a pre-commit Git Hook, to ensure youโ€™re not trying to push any passwords or sensitive information into your repo. Commits are rejected if the tool matches any of the configured regular expression patterns indicating that sensitive information has been stored improperly. This may slow down pushes a tiny bit, but itโ€™s well worth it.

Having team-wide rules that prevent credentials from being stored as code is a great way to monitor bad actions in the existing developer workflow. Use tools like Vault to help manage your secrets when in production. Lastly, consider using an identity and user management toolchain, like Keycloak (currently maintained by a number of developers in Red Hat) as well as others.

There are many ways to avoid putting credentials into your repository in the first place and itโ€™s best if you tried to implement as many as you can; however, thereโ€™s always the chance some sensitive information may sneak in. You should also consider regularly auditing your repos, making use of tools like GitRob or truffleHog, both of which scan through your codebase, searching for sensitive information via pattern matching.

Want to know more

Check the complete Secure code review cheat sheet

Posted on by:

brianverm profile

Brian Vermeer ๐Ÿง‘๐Ÿผโ€๐ŸŽ“๐Ÿง‘๐Ÿผโ€๐Ÿ’ป

@brianverm

Java Dev | DevRel | VirtualJug Co-lead | UtrechtJUG Co-lead | MyDevSecOps Co-lead | Dutch Air Reserve | Taekwondo Master | Flag Football CB/WR

Discussion

markdown guide