For the last few years the general consensus of the security industry has been that we should all “shift left”, implying developers should take care of as much security as they can before they commit code. This in fact is not new.
For the last two decades it has been largely driven by security tools vendors who had a vested interest in selling ‘seat based pricing’ security tools to CSOs. The more developers that used their tools then the more cash they collected and ‘convenient marketing’ was presented as fact. We have all seen stats such as “it's 100 times cheaper to fix a bug upstream”, very convenient but likely bullshit.
"The Systems Sciences Institute at IBM has reported that the cost to fix an error found after product release was four to five times as much as one uncovered during design, and up to 100 times more than one identified in the maintenance phase”
The IBM System Sciences Institute stopped doing business in 1970, long before Agile was even a thing and the study was performed on just a handful of waterfall developers. I suspect Wade Baker would literally tear it apart but it's so flawed it's not even worthy of his attention.
I think modern appsec practices should be a combination of two things, the first is to encourage developers to do the right thing before they commit code by providing options and the second is to enforce good security practices at the CI.
We should probably call the movement nudge left versus shifting left. Something like SAST makes sense to just move a little bit left. It's before deployment but after development after all.
There is a technology that can be used to encourage developers to do the right thing, Git pre-commit hooks, scripts that run on code with the goal of identifying issues before code is checked in. It’s like saying “these are the things we would like you to do before you commit your code”.
This post offers some tips and tricks for deploying pre-commit hooks if you are an appsec team. Information about pre-commit itself is here and a list of hooks available. You can also search public Github repos with this Github search query. You will find that many commercial tools vendors supply their own which are not publicly available and so it's worth asking if you want to make their tools available via pre-commit.
- Automate your deployment
- Pre-commit should not negate checks in CI
- GitHub Actions vs pre-commit
- Pre-commit is very useful for SBOMs and SCA
Automate your deployment
Once a pre-commit configuration file has been created in the repository and the special incantation of the pre-commit install has been done on the command-line, the pre-commit hook will be configured on the repository. So far so good but if you take that approach then all developers will need to run pre-commit install on their machines and that would be like chasing people to update Chrome. Instead, added in version 1.18.0 you can now use pre-commit init-templatedir can be used so that any newly cloned repository will automatically have the hooks set up without the need to run pre-commit install. Documentation can be found here.
Pre-commit should not negate checks in CI
The `--no-verify` flag on the commit will bypass the pre-commit checks. Pre-commit hooks were never meant to be a gate that halted development and so you should not rely on them as a security checkpoint.
GitHub Actions vs pre-commit
An alternative to pre-commits is to use GitHub actions. There is a diverse marketplace for actions and the majority of vendors have some type of integration and/or guide to adding their tool to GitHub actions. There has been a lot of attention around the security of actions lately. Github has excellent documentation, the TLDR of which is that the security implications mean defining actions securely across the organisation are tough. To reduce the friction you can share workflows and create starter templates.
I am not aware of a way to block a commit using Github Actions. If you know how to do it then please share? It must be possible. You can block a merge or create an issue but if you do this you may create busy work for developers that could have been avoided. If a secret gets committed you will need to rotate your secret and probably go back and remove it from the commit history just to be sure. Double bagging again.
Pre-commit is very useful for SBOMs and SCA
With the frenzy about SBOMs and supply chain attacks it's very useful to deploy SCA software as a pre-commit hook, especially for commits that are new features. If there is something that needs to be upgraded or indeed should use a different dependency altogether, it is usually easier done by the original committer.