GitGuardian: The credential layer security platform (non-US companies)

My main use case for GitGuardian Platform is for secret detection in the code base, whether in the actual files or in the history of the GitHub code, helping me determine if there are, or were at any point, hard-coded secrets like API keys, passwords, or certificate key stores, and whether they are valid or false positives that require immediate remediation or remediation later on.

There was a specific time when GitGuardian Platform helped me catch something important, as it detected a couple of secrets that were still used in a project that had been migrated. We discovered in the history that while the current files contained no hard-coded secrets—everything had transitioned to using Secrets Manager—GitGuardian Platform identified two valid secrets in the GitHub history that needed to be deleted, although they were not critical or dangerous. To be on the safe side, we changed those secrets after ensuring they were properly removed from the history.

I have nothing else to add about my main use case or how I use GitGuardian Platform day-to-day. It is nice how it automatically scans whenever there is a commit in the GitHub repository, and even when a commit is deleted, the ID of the commit remains visible but grayed out, as it doesn't exist anymore. I would mention the validity check for public API keys is very useful while monitoring the security score. One limitation I've found is that as the tool progresses and updates, it may detect older secrets that have already been resolved, so it would be helpful to get notified when that occurs. Another significant limitation we've encountered is when the same secret is present in multiple repositories managed by different teams; we cannot close the incident unless both teams communicate and agree, because closing is applicable to all repositories, which is challenging when teams don't know each other.

GitGuardian Platform has positively impacted my organization by making the team extra careful about committing hard-coded passwords, even if they are just for testing purposes and deemed invalid. Additionally, my team has started integrating GitGuardian Platform on their local VS Code to scan before pushing code. It has also encouraged the habit of rotating old secrets that were at one point flagged in the tool.

I haven't noticed a reduction in security incidents, as we don't have many because we prioritize security in our development cycle. However, I can say that GitGuardian Platform helped us clean up our GitHub repositories of any type of secrets, even the useless ones, ensuring that if someone were to gain access, they wouldn't know what our API key or password looks like. It has especially helped us eliminate valid secrets from our repository histories, and we currently have zero valid secrets left.

The best features GitGuardian Platform offers include secret detection regardless of the commit history, which means it can detect both current and older files. Its ability to check the validity of API keys is crucial, and it allows tracing of actions regarding secrets—whether they are marked as false positives, invalid, or if remediation is necessary. Additionally, it facilitates the use of tools such as Slack or Teams for notifications.

I find myself relying the most on the instant scan of passwords offered by GitGuardian Platform, as it accurately checks for real secrets and does not mistake common words such as 'password' as a secret. This is advantageous compared to other tools that increase the rate of false positives significantly, which often occurs with keys that are merely for testing or are invalid.

Regarding improvements for GitGuardian Platform, the secret detection feature needs upgrading as it opens only one common issue for the same secret detected in multiple repositories. This poses a challenge, especially if two teams in different repositories, who don't know each other, are working with the same hard-coded secret. Team A cannot close the ticket independently because they are unaware of how Team B is using that secret. It would be much more effective to have a parent ticket for the secret that contains child tickets for each repository, allowing each team to manage their status for that secret as they see fit.

The reason I chose a nine or nine and a half is due to the pain points I've mentioned, particularly the challenges when validating secrets. Additionally, I prefer being notified whenever a new secret is detected in the GitHub history.

I have been using GitGuardian Platform for almost two years.

GitGuardian Platform is very stable, with no downtime or issues in my experience.

The scalability of GitGuardian Platform has met my organization's needs as we have grown or changed, and I did not notice any difference.

Previously, we used the password detection feature in Checkmarx, but we switched because we found it unreliable. Checkmarx often flagged many false positives, sometimes misidentifying the word 'password' as a real password or mistaking names of secrets in Secrets Manager or Key Vault for secret values. Their lack of capability to detect hard-coded passwords in the GitHub history was another issue compared to what GitGuardian Platform offers.

I have seen a return on investment, particularly in securing the applications and ensuring there are no hard-coded secrets within the code base, which is a significant security positive.

I haven't had the chance to thoroughly explore GitGuardian Platform's AI capabilities, so I'm not sure how I can answer that. Regarding my experience with the accuracy and reliability of GitGuardian Platform's AI capabilities, prior to their implementation, I found them to be helpful, especially in deciding the severity of a password when evaluating its risk from someone outside the application. My advice for others considering GitGuardian Platform is to move forward with it, as it's a great tool. I would rate GitGuardian Platform overall at nine, or nine and a half.