Code security provider GitGuardian has added a new honeytoken module to its platform to help customers secure their software development life cycle and software supply chains with intrusion and code leakage detection assistance.
Honeytokens are code scripts containing decoy credentials, which can be placed within a customer’s development environments to lure out attackers looking to target critical DevOps environments such as source control management (SCM) systems, continuous integration continuous deployment (CI/CD) pipelines, and software artifact registries.
“Our honeytokens look just like any other secret to attackers, tempting them to exploit them for further lateral movement inside the victim’s organization,” said Soujanya Ain, product marketing manager at GitGuardian. “Rather than allowing access to a customer’s actual resources, they act as tripwires that reveal information about the attacker.”
Security teams will be able to monitor their honeytokens and based on the triggers, prioritize securing the credentials that hackers target the most within GitGuardian’s existing console. This capability will initially be available in beta for free to existing customers on an on-demand basis, with plans for general availability in the future with additional charges per usage.
Triggers by any secret scanner used by attackers
Passwords, access tokens, and other sensitive information within a customer environment are usually traced through an automated secret scanner tool designed to scan code repositories, application code, and other sources of software code, identifying secrets that should not be publicly accessible.
Malicious actors often exploit the functionality of these secret scanners to extract secrets from user repositories. GitGuardian’s honeytokens are meant to be picked by these secret scanners to detect and reveal an attacker’s hack infrastructure (IP addresses).
“We designed our honeytokens to be triggered by all types of secret scanners including open-source projects like TruffleHogs, Gitleaks, and Gitrob. Whenever a hacker uses any of these secret scanners, they will trip on the honeytoken, triggering an alert that notifies the security teams of a potential security incident,” Ain said.
When triggered by an attacker, the GitGuardian honeytokens are designed to track critical information about the source of the attempt. These useful deliverables include the timestamp of the attack, type of action performed eg. GetCallerIdentity, ListBuckets etc, and the source of honeytoken indicating the target location.
GetCallerIdentity and ListBuckets are two crucial Amazon Web Services API calls that provide access to secrets and buckets (containers for files, images, and other data) stored in different AWS accounts.
The number of honeytokens a subscribed customer gets depends on the size of the organization, the number of developers involved, and the collection of assets to safeguard, according to Ain.
Unique placement detects code leakage
GitGuardian monitors real-time activities in public GitHub. Public GitHub refers to all the public repositories on the GitHub platform that can be accessed and contributed to by anyone on the platform, as opposed to private repositories that restrict access to select accounts and contributors.
This real-time monitoring allows GitGuardian to detect any leakage of secrets on public Github, notifying developers as and when they happen. These detections can alert the security teams about the source of the breach and the compromised resources by tracing the placement made for the leaked honeytoken.
“We recommend deploying each honeytoken in a unique location to ensure the most accurate detection and response to potential security threats. If a honeytoken is repeated in multiple locations, when it is triggered, it can make it more difficult to pinpoint the specific asset that has been compromised,” Ain said.
This is why despite being an isolated piece of code that can easily be copied and pasted across resources to plant decoys, each honeytoken needs to be unique to be placed at a unique location to efficiently track each incident to the source placement.
Nevertheless, the pricing of a GitGuardian honeytoken will not be affected by the number of times a single honeytoken is copied, pasted, or triggered, Ain said.
The “publicly exposed” honeytokens are identified and filtered from the honeytokens list on the GitGuardian dashboard.
“When a honeytoken is triggered, if we recognize the source IP as one from GitGuardian’s infrastructure, it indicates that their code has been leaked on the public GitHub. We then tag the event and honeytoken as ‘Publicly exposed’,” Ain said.
Last year, GitGuardian launched ggcanary, a free, open source project that enables organizations to deploy honeytokens in their codebase or configuration files to detect intrusions in their DevOps environments.
Copyright © 2023 IDG Communications, Inc.
