We know that secrets are necessary to tie together different components of an application. Development and Operations teams need constant access to these secrets to build, connect, test and deploy applications. As a result, secrets represent a special type of information that needs to be both tightly-wrapped and widely-distributed.
It is no secret that enforcing good security practices at the organization level is hard. Developers today are faced with large turnover inside companies, and are often spread across many different teams and geographies. They must master a growing number of technologies and are under increasing pressure due to shortened release cycles. This makes secret management very complicated and an ever-changing challenge.
This is further complicated when VCS like git are introduced because secrets can be buried deep inside the history. The current version of source code might look clean, while the history might contain credentials that were added, removed, and then completely forgotten about. Valid secrets in the git history represent a real threat and any secret that reaches the VCS must be considered compromised.
---
Storing and managing secrets like API keys and other credentials can be challenging. Even the most careful policies can sometimes be circumvented in exchange for convenience. We have put together a helpful cheat sheet and article explaining the best practices for managing secrets.
As a minimum here are some points you should consider:
---
At GitGuardian, we’ve been monitoring every single commit pushed to public GitHub since July 2017. Three and a half years later, we’ve uncovered millions of secrets and millions of pro bono alerts to developers. The State of Secrets Sprawl report measures this exposure of secrets within public repositories on GitHub and how this serious threat is evolving year to year. It also includes an in-depth study on the state of secrets sprawl in corporate repositories and Docker Hub.
git reset --soft -HEAD