{"id":3981,"date":"2023-03-16T16:02:52","date_gmt":"2023-03-16T16:02:52","guid":{"rendered":"https:\/\/gitprotect.io\/blog\/?p=3981"},"modified":"2024-03-04T14:26:21","modified_gmt":"2024-03-04T14:26:21","slug":"detect-secrets-in-code-with-gitguardian","status":"publish","type":"post","link":"https:\/\/gitprotect.io\/blog\/detect-secrets-in-code-with-gitguardian\/","title":{"rendered":"Detect Secrets in Code with GitGuardian<\/strong>"},"content":{"rendered":"\n

Let’s begin with an undeniable truth: every programmer has, at some point in their coding career, hard-coded secrets into their code. Whether it’s to perform a quick API test or to store credentials temporarily, there’s no denying that it’s a convenient shortcut. However, it’s also becoming an increasingly dangerous threat to the security of codebases.<\/p>\n\n\n\n\n\n\n\n

The Problem of Secrets Sprawl<\/strong><\/h2>\n\n\n\n

The issue at hand is one of magnitude: while most developers recognize that hard-coding secrets is an ill-advised practice, errors still occur often enough to make the situation dangerous for everyone. To put it simply, secrets-in-code, and even more in Version Control Systems such as git, are a reality that must be addressed.<\/p>\n\n\n\n

If you are not yet convinced, please allow me to present the data: according to the largest study on the matter, the  State of Secrets Sprawl 2023 report<\/a>, in 2022, 10 million new secrets were discovered in public GitHub commits. This number, derived from analyzing more than 1 billion new commits, is 67% higher than the preceding year.<\/p>\n\n\n\n

The report also uncovered that 1 out of 10 GitHub code authors exposed a secret in 2022, which indicates that such incidents are not uncommon and are not necessarily related to experience or seniority. Furthermore, what is visible on GitHub is only the tip of the iceberg, as secrets are more frequently exposed in private source code repositories.<\/p>\n\n\n\n

With software development teams managing an ever-increasing number of credentials, there is a heightened risk of secrets being exposed in source code, CI\/CD workflows, container image layers, runner logs, and other areas. This is not only a security issue, but it also affects productivity, as teams must rotate credentials quickly to address the vulnerability, which can disrupt CI\/CD pipelines and bring teams to a standstill. To reduce these risks, organizations should consider shifting secrets scanning left and detecting hard-coded secrets earlier.<\/p>\n\n\n\n

First, let’s review why secrets detection is harder than one might think. We will then look at how to use secret detection to develop an effective policy for protecting an organization’s secrets.<\/p>\n\n\n\n

Why Are Hard-coded Secrets Different from other Types of Vulnerabilities?<\/strong><\/h2>\n\n\n\n

It is important to note that hard-coded secrets differ from other types of vulnerabilities in that they are not execution vulnerabilities.<\/p>\n\n\n\n

This means that they do not require the software to be running to be a vulnerability; rather, from the moment a secret is copied in cleartext in a digital asset, it becomes a security flaw. That’s a fundamental difference with all the security flaws listed in well-known security resources, such as the Common Weaknesses Enumeration Top 25<\/a>, or the OWASP Top 10<\/a>.<\/p>\n\n\n\n

In the event that a developer mistakenly commits a secret, it may either be acknowledged or not.<\/p>\n\n\n\n

In the latter case, it is likely the secret will reach the remote version control system (VCS). At that point, the secret would already be considered leaked (best case scenario, it would be detected at the code review stage, but the secret may already need to be rotated at that point).<\/p>\n\n\n\n

In the former case, one very common mistake would be to delete it and simply commit the change. The secret disappears from the current state of the source code, but it is still in the commit history!<\/p>\n\n\n\n

It is not uncommon to find valid secrets hidden deep inside the codebase history<\/strong>. The bottom line is that, unlike other vulnerability scanning processes, secrets detection needs to take into account this attack surface and<\/em> scan for incremental changes to the repository to prevent these kinds of leaks.<\/p>\n\n\n\n

How to Detect Secret Credentials in Your Repositories?<\/strong><\/h2>\n\n\n\n

From a developer perspective, you want a tool that supports:<\/p>\n\n\n\n