GitHub’s New Security Feature Made Available to Everyone

What Is a Secret?

For GitHub users, the word “secret” has a meaning that’s distinct from the general understanding of the word. In the context of GitHub and software development, a secret is any kind of private information, such as a token, password, or private authentication used by a service provider to enable interactions between applications. The development of software frequently involves the use of secrets and the embedding of those secrets in code.

With secrets, however, comes the risk that a secret has been compromised. A developer might commit a secret to a piece of code without noticing, and by doing so, reveal it publicly — rendering the secret to be insecure. In other words, the secret is not a secret anymore. Its ability to provide unique, private connections is no longer assured. A malicious actor can use the secret as a stolen credential to mount an attack.

---

GitHub’s New Secret Scanning Push Protection

To mitigate the risk of embedding secrets into code and making them public, it is necessary to scan the code for the existence of the secret prior to publishing it. A developer should not use a secret in the code, especially if the code is published on the internet. That sounds simple enough, but there are two challenges in this scenario. One is correctly identifying secrets within the code, as they vary in structure from one service to another. Then, there’s the prevention. How will the developer know if he or she has secrets in their code before publishing it?

GitHub offers a solution. It has offered a built-inservice that detects secrets and alerts developers if those secrets are in their code. This feature is useful, but it only scans code that has already been published. This is not ideal, because it makes application security reactive in nature. Inevitably, some leaked secret vulnerabilities would fall between the cracks. 

The new “push protection” feature, recently announced by GitHub, changes the dynamics of the situation. Push protection checks for more than one hundred types of tokens/secrets as developers push code into production. It blocks the push if it detects the presence of a secret. GitHub describes the process as scanning for what it calls “high-confidence secrets,” which has a low rate of false positives. 

Push protection has two goals. First, it stops secrets from getting into code. Second, it aims to keep code secure without disrupting the developer’s experience. The alerts are built into the developer’s integrated development environment (IDE) or command line interface(CLI). The alert may contain recommendations for remediating the problem. This approach enables developers to review alerts and remove secrets from their code before they push it again. If the suggested remediation does not work, or makes sense, the developer can move ahead with the push by resolving the secret as a test case or false positive. Or he or she can flag it as a real instance but fix the issue later. 

A developer can bypass the push protection.However, in that event, GitHub creates a closed security alert. If the developer flagged a secret as something to deal with later, GitHub generates an open security alert so the developer and repository admin can collaborate on remediation when they are ready to tackle the problem.

---

Why Push Protection is a Big Deal

It may not seem like push protection is a major advance in AppSec. It’s an incremental feature that adds to GitHub’s existing secret scanning capabilities. However, it is a significant development because it shifts code protection from being reactive to proactive. Now, instead of waiting for scans of published code to reveal the presence of secrets, developers can know about secrets before they commit and push the code into production. This makes the code more secure.  

Secret scanning’s push protection is already delivering results. Since its beta release in April 2022, when it was made available to GitHub Advanced Security users, push protection has prevented 17,000 potential secret leaks. This resulted in savings of over 95,000 hours that would have been spent revoking, rotating, and remediating exposed secrets.

---

Conclusion

The leak of a secret exposes applications to risk. Existing reactive methods of detecting and remediating secret leaks were deficient. They were not aligned with the way developers worked, and they allowed for too much time to elapse between the discovery of a leak and its correction, if in fact such a correction ever occurred. GitHub understood that developers had to be part of the solution, empowered to deal with secrets, but in a way that would not negatively affect their productivity or overall experience. Secret scanning’s push protection is the solution. It enables proactive detection and remediation of leaked secrets.

---

Suridata will make sure your GitHub configuration is set to enable the new push protection feature. For more information, contact us.

---