Table of content
Git hooks are scripts that are triggered by certain actions in the software development process, like committing or pushing. By automatically pointing out issues in code, they allow reviewers not to waste time on mistakes that can be easily diagnosed by a machine.
There are client-side hooks, that execute locally on the developers’ workstation, and server-side hooks, that execute on the centralized version control system.
Examples of client-side hooks:
Examples of server-side hooks:
To learn more: see our blog post about Git Hooks in the SDLC
"The pre-commit hook is run first when committing, before you even type in a commit message. It’s used to inspect the snapshot that’s about to be committed, to see if you’ve forgotten something, to make sure tests run, or to examine whatever you need to inspect in the code.
Exiting non-zero from this hook aborts the commit, although you can bypass it with git commit --no-verify. You can do things like check for code style (run lint or something equivalent), check for trailing whitespace, or check for appropriate documentation on new methods."
If you want to learn more about setting up a pre-commit git hook to prevent credentials from reaching your code base, read our dedicated article.
A pre-receive hook is a script that runs on the server. It performs checks on the content of the push; if it exits non-zero, the push is rejected. You can use this hook to do things like prevent a PR author from merging their own changes, or require commit messages to follow some specific guidelines.
Be careful when using pre-receive hooks as they are blocking: if the checks don’t pass, the server is not updated.
"The post-receive hook runs after the entire process of pushing code to the server is completed and can be used to update other services or notify users. Examples include emailing a list, notifying a continuous integration server, or updating a ticket-tracking system – you can even parse the commit messages to see if any tickets need to be opened, modified, or closed. This script can’t stop the push process, but the client doesn’t disconnect until it has completed, so be careful if you try to do anything that may take a long time."
Unlike the pre-receive hook, post-receive is non-blocking.
The earlier a security vulnerability is uncovered, the less costly it is to correct. Hardcoded secrets are no exceptions. If the secret is uncovered after the secret reaches centralized version control server-side, it must be considered compromised, which requires rotating (revoking and redistributing) the exposed credential. This operation can be complex and typically involves multiple stakeholders.
Client-side secrets detection early in the software development process is a nice-to-have as it will prevent secrets entering the VCS earlier.
Server-side secrets detection is a must have:
From our experience, when trying to impose rules that are too constraining, people will bend them, often in an effort to collaborate better and do their job. Security must not be a blocker. It should allow flexibility and enable information to flow, yet enable visibility and control.
On one hand, security measures will be bypassed, sometimes for the worst. But on the other hand, it is also good sometimes that the developer can take the responsibility to bypass them.
Because even the best algorithms can fail and need human judgement. Secrets detection is probabilistic: algorithms achieve a tradeoff between not raising false alerts and not missing keys.