GitGuardian Investigation Finds Secrets in Docker Images
A report published by GitGuardian, a provider of security tools for scanning Git repositories, finds that out of 2,000 images pushed to Docker Hub, a total of 7% contained at least one secret, with one secret being discovered for every 500 files scanned.
Henri Hubert, lead developer for the secrets team at GitGuardian, says that while that’s about half of what is usually found in source code stored in a public repository, the secrets found in Docker images are likely to be more sensitive because they are more often associated with infrastructure services.
GitGuardian decided to investigate secrets management following a security incident at Codecov, a provider of tools for testing code. A Docker image contained git credentials that allowed an attacker to gain access to Codecov’s private git repositories in a way that compromised the company’s software supply chain.
The GitGuardian report notes there are three primary ways secrets find their way into container images. First, Docker images often contain source code that, for one reason or another, might not have been scanned before being deployed in a production environment.
The second source of secrets is the configuration of the Dockerfile. Secrets can be added either directly in the Dockerfile or by adding a file containing secrets. A Dockerfile is often employed during the build process or to manage operations to access a package manager or the keys for application programming interfaces (APIs).
The third source is a Docker image based on stacked layers that are prone to leaks. Leaks occur because one layer can hide the secrets from the previous layer in a way that makes them less visible in the final state of the image. Few organizations review multiple layers of a Docker image.
Overall, the report suggests developers who employ containers are more security conscious than developers that still rely on other types of software artifacts to build applications. However, as the number of container images stored on public repositories steadily increases, so, too, does the potential number of vulnerabilities, notes Hubert.
In general, Hubert says there’s a clear need for additional secrets management education among developers. Secrets are included as text in files for the sake of convenience during the application development process. The trouble is, from time to time a developer forgets to remove them before an application is deployed in a production environment. Cybercriminals, of course, now routinely scan applications looking for those secrets.
In an ideal world, scanning for secrets in applications would become part of any set of DevSecOps best practices that an application development team might adopt. The challenge is that DevSecOps, as a methodology for building secure applications, is still in its infancy. In the meantime, it’s either up to a developer to scan for secrets or it’s up to cybersecurity analysts that are trying to identify potential vulnerabilities in applications.
One way or another, the need to better protect application secrets will be part of a larger focus on securing software supply chains that has emerged in the wake of a series of high-profile breaches that has many organizations reevaluating how they build and deploy modern software.
