Among the secrets GitGuardian detects on the public Internet, Artifactory tokens are relatively uncommon. In the State of Secret Sprawl report 2024, our Artifactory token detector was not among the top 10 specific detectors.
However, the GitGuardian Cybersecurity Research team recently noted that most leaked Artifactory tokens are tied to corporate environments. In addition, most Artifactory token leaks are found to be critical. They are tightly related to production environments and, because JFrog Artifactory is a paid service, are unlikely to be used for toy or personal projects.
Over the last three months, our research team responsibly disclosed severe Artifactory token leaks to several companies in diverse industries, including pharmaceutical, energy, defense, and hardware and microelectronics. One of those companies is part of the Big Five tech companies.
In this first post about Artifactory tokens, we detail where and how Artifactory tokens leak.
Build configuration files
By nature, Artifactory tokens are tightly linked to build processes. Artifactory stores software artifacts, such as Python packages or Docker images, so that tokens are used to pull dependencies or store the result of a build process. It is therefore unsurprising that most of the Artifactory token leaks appear in files related to build configuration.
About 60% of the leaks occur in configuration files of various kinds and providers. About half of them are configuration files for Gradle, the popular build automation tool.
In most cases, Gradle configurations leak Artifactory credentials in Maven repository definitions. Maven is the most used build automation tool, mostly used in Java environments. Artifactory supports storing Maven artifacts and can be set as a package source.
repositories {
google()
mavenCentral()
maven {
url "https://somehost.jfrog.io/artifactory/something"
credentials {
username "someuser"
password "AKCpNkw3gRz0+3TYO6o25o/aMa2NAk7B3+4X6086qeKQZNJc7dSfcvzIhTZayUiautYJDy2DJ"
}
}
}Excerpt from a Gragle configuration file. A maven repository host on Artifactory is configured.
Jenkinsfile, the configuration for the well-known software automation Jenkins, is another file that leaks Artifactory tokens while being close to the build configuration. Unlike Maven configurations, the tokens leaked in Jenkinsfiles often relate to uploading artifacts to the repository after a build.
stage('Promote jar and image to release repo'){
sh '''
curl -H \"X-JFrog-Art-Api: AKCpNkw3gRz0+3TYO6o25o/aMa2NAk7B3+4X6086qeKQZNJc7dSfcvzIhTZayUiautYJDy2DJ\" \
-X PUT \
-T target/some-service-1.0-SNAPSHOT.jar \
'http://somehost.jfrog.io/artifactory/some/path/to/some.jar'
docker tag somehost.jfrog.io/docker/some-service:\$BUILD_NUMBER somehost.jfrog.io/docker/some-service:\$BUILD_NUMBER
docker push somehost.jfrog.io/docker/some-service:\$BUILD_NUMBER
'''
}Excerpt from a Jenkins configuration file. A script promotes a Java build artifact.
This difference implies a different level of privileges between tokens. Tokens leaked as part of a build configuration similar to Gradle can be configured with only read permissions. On the contrary, Jenkinsfile-contained secrets generally require write permissions to Artifactory.
While not a general rule, Artifactory tokens in Jenkinsfile have more chances to be critical.
The Source Code Blind Spot
Another significant proportion of the leaks occur in source files. This is more surprising as the use cases for programmatical accesses to Artifactory repositories are less obvious.
The most common languages for Artifactory tokens manipulation are, in order:
- Shell script
- Python
- Java
- Javascript
Other languages are also observed but with a much smaller volume.
Apart from the classical build, installation, and update scripts, shell scripts containing Artifactory tokens are often found in dotfiles or similar repositories. Their owners store their Linux home environment configuration in them to fasten the configuration of new hosts.
While those repositories are usually found under personal GitHub organizations, they usually contain corporate credentials.
export HOMEBREW_ARTIFACTORY_API_TOKEN=AKCpNkw3gRz0+3TYO6o25o/aMa2NAk7B3+4X6086qeKQZNJc7dSfcvzIhTZayUiautYJDy2DJ
export HOMEBREW_ARTIFACTORY_API_USER=someuser
export VAULT_TOKEN=hvs.R7Yrx7F4dBLQd18gfYzNuqAjrq9HBRanix_yeAcWNlW2kpOKKFnPj3tSOWWNT1waOU3_GOXYUAPuciaUgMDRhZmVuh7someuser/dotfiles:config/someconfig/some_config_env.sh
The common factor between most leaks in source code is the devops context. Source files containing Artifactory tokens are often found in repositories relating to deployment, CI/CD, or infrastructure as code. A typical example is scripts to download helm charts.
#!/usr/bin/python
from optparse import OptionParser
DEFAULT_APP_HELM_REPO="https://repository.company.io/artifactory/proj-helm-dev/proj-baseline"
DEFAULT_USER="someuser"
DEFAULT_TOKEN="AKCpNkw3gRz0+3TYO6o25o/aMa2NAk7B3+4X6086qeKQZNJc7dSfcvzIhTZayUiautYJDy2DJ"The beginning of a script to download helm charts.
Most of the code related to devops practices should probably not be found in public repositories. It generally contains references to private hosts or internal documentation that is useless to the public community.
This devops code is commonly found on personal repositories, committed from personal accounts. It lives outside the typical corporate perimeter. Because of this, it can be difficult to discover their secrets using simple secret detection methods.
Strengthening Security for Artifactory Tokens
Artifactory token leaks represent a significant security concern, especially in corporate environments. Our research identified two primary exposure vectors: build configuration files (particularly Gradle and Jenkinsfiles) accounting for 60% of the leaks, and source code repositories in DevOps contexts. The fact that many of these leaks occur in personal repositories outside corporate security perimeters creates significant defensive challenges.
Following secrets security best practices is a must for such high-profile secrets. Vaults are widely regarded as the gold standard for secrets management. They can be backed up by CI/CD secrets management, such as GitHub repository secrets, when dealing with build secrets. This is especially relevant for Artifactory tokens that are often close to the build process.
Even with vaults in place, leaks outside the corporate scope—such as those found in personal public repositories—remain a significant challenge. By nature, they can escape corporate policy enforcement and go unnoticed. This is where having strong secrets detection capabilities matters. With GitGuardian Public Monitoring, you can detect leaks from your developers, even outside your corporate scope.
To finish, following software updates and providers' best practices is also important. If you use classic Artifactory API keys, those have been deprecated and JFrog recommends not using them anymore. Following the token deprecation guidelines and using more modern alternatives, while not perfect, already provides better security.
In the next post of this series, we will explore how attackers can exploit Artifactory tokens and highlight the exact impact of this exploitation.
