“The best way to foster a DevSecOps culture is to provide developers with the appropriate toolset, like security command-line applications (CLI) and ad-hoc access to security incidents,” says Eric Fourrier, Co-Founder, GitGuardian, in an exclusive interview with ITSecurityWire.
ITSW Bureau: What are the challenges that organizations face in keeping secrets out of the code, especially on open-source platforms?
Eric Fourrier: Modern application development practices are ever more reliant on new development and deployment tooling and services. Cloud computing, microservice architectures, Continuous Integration/Continuous Deployment (CI/CD) pipelines, SaaS and now Infrastructure-as-Code (IaC) are transforming the development landscape, and one of their common features is the use of “secrets” to self-authenticate in a secure way. In parallel, Source Code Management (SCM) services such as GitHub, GitLab and Bitbucket have become a staple of software development. Software craftsmen use them intensively to collaborate, share, learn, and accelerate code development.
The conjunction of these two trends has led to a situation where the problem of “secrets sprawl” is bound to accelerate. Organizations are watching the number of credentials in use across multiple teams (development squad, SRE, DevOps, security etc.) explode. It is next to impossible to keep track of all these secrets. The problem is that when leaked, secrets are a very low entry barrier for an attacker to gain a foothold into internal systems. From there, lateral movement tactics can take place.
Unsurprisingly, we are witnessing more and more attacks where hackers look for secrets forgotten in source code. This touches on another pain point: there is a huge discrepancy between developer and security teams’ sizes. In 2021, a typical company with 400 developers discovered 1,050 unique secrets left behind in developers’ code, with 13 occurrences per secret on average. With only 1 AppSec engineer for 100 developers, it is easy to understand why there are so many vulnerabilities left in the source code.
Finally, you are right to underline that open source code should be kept under close surveillance too: in 2021, we detected more than 6 million secrets on GitHub, doubling the number from the previous year. That’s three out of every 1,000 commits that expose a credential on average!
We regularly find valid corporate secrets publicly exposed, and this can be explained by the grey area existing between private/public and corporate/personal repositories on cloud-based SCM. Unlike most other enterprise-use applications, where access control is governed by corporate policies, access is too often provided through personal accounts. You also have a lot of developers who contribute to open-source from their work machine. The result is that it’s all too easy for someone to unintentionally push sensitive code into a public repository, inadvertently creating a silent vulnerability for the enterprise. Monitoring all their source code attack surface is yet another challenge faced by organizations.
ITSW Bureau: What steps can they take to reduce the exposure risk of their sensitive data?
Eric Fourrier: There are two key success factors: first, to tackle the root cause of sensitive data exposure, security needs to be baked into the development lifecycle. Second, security can never be a one-step process: multiple layers of defense are required, and mitigating leaks is no different.
In particular, it is recommended to automate as much as possible security testing with continuous integration pipelines.
Developers should also play a big role in your defense strategy: they are the ones who can solve most of the incidents in context. The best way to foster a DevSecOps culture is to provide developers with the appropriate toolset, like security command-line applications (CLI) and ad-hoc access to security incidents.
Also Read: Edge Computing: Four Cybersecurity Challenges in 2022
ITSW Bureau: How can organizations monitor their attack surface of public GitHub?
Eric Fourrier: As mentioned earlier, monitoring their attack surface is particularly challenging for an organization because even if it doesn’t have an official presence on the platform (such as a GitHub Org), its developers do, in fact, contribute to open-source projects or use personal repositories to share code.
At GitGuardian, we use a unique approach to identity stitching on GitHub, which allows us to automatically establish an organization’s perimeter, including developers’ or subcontractors’ personal public repositories. This could be done manually but would require a lot of initial investigation and maintenance work since that perimeter is bound to evolve in time.
From there, you can monitor your developers’ repositories as well as your organization’s open-source repositories on GitHub.com.
ITSW Bureau: Partnering with MSPs often introduces potential third-party attack surfaces along with unanticipated risks to the infrastructure? How do you suggest organizations deal with these?
Eric Fourrier: MSPs are usually responsible for ensuring that IT security is correctly implemented, therefore it is normal to think that they should display a high level of assurance in this domain. But the reality on the ground is quite different: because they supervise more developers than other types of businesses, are confronted with higher turnover, and lack centralized controls, MSPs are more at risk than other software organizations. They represent an attractive target for criminals.
The core problem is that the development lifecycle has evolved into a very complex supply chain involving a lot of different third parties. Security needs to be enforced on a much larger attack surface than it used to be.
Correctly assessing and preventing the risks introduced by the software supply chain is one of the top security concerns right now: as an example, assigned by Executive Order 14028 on improving the nation’s cybersecurity, NIST is improving its guidance on practices for software supply chain security.
It is an ongoing and complex topic, and security teams working on it need to take into account many factors. Here are some general suggestions to invest in, keeping in mind that each situation can be very different:
- Review all the software dependencies you rely on.
- Design an automated trust (signing) mechanism for your own in-house artifacts.
- Implement automated vulnerability scanning, including secret scanning.
- Advance towards Zero-Trust by continuously tightening access control mechanisms to ensure only what is needed can be accessed.
Eric Fourrier, co-founder of GitGuardian, is an engineer who graduated from Ecole Centrale and has also a degree in machine learning from Ecole Normale Supérieure in Paris. He first worked as a data scientist in the United States in the financial sector and then began his entrepreneurial journey by founding first Quantiops, a consulting firm specializing in big data analysis, and then GitGuardian in 2017. GitGuardian, a cybersecurity startup co-founded with Jérémy Thomas, has been pursuing a strong growth trajectory since 2017, supported by investors such as Balderton Capital, BPI France or even Scott Chacon, co-founder of GitHub and Solomon Hykes, founder of Docker.
