If you are serious about DevSecOps for your organization, you probably know what shift left is. Shifting security left ensures vulnerabilities are not audited only at the end of the development cycle. By automating vulnerability scanning all along the development process, you can keep application security engineers working on higher-value tasks. On the other hand, developers want to keep their workflow optimized for speed, and their tool of choice for collaborating nowadays is Git. So this is where to integrate automated detection if we want to improve application security.
This article will show you why pre-commit hooks are one of the best tools for shifting your security left and why you need to consider them with precaution. If you need a solution that can be truly enforced at scale as your team grows, we will give you the best option according to our experience.
Shifting Left Means Making Security Proactive
If we take a look at the way developers work, it’s clear that pre-commit hooks are the best tool to shift left:
Operating a security scan pre-commit means that if the developer’s work contains a vulnerability, it cannot reach the version control system (in most cases, Git). It is up to the developer to modify their work to make it pass, much like any test suite would fail if a regression were introduced.
Assuming that the scanning tool provides enough context, the developer is generally able to locate and remediate the issue swiftly. Commits represent incremental changes in a codebase, so the developer is kept very close to their personal contribution and doesn’t need to halt and switch context to look for more information. They are able to respond to vulnerability alerts as coding happens proactively. That’s what we call a developer-centric approach.
From a global perspective, it is in everyone’s best interest to prevent breaches before they impact the company’s security. Regarding vulnerability exposure and remediation cost, it is always desirable to move as quickly as possible to address newly discovered vulnerabilities and fix them. If correctly implemented with the right choice of tools, systematic scanning can deliver cleaner code faster.
This is even more true for secrets detection, which is very sensitive to sprawling; as soon as a secret enters a version control system, it should be considered compromised.
A Special Case: Secrets Detection
In an ideal world, developers would never touch secrets, and security engineers would create a safe and user-friendly mechanism for seamlessly connecting applications and services, even at the development stage. This, of course, is not the state of the world.
Developers have highly privileged access to secrets because they need them to be able to build and deliver working software. When a secrets management solution is approved and implemented, it makes life harder for them, so what do they do? They choose the path of least resistance, get a copy of those credentials, maybe through slack, or maybe through emails and, sometimes, hardcode them directly in their code.
At this point, you want something to prevent it from going further. Secrets are unlike other code vulnerabilities in that they do not need a running application to be exploitable. Worse, they can live undetected in version control history for months or even years before being leveraged by an attacker.
GitGuardian considered this when developing its secrets detection solution for developers. A CLI leveraging its advanced detection capabilities through the GitGuardian API serves this purpose: GitGuardian Shield. This free tool can be integrated easily as a pre-commit hook to protect your systems from leaking secrets, with a very low rate of false positives and various whitelisting mechanisms.
New detectors are added every month (already more than 300 credentials supported) to ensure that your code is protected from leaking keys of the wide range of tools used in modern stacks.
Read this tutorial if you want to learn how to set up a pre-commit hook scanning for potential secrets leaking.
To enforce a secrets’ policy, it is clear that a blocking check is needed. While pre-commit hooks are very user-friendly, there is a catch: pre-commit means locally installed, and the rollout will not be scalable at the organization level.
Fortunately, there is a better alternative.
A Centralized Approach
The only way to implement a coercive solution to reject commits and stop them from entering the VCS if they do not validate every check is to implement server-side pre-receive hooks.
By using pre-receive hooks, you are making sure to dispose of a scalable solution that won’t break the developers’ workflow. It is an additional, very powerful, layer of defense for shifting your security left.
When deploying this mechanism at GitGuardian, our priority was to ensure that the developers would never be blocked in their workflow by a failing scan. That’s why we created a "breakglass" option to force a failing "git push" command, effectively bypassing the security layer. In this case, the incident is still reported to the dashboard, and so security engineers are notified and can engage in a discussion. In our opinion, this is the best solution to prevent most of the secrets from leaking while still providing a solution path for the most complex situations.
When used at scale, pre-receive hooks have proven to be one of the most effective ways to immediately ‘stop the bleeding’ of secrets being repeatedly leaked. In turn, it clears up the way for security teams to make the best use of their skillset on other more critical incident responses.
Conclusion
Pre-commit hooks are the best tool for shifting security left because they act as guardrails on which the developer has complete control. Therefore their usefulness is tightly linked to the expected level of discipline, which is not something you want to rely on when talking about something as sensitive as secrets. Our experience at GitGuardian has shown that to shift left at scale efficiently, you need to enforce a centralized layer of security while leaving some flexibility margin. The benefits show up quickly: less burden on security shoulders and improved time to remediate, while developers can learn from their errors and improve their coding hygiene. Above all, the two are now better positioned to cooperate on security matters efficiently.
