Secrets, such as passwords and credentials, are out in the open just sitting there in code repositories. Why do these secrets even exist in public? What’s their danger? And how can they be found and removed?
Check out this post for the basis for our conversation on this week’s episode which features me, David Spark (@dspark), producer of CISO Series, co-host Allan Alford (@allanalfordintx), and our sponsored guest is Jérémy Thomas, CEO, GitGuardian.
Thanks to this week’s podcast sponsor GitGuardian
Got feedback? Join the conversation on LinkedIn.
On this episode of Defense in Depth, you’ll learn:
- Putting passwords and other credential information inside of code simply happens. It is done by developers for purposes of efficiency, laziness, or simply forgot to take it out.
- Given that exposing secrets is done by developers, these secrets appear in code everywhere, most notably in public code repositories like GitHub.
- Exposed credentials can appear in SIEMS as it’s being exported from the developers’ code.
- There is a shared responsibility model and cloud providers do have some ability to scan code, but ultimately code you put in your programs is your responsibility.
- Scanning public code repositories should be your first step. You don’t want to be adding code that has known issues.
- Next step is to scan your own code and get alerts if your developers are adding secrets (wittingly or unwittingly) in their code. If you alert in real-time, it fits naturally within the DevOps pipeline and they will improve their secure coding skills.
- Another option to deal with exposed secrets is to sidestep the problem completely and put in additional layers of security, most notably multi-factor authentication (MFA). A great idea, and yes, you should definitely include this very secure step, but it doesn’t eliminate the problem. There are far too many authentication layers (many automated) for you to put MFA on everything. There will always be many moments of exposure.
(CC BY-NC 2.0) photo attribution to Flickr user Doug.