All developers want to create secure and dependable software. They should feel proud to release their code with the full confidence they did not introduce any weaknesses or anti-patterns into their applications. Unfortunately, developers are not writing their own code for the most part these days. 96% of all software contains some open-source components, and open-source components make up between 70% and 90% of any given piece of modern software. Unfortunately for our security-minded developers, most modern vulnerabilities come from those software components.
As new vulnerabilities emerge and are publicly reported as Common Vulnerabilities and Exposures (CVEs), security teams have little choice but to ask the developer to refactor the code to include different versions of the dependencies. Nobody is happy in this situation, as it blocks new features and can be maddening to roll back component versions and hope that nothing breaks. Developers need a way to quickly determine if a component they want to use has a known vulnerability before they make a pull request.
Fortunately for developers and security teams, it is now easier and faster than ever to scan for CVEs locally, automatically, and before any commits are made.
Understanding what is in your code before it is committed
Source Code Analysis (SCA) mostly comes up in discussions of Software Bill Of Materials (SBOMs) and in conversations about compliance, and normally much later than the actual writing of code. With GitGuardian Software Composition Analysis (SCA), developers scan for issues directly from their terminal at any point in their work, thanks to ggshield, the GitGuardian CLI. With one quick command, coders can test if a particular version of a dependency introduces a known vulnerability. GitGuardian will even show if a fix is available.
In this example, we have added a requirement for the `go-getter` library and specified version 1.7.1. There could be many reasons why a developer would have used that version, such as copying from an older tutorial or a post online that explains the functionality of that library. A simple SCA scan shows that not only would this version introduce a known vulnerability, but there is also a fix made available in version 1.7.4.
ggshield, the GitGuardian CLI, performing an SCA scan to find a vulnerability in the code.
Automatically scan just the new changes
While scanning for CVEs in our code locally is very powerful, it is still a manual process. Humans are great at being creative, but we are not great when it comes to consistently doing every step in a process repeatedly, especially tedious ones. It is a good thing that every developer has a whole automation platform built directly into their favorite source control management tool, Git Hooks.
GitGuardian SCA scanning can be triggered automatically at either the pre-commit or pre-push phase of Git’s workflow. The ideal time to catch any issue in code is before it ever makes it into your project’s history. If it is never committed, then a security scan is not likely to later detect an issue in the CI/CD pipeline or production. While new CVEs emerge daily we should do all we can to make sure we are not adding known ones to our code.
A pre-commit git hook that automatically runs the command ggshield sca scan pre-commit
Scanning just the correct scope of work
You will see in the example git hook we are using the command `ggshield sca scan pre-commit` instead of `ggshield sca scan all` as we used in the manual example. This variant on the SCA scan limits the scan to only the current working directory, meaning only the changes that have been made since the last commit. This way, if there are existing vulnerabilities in the codebase that can not yet be addressed, they will not block your changes. Only new issues with dependencies will be identified and the commit will be halted then.
The pre-commit git hook finds a critical vulnerability when a commit is attempted, stopping the code from being added to the project.
In this example, not only does the commit not happen, but the message from GitGuardian tells us there is a fix available in a later version. All our developer needs to do is change one character in the identified file, save it and then they can successfully make the new commit.
A successful commit once the code is updated.
Shifting left means solving issues earlier
While security requires the whole organization, arming your development team with the right tools to find and squash security issues early can eliminate many headaches later in the software delivery process. The closer to production you find an issue, the more expensive it becomes to fix. This is why we have made GitGuardian SCA available as a pre-commit Git Hook, so every developer can prevent themselves from adding a known vulnerability into the pipeline and eventually production.
GitGuardian SCA is available for a 2-week free trial after a quick conversation with our team. SCA is just one of the concerns that GitGuardian’s product suite addresses. We also integrate a range of security tools, including Secrets Detection, Public Monitoring, Infra as Code Security, and Honeytoken.
Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Twitter and LinkedIn to read more exclusive content we post.
