Once again we are seeing how vulnerable and easily development environments can be exploited with the recent news of a massive trove of leaked code from 50+ enterprises across multiple industries, including tech, finance, retail, manufacturing, food and eCommerce. Tillie Kottman, a Swiss software developer, collected leaked code into a public GitLab repository that is accessible by anyone. So how did they get the source code of these major players? Most of it was found by scanning misconfigured DevOps applications and third-party sources.
Aside from the obvious intrusion a leak like this invokes, what makes it particularly alarming is the number of hard coded credentials that were exposed Hard coded credentials are passwords, access keys and other types of secrets stored in the source code, sometimes even as plain text. Each of these credentials could be used by an attacker to gain a foothold on that company’s cloud, development environment or IT infrastructure and, potentially, lead to further data leaks or other cybersecurity nightmares.
Fortunately, there are some valuable lessons to be learned here:
- Hard Coded Credentials Are A Serious Risk
While it’s unclear if hard coded credentials played a role in making the leak possible, the leak certainly made those credentials available to anyone who might visit GitLab. This would make it extremely easy for a cyber attacker to steal passwords and other secrets and potentially start using them to gain privileged access to any of these companies’ IT infrastructure. Some of the companies involved in the data leak also hard coded their cloud access keys, which would allow a cyber attacker to takeover a company’s cloud environment or steal sensitive information the company has on the cloud.
- Developers Need to Take Security Seriously
Some of the developers contacted about the code leak weren’t concerned about their code being exposed. This unfortunate example highlights a key issue: some developers are less concerned about security than they should be. But exposed code can quickly lead to big problems – like this data leak – and that’s a risk worth taking seriously.
Consider: even before this trove of source code was found and shared on GitLab, it was unprotected and available to attackers. Not only could those attackers use the code to steal intellectual property and potentially any hardcoded credentials or cloud access keys, they could get way more creative. For example, an attacker that can access the code could also add their own malicious code into automated builds and include it in the organizations code base.
- Protecting Code Repositories Is Really Important
The only information currently known about the origin of the source code is that it was found by scanning third-party sources and misconfigured DevOps applications. –However, is likely that at least some code was taken from a repository. After all, code repositories are established as an essential part of the modern development process. It’s a familiar scenario. The developers who created the leaked source code probably thought they were putting code into a private repository – but that wasn’t the case.
Either that code was inadvertently made public or a misconfiguration or stolen credential was used to expose it – which is an easy mistake, but a dangerous one. It’s essential to not only make sure the repository is correctly configured, but also to protect the credentials used by the developers to access and configure the repository.
- Bring Developers and Security Teams Together to Secure DevOps Environments
It’s not exactly a surprise that poorly protected DevOps tools and applications – and access to those tools – contributed to this leaked code. The trend toward greater independence for developers has introduced risks and cultural changes that create clear security challenges. Specifically, the responsibility for managing risk in development environments is too often shifting from IT and security teams to development and DevOps teams.
In today’s high velocity developer culture, low-security shortcuts often flourish and traditional security processes are not always easy to integrate. To secure developers without slowing them down, the security team must work with their developer and DevOps counterparts to follow cybersecurity best practices. The goal is to find the right balance of securing the development environments while not overburdening developers. With developers and security teams working together, it’s much harder for something like this code leak to happen to you.
Next Steps
If organizations learn nothing else from this leak, they should learn that security can’t – and shouldn’t – be separated from development. The use of security best practices might have prevented these companies from having their credentials exposed in a public repository – and the potential leaks, breaches and takeovers that it could lead to. Adding security into the development process after the fact can be difficult and disruptive. Instead, involve security right from the beginning to keep credentials and repositories secure.
To find out more about how to address these issues, check out the CISO View – Securing Privileged Credentials in DevOps and Cloud Environments for insights from 13 global 2000 CISOs on how they have worked within their organizations to secure their DevOps environments. Or watch a video animation or read a white paper on the vulnerabilities exposed by development environments and why it is so critical for organizations to secure their development environments.
