Mackenzie Jackson, GitGuardian: “code security needs to be a layered approach”
Security should be something that companies implement into the software development lifecycle as early as possible. It should be a consideration at every step of development, from design and through to deployment and every incremental change made thereafter.
Nowadays, the need for online security is a never ending process. Companies look for protection in hiding their online traffic routes and stopping trackers, yet it is only one layer of security and sensitive data can often still be easily exposed. But what exact additional security measures are needed? And what are the lurking threats when extra protection is not implemented?
To answer this, we have talked to Mackenzie Jackson – Developer advocate at GitGuardian who works closely with research teams to show how malicious actors discover and exploit vulnerabilities.
Tell us how it all began. How did the idea of GitGuardian originate?
GitGuardian was founded by two engineers, Jeremy Thomas and Eric Fourier, who were both studying at the engineering school École Centrale Paris. They met on the mats of jujitsu judo. Originally it started as a fun experiment after investigating the GitHub API. The two wanted to see if they could find sensitive information that had been leaked into public GitHub repositories. Expecting to find a few examples, they were shocked by the scale at which sensitive information was leaked. Jeremy and Eric faced a dilemma at this point – use this information for bug bounties from large companies or build a product that could help solve this problem. Luckily, they took the latter option and the rest is history.
Can you tell us a little bit about the main differences between your internal and public monitoring products?
The two products are complementary (as the names suggest) – one monitors code that is publicly available on GitHub.com, while the other monitors source code that is private (or internal).
The internal monitoring product allows organizations to secure their source code from secrets in three parts:
- Granting full visibility into a project's entire history and finding any threats inside code repositories
- Scanning all new commits for leaked secrets in real-time at scale
- Giving developers tools to be able to prevent leaking secrets themselves.
What’s interesting about the public monitoring product, is that it identifies secrets that have been leaked into public GitHub repositories not just belonging to the organization but also belonging to the personal repositories of their employees and partners. This is crucial because it operates in a security blind spot that is outside of the organization's control.
What tools do you use to secure your source code?
Code security needs to be a layered approach. At GitGuardian, we use many tools ourselves to protect our code in what we call a ‘best of breed’ strategy. Often, organizations choose a single security vendor that protects many aspects of code fairly, but we choose to work with multiple vendors that are the best at their respective security niches. This gives us the best possible protection and is the approach we recommend to all companies looking for the best security for their code, application, and infrastructure.
In your opinion, has the pandemic altered the cybersecurity industry in any way?
The cyber security industry moves at such a rapid pace that it can be difficult to know what changes are a result of the pandemic rather than just another new development. Certainly, the decentralization of data as a result of remote working and an increase in public anxiety that adversaries can take advantage of has created additional challenges for organizations.
We have also seen big changes in the type of organizations that are being affected by security attacks. For example, we saw a huge increase in Software Supply Chain Attacks over the past two years in pace with the pandemic. This has resulted in both a change in the type of companies attackers are targeting and has rendered many organizations powerless to prevent becoming a victim of attacks.
In recent years, DevSecOps practices started to gain traction. Can you briefly describe this approach?
New practices like DevSecOps and Shift Left describe a fundamental shift in cyber security. I would describe it as a security revolution toward a shared security model. Previously, cyber security was something that was seen as separate from software development: it sat at the end of the software development lifecycle after a feature or application had been deployed. This meant that it took organizations a look time to go from threat discovery to security fixes if detected at all. DevSecOps is the concept of taking Development and Operations teams and inserting security into the workflow. Operations, security, and developers teams work together from the very start of the project, making threat discovery and security fixes part of the development process, reducing time, and increasing security.
What would you consider the biggest security risks nowadays that companies should be on the lookout for?
Organizations can never fully eradicate the risk of being exploited by adversaries, so it is hard to single out one risk as to the biggest. But one thing that organizations definitely must look out for is to ensure that codes do not provide threat actors with the opportunity to move deeper into your organization. This of course includes ensuring your code repositories are free from secrets and PII; making sure you don’t have the misconfigured infrastructure and using short-lived credentials where possible. This approach means that even if a breach does happen, it can be contained and block an adversary from moving deeper into more critical infrastructure.
In your opinion, why are git repositories attractive targets for threat actors?
Git repositories have become known to contain a wealth of sensitive information. This is true for a combination of factors. Git repositories store a complete record of all activity, which means a mistake a developer made a month or even a year ago is still present in history, even if it was since removed from the latest version. This is uniquely different from other vulnerabilities.
Git is also a centralized point of truth for developers who now have to handle increasing amounts of sensitive information. This means that sensitive information often gets committed into repositories. Even private git repositories do not have adequate protection for sensitive information, making it a known weak link for attackers to gain initial access into an organization and move laterally into different services and systems.
What are the best practices companies should follow when developing, and, when launching software?
Security should be something that companies add as early as possible into the software development lifecycle. It should be a consideration at every step of development, from design and through to deployment and every incremental change made thereafter. To be able to do this effectively, it is always the best practice to make developers part of the security solution. Part of this is through educating them about security, but also giving them the tools they need to be able to take some ownership over certain elements of security.
What does the future hold for GitGuardian?
It is a very exciting time at GitGuardian, our mission is ambitious but is built on a very simple philosophy at its core. Developing and launching secure applications must be a shared responsibility between Dev, Sec, and Cloud Ops. We have just raised a successful Series B, which will enable us to take a large step towards our goal of being the leader in the shared security model. This year we will not only improve our current product offerings for detecting secrets but also expand our code security product suite. This will include a tool to detect IP leaks, which is currently in beta and also expand into infrastructure as code (IaC) security.