Dealing with Leaks of Your Company Secrets

“Secrets leaked publicly are unlike zero-day vulnerabilities or more sophisticated vulnerabilities. They are extremely easy to exploit without specific knowledge. A secret leaked publicly is as easy to exploit for a developer as a lost key giving access to your home with its address written on it,” says Jeremy Thomas, CEO, GitGuardian, in an exclusive interview with ITSecurityWire.

ITSW Bureau: In your opinion, how safe or unsafe are company secrets (API keys, database credentials, certificates) in open sources?

Jérémy Thomas: Open source is an integral part of today’s application development. The amount of open-source dependencies within applications has nearly doubled in five years. It is not just organizations that publish open-source code, it is also individual developers.

As software has moved to a more distributed architecture of individual services, SaaS platforms, APIs, managed databases and cloud infrastructure, it has also increased the number of secrets developers need to handle. This, combined with the increase in open-source contributions has driven a rise in the number of corporate secrets being leaked within open-source repositories.

Secrets leaked publicly are unlike zero-day vulnerabilities or more sophisticated vulnerabilities. They are extremely easy to exploit without specific knowledge. A secret leaked publicly is as easy to exploit for a developer as a lost key giving access to your home with its address written on it.

ITSW Bureau: What strategies and software solutions would you recommend to secure corporate secrets? Are they cost-effective?

Jérémy Thomas: Companies often deploy secrets management solutions like vaults. They are often deployed on well-chosen restricted perimeters, where they perform the best. Even more importantly, these systems are not coercive: there is no guarantee that developers don’t fetch secrets from the vaults before hardcoding them in source code. Companies deploying secrets management solutions can’t ignore that they are still facing the following risks: incomplete visibility over all secrets locations, hardcoded credentials in source code, developers sharing or saving secrets insecurely, secrets being exposed in debug or bash history files, secrets used in DevOps configuration files that end up in git. This is why a detection layer needs to be added in addition to a secrets management solution. The detection solution will be the assurance that all secrets remain protected and are not exposed in any way. In terms of cybersecurity, cost-effectiveness is measured in terms of risk avoidance. A lot is that after hackers gain initial access to an internal system. They try to move laterally to other systems using a bunch of different techniques. Most of the time, all they have to do is leverage credentials they just found on their way.

Also Read: IT Security Threats are taking a higher Toll than Ever

ITSW Bureau: What future technology-based detection solutions do you foresee?

Jérémy Thomas: I talked about secrets but leaks can also include IP. Companies invest a lot of money developing code and they don’t want this code to become public in an uncontrolled fashion. For IP leaks, we are talking about two different types of risk. The first one is that leaked IP can compromise security. Development patterns are exposed, and it is easier for hackers to find vulnerabilities in an application when they can read source code (as opposed to considering the application as a black box). The second one is a competitive loss. R&D investment in innovation could be spoiled if competition gets hold of the code.

Detecting IP is not a simple task. Of course, exact match of a piece of code is straightforward, but real-world IP leaks can be more difficult than that to detect. What detection needs to be able to do is detect code DNA. This would allow detecting leaks of original and slightly modified elements of code within larger pieces.

Secrets sprawl show that a majority of data leaks is through develop sources. Does this make open-source risky for enterprise use?

Jérémy Thomas: It is important to make a distinction between open sourcing and using open source. Each of them has its own benefits and drawbacks.

Let’s first look at open sourcing. Open-sourcing code brings a lot of benefits such as more visibility, contributions from developers around the world, etc. Now on the drawbacks side. Companies with large numbers of developers are always exposed to their internal code ending up in the open source. Even if companies don’t do open source themselves, their developers often do, and it is impossible to prevent developers from doing so. However, companies must have controls in place to make sure their developers don’t leak corporate data publicly, especially in their personal public repositories.

Let’s now look at using open source. Leveraging open source components allows code reuse, avoiding reinventing the wheel and faster time-to-market for software. Using open source components exposes companies to importing vulnerable components in their codebase. They can limit this drawback by implementing software composition analysis that looks for CVEs in open source dependencies.

Also Read: IT Security and Privacy Compliance Policies Are Costing Enterprises Big

ITSW Bureau: How can secret sprawls be controlled?

Jérémy Thomas: Companies need to invest in two dimensions: developers’ education and tooling.

Developers training programs should be put in place and security champions empowered, although these do not eradicate the risk of leaked credentials. Code reviews are also not sufficient and usually fail at detecting secrets. They are also very time-consuming, and time is something development teams care a lot about.

This is why companies need to invest in detection tooling. Automated secrets detection can mitigate the risk at scale.

Depending on the company’s need and potential exposure, two types of secrets detection can be put in place: public code repositories monitoring and internal repositories monitoring.

Some companies have built internal tools, often derived from open source but they are hard to build, maintain, and update. They often lack precision and trigger many false positive alerts, leading to alert fatigue. Enterprise-grade solutions, on the other hand, are expected to provide precision, coverage and ease of use. They are also capable of integrating with the development workflow and allow true collaboration between developers, security and operation teams.

For more such updates follow us on Google News ITsecuritywire News.