It’s time for security teams to get serious about monitoring risks and vulnerabilities within development platforms. Whether an organization runs a number of open source tools or services, or if it hosts its entire platform’s codebase on development platforms, these platforms are the go-to standard for software development.
Organizations are drawn to platforms like GitHub and Bitbucket because they enable cross-collaboration across development teams, however they also inadvertently introduce new security risks to organizations.
It is the unfortunate reality that organizations increase their risk of exposing sensitive company information, intellectual property or vulnerabilities with every tool or code integration they make. Case-in-point, Amazon keys are constantly mined by cyber-criminals to launch crypto mining clusters and build logs can accidentally expose API keys. Development platform security is not just a secure software development lifecycle (SDLC) problem, but it also is a security team problem.
The problem with existing open source tools
As organizations look to tackle these problems, a logical first step many take is to look for open source solutions such a common tool set in the security team’s arsenal that deals with secrets exposure. These tools automatically look at the repositories and git projects that have emerged, however they are unfortunately limited in their capabilities.
truffleHog and git-hound are two well-known examples that take advantage of GitHub or Bitbucket APIs to search code. They cover a number of use cases that an attentive security engineer cares about, including:
- Secrets inside committed code, such as private keys, API keys or internal domains
- Regular expression plugins to find specific secrets, names or PII inside code
- Detection of things like internal project names that can result in an incident which exposes too much internal company information
- CI/CD integration that fails a build if something is found or a rule is fired
The problem is that a lot of these tools only cover what an organization owns on the development platforms, i.e. the accounts or repositories. As a result, organizations are still struggling to monitor these platforms for other common security problems such as PII leaks, secret leaks, vulnerability identification and intellectual property leaks. Today, there are a number of OSINT frameworks and reference materials, but few, if any, focus specifically on searching development platforms for these concerns. This is important because it outlines a clear gap in coverage within the security community; code sharing websites are a digital risk problem.
Identifying gaps in coverage
Today, building and implementing a threat model that matches an organization’s specific gaps and vulnerabilities is challenging. No two threat models are the same. However, if an organization approaches the process by thinking like an attacker, they can build a comprehensive model. For example, if you were attacking your own organization, how could development platforms get you inside the network, or provide you enough information to craft a targeted attack? Although you’ve identified GitHub, for example, as an asset, what is it about GitHub that makes you vulnerable? What can help you protect assets on GitHub, and where are your gaps in coverage?
Let’s explore three assets that serve as good reference point for organizations as they work to identify gaps in coverage.
Asset: Intellectual Property - Repositories of Application Code
Here, the risk involves an engineer who has access to the code and makes the repository public or clones the repository and publishes it. Once exposed, this can be used by cyber-criminals to attack an application. Currently, there is no open source tool that addresses this problem. To combat this, organizations should look for solutions that enable them to search repositories for company names or project names to detect.
Asset: API Keys, Private Keys, Private or Secret application information
In this situation, we are dealing with secrets exposure which are leaked or accidentally added to development platforms as backup. When this happens, attackers in turn use these secrets to access applications or machines, and then pivot throughout an organization’s infrastructure. While organizations can leverage open source tools to monitor repositories that they own, they need to start leveraging other repositories that are public and they do not own.
Asset: Organizational infrastructure such as servers, endpoints and networking equipment
When a CVE is published, and an organization needs to prioritize patching, a PoC is published through educational purposes, leaks, malice or researcher frustration. Attackers in the wild can use the PoC to gain access to an organization’s infrastructure. To address this risk, organizations should leverage tools that have the ability to scan a myriad of data sources – especially development platforms – to monitor for chatter.
Although securing development platforms have traditionally been an AppSec responsibility, they should also be a concern for security teams and incident response capabilities. The open nature of the web allows people to publish whatever they have on their computer onto these platforms. As a result, organizations need to ensure they can monitor these platforms according to their threat mode to build an in-depth defense strategy.