TruffleHog owes its success to the amazing support and commitment of the open source security community. Security engineers graciously volunteer their time to improve our secret scanner’s capabilities by submitting bug fixes, extending test coverage and proposing new features. As a small token of our appreciation, we’ve decided to highlight one outstanding contributor every quarter. Each post will feature a small Q&A with the contributor. Our goal is to motivate additional contributors to join our community and keep advancing open-source secrets scanning.
Introducing our inaugural contributor: Richard Gomez.
Richard has been a dedicated supporter of the open-source TruffleHog project. He has made significant contributions by submitting numerous PRs and actively participating in the community on Slack (join here). Richard’s efforts to improve TruffleHog have not gone unnoticed, and our entire team is sincerely grateful for his hard work and dedication.
Below is a transcript of a Q&A we had with Richard:
Truffle: Can you share a brief introduction about yourself and your current role?
Richard: Of course! I’m a passionate software developer and security professional based in Ontario, Canada. Currently, I’m a Senior Security Specialist on the Royal Bank of Canada’s Red Team. Our team focuses on testing and enhancing RBC’s security defenses by simulating adversary attacks.
Truffle: How did you first come across TruffleHog?
Richard: I first came across TruffleHog back in early 2019, before my shift from software development to security. During that time, there was a growing concern about secret leakage in source code, fueled by incidents like the Uber hack in 2016. After some futile attempts manually searching for “dorks”, I started looking for a tool that could automatically detect potential secrets in my code. That’s when I discovered TruffleHog. I was blown away by its ability to uncover secrets using high signal regular expressions and entropy checks; I found more secrets in my first hour using TruffleHog than I had in an entire week of searching by hand.
Truffle: In what ways do you utilize TruffleHog for your work or your personal projects?
Richard: I tend to use TruffleHog for both work and personal projects. In my free time, I often run it against third-party codebases and artifacts to uncover potential leaked secrets. While my primary motivation is to help projects enhance their security posture, I can’t deny the thrill of discovering secrets — I truly feel like a pig hunting for truffles. Of course, when I run it for my own code or code that I’m reviewing, I’m hoping not to find any secrets!
The versatility of sources (e.g., filesystem, docker, git) and decoders/handlers (e.g., base64, compressed archives) makes it easy to run a set of detectors across a diverse set of inputs. I tend to use –no-verification and review results manually because I like to hunt for generic results that can’t be verified programmatically; I wouldn’t recommend this for everyday use, however, I think it’s worth doing at least once per repository.
Truffle: Have you uncovered any public secrets using TruffleHog? If so, is there an interesting story around that (without revealing sensitive details)?
Richard: I have, both several years ago with v2 and recently with v3! During one of my “deep dives” using --no-verification, I stumbled across a private key inside a company’s public Git repository. It was not associated with anything obvious or programmatically verifiable, such as a GitHub SSH key, but I suspected that it was important based on the context. I eventually discovered a hardcoded public key in a sister repository, alongside some excellent documentation, which allowed me to confirm that the private key was indeed “live”, after which I disclosed my finding to the company’s security team. Without that vital context, I wouldn’t have been able to validate the secret and may not have reported it.
This was particularly rewarding because most generic secrets I find are not possible to validate, even if they seem important. I will still occasionally disclose them if they seem important enough, but I hate wasting people’s time.
Truffle: When it comes to managing secrets, what’s one piece of advice or insight you wish more people were aware of?
Richard: That’s a tough question, there’s a lot that I wish people knew about secrets management. If I had to choose one thing, it would be the importance of managing secrets and the risks associated with neglecting to do so. That might seem obvious, but let me elaborate.
While many secrets are unintentionally leaked due to common mistakes like accidentally committing an .env file, in my experience a substantial number of leaks occur because individuals knowingly include secrets in insecure places like documentation or source code. For instance, secrets stored in “private” repositories are not as secure one might assume. The visibility setting could be changed to “public” at a later stage, a contractor or intern could upload the code publicly for their portfolio, or a threat actor could gain access to your environment, discover these secrets, and exploit them for lateral movement or privilege escalation.
Organizations should operate under the assumption that they will eventually face a security breach and implement a defense-in-depth strategy. When it comes to secrets management, this involves training employees on proper secrets management practices, using a secrets management solution to secure, manage, and rotate secrets, and proactively scanning for and remediating leaked secrets. These measures are essential for maintaining a secure environment and mitigating the risks associated with a potential breach.
Truffle: Have you ever been responsible for accidentally revealing secrets? If so, how did you handle that situation?
Richard: While I’d like to believe that I haven’t accidentally revealed secrets, it’s such an easy mistake to make that I can’t definitively say that I haven’t.
When writing code, I try to judiciously review changes with git add -p, rather than using git add ., which has prevented me from accidentally committing secrets on several occasions. In the event that a secret were to be pushed to a central version control system like GitHub or GitLab, I would immediately purge the history using BFG Repo-Cleaner and rotate the secret as soon as possible. Rotating secrets is a crucial step that people often overlook — the blog post “Deleting leaked API keys isn’t a solution” does an excellent job of explaining why it’s necessary.
Truffle: Among the myriad of open source secret scanners available, what sets TruffleHog apart for you?
Richard: I’m a huge fan of TruffleHog’s platform-agnostic design and growing list of integrations. While secrets leakage is a common issue in version control systems, there are numerous other places where sensitive information can be inadvertently exposed such as build artifacts, Confluence spaces, or network shares. The OWA and Outlook.com hack earlier this year was attributed to sensitive signing keys being leaked in a crash dump, which I think highlights the importance of scanning for secrets beyond the confines of platforms like GitHub.
Truffle: What TruffleHog features do you use most often?
Richard: I mainly use TruffleHog for ad-hoc source code scanning, so I’ve probably used the Git/GitHub scanning the most. That use may wane as controls and detections for secrets in source code become more commonplace. Recently, I’ve been experimenting with Docker image scanning; build artifacts are still a veritable treasure trove of secrets, as they’re far more opaque than source code.
Truffle: Are there any upcoming features or enhancements you’re looking forward to in the future?
Richard: I’m looking forward to using the recently reintroduced entropy filter (#1875) to find more actionable generic secrets. While I appreciate the value of only receiving verified results (no one likes dealing with a sea of false positives), I love the thrill of finding a needle in a haystack.
PR 1875 – Adding an Entropy Filter
Truffle: Is there any particular contribution that you’re most proud of?
Richard: My favourite contribution thus far has been refactoring the logic responsible for parsing Git diffs. It was a fun challenge to identify the source of a bug and develop a solution that didn’t impact performance or parsing accuracy, especially because I wasn’t familiar with TruffleHog’s codebase at that time. That experience also gave me a deeper appreciation for something I wouldn’t typically give much thought to: the intricacies of git log and git diff formats.
One of Richard’s Contributions (PR #1486)
Truffle: What motivates you to contribute to TruffleHog?
Richard: TruffleHog is an outstanding tool, and the fact that it’s open-source with such a supportive team makes it a natural choice for me to contribute to. I know that the team works diligently to ensure result accuracy, but secret scanning can be quite nuanced, and edge cases are bound to arise. By contributing, I not only benefit myself but also contribute to the security and resilience of other organizations and individuals that rely on it.
In a broader sense, I’m a strong advocate for user experience (UX/UI) and the value of providing feedback early and often. There’s a fantastic blog post from 2019 titled “They Might Never Tell You It’s Broken” that highlights why most people don’t report bugs. It’s one of the reasons why I make a conscious effort to provide feedback whenever I encounter an unusual bug or think of a feature that could be valuable.
On behalf of Truffle Security, we’d like to formally thank Richard Gomez for his contributions to TruffleHog as well as for spending time being interviewed for this blog post. If you’d like to contribute to TruffleHog and potentially be featured in a Contributor Spotlight, please review our section on Contributing.
