GitGuardian Platform is a security tool preventing the exposure of secrets. It is particularly valuable as a tool because it doesn't just identify exposed security issues, but works as a platform that gives developers an intuitive and easy way of reacting to and fixing the issues.

GitGuardian Platform captures all the major secret types we care about. It tends to be a bit overzealous in some categories, but it covers all the ones that we want to track and keep an eye on. It has great coverage over those.

GitGuardian Platform has helped save significant time for the security team by eliminating the need to seek out development teams and work with them on exposed secrets, as much of this is now handled proactively. The built-in process for developers interacting with exposed secrets saves them time fixing security problems before returning to their tasks. We can also provide customized remediation guidelines to developers.

Automated validity checks are super critical for us. If something is confirmed as valid in the platform, we know there is some externally accessible value that's exposed somewhere. It's then the top priority for us to engage in. It also gives us a lot of confidence. When the development teams come back and say that they have fixed it, GitGuardian Platform confirms that.

We rely a lot on GitGuardian Platform's self-service functionality so that developers handle incidents without us having to take action. We don't rely on automated severity scoring for incident management. While the severity rating is decent, we focus more on the validity feature and detector categories than on GitGuardian's high-risk ratings. We have customized remediation guidelines by providing specific internal context for handling exposed secrets. We use GitGuardian's integrations with other tracking platforms, but we don't have everything funneled into Jira. We use our own prioritization to see which ones we want to funnel into Jira.

The platform has given us a clear picture of the historical landscape, showing what has been fixed versus what remains hidden in historical data. This clarity has been helpful in planning security measures around issues that don't get self-healed.

We have it scanning our GitHub environments, Atlassian suite (Jira tickets, Confluence), and Slack messages. That gives us a nice coverage across the business.

The validity and self-healing playbook features of GitGuardian Platform is one of the most useful features for us. It automatically reaches out to developers for any leaks, notifying them immediately via email. We have Slack notifications set up, allowing developers to respond, provide feedback about sensitive values, and self-close issues by attesting completion on the platform. A high number of our exposures are remediated by developers before security needs to step in, as the self-healing playbook process engages them automatically. This results in issues being resolved within minutes, saving significant effort from the security team in tracking down or communicating with developers.

The analytics in GitGuardian Platform have a significant opportunity to better reflect the value provided to security teams and demonstrate actual activity occurring. While the self-healing capability and proactive developer actions are important features, the analytics do not provide information around this activity. They only track actions inside the platform when security team members assign themselves to issues and respond. The self-healing activity by developers isn't reflected in the analytics, requiring us to collect this data ourselves. This presents an opportunity for them to better showcase their developer-first remediation mindset.

We have been using GitGuardian Platform for approximately nine months.

It's a stable platform, we don't often have to think about it. The SaaS platform has experienced two significant moments of downtime or instability in the last six months, requiring notices and retrospectives. We also run a self-hosted cluster which has not experienced these issues, though we've faced some challenges upgrading Kubernetes that required support assistance to prevent internal downtime.

It is scalable. I would rate it a nine out of ten for scalability.

My product security team administrates the platform, with a few other security people accessing it. Access to respond to incidents is deployed for every engineer. Team-based provisioning is not yet supported with SCIM, which makes team-based grouping a hassle, so we do not use it.

I would rate their technical support a nine out of ten.

We were using a home-grown solution.

The initial setup of the self-hosted cluster was moderately complex. We faced some issues because of the environment we had. We had to fix some installation errors and bugs in their Helm configuration.

In terms of deployment model, we self-host a cluster out of necessity. We have an internal GitHub Enterprise server. We self-host GitGuardian Platform to connect to that environment. We also use their SaaS version for Slack and Atlassian integrations.

We implemented in-house.

The majority of our incidents for critical detectors and important secret types are remediated automatically or proactively by developers through GitGuardian's notification system, without security team involvement. It saves a lot of time for the security teams and the developers. It probably saves approximately 10 hours per week. Previously, we needed an extra 20% of our time focused on this subject area, which has now been saved because of this platform.

It's competitively priced compared to others. Overall, the secret detection sector is expensive, but we are happy with the value we get.

We evaluated other vendors on the market. The secret detection capabilities of most vendors are basically equivalent, capturing all major types of secrets. The management and administration of findings after scanning is what differentiates vendors. Many alternatives lack strong administration capabilities for security teams after finding detections. GitGuardian's dashboard, self-healing playbooks, and ways for the security team to monitor, track, and deduplicate detections make it easier to manage the program compared to competitors.

I would recommend GitGuardian Platform to other users due to the ease of management for the security team with the dashboard. It offers easy administration of results. The proactive self-service capabilities provided to developers remove the burden from the security team and enable faster remediation of exposed values.

My overall rating for GitGuardian Platform is an eight out of ten.

We use GitHub as our source code platform. When we shifted from on-premise version control systems, we identified a requirement for capable tooling that could both find secrets that were committed in the past, and prevent and alert on secrets that were being accidentally committed.

GitGuardian gives us a better understanding of what's going on in our source code. Persistent use of the platform has allowed us to highlight areas where we need to improve; eg. providing training so that people know what information should and should not be in GitHub.

We've managed to use this data to improve practices related to where teams store their secrets, and have also been able to use it to understand where we might be lacking tooling.

When a developer commits a secret or there's a particular pattern in a repository, we often ask them about why they did this. They may turn around and say that there's no better option at the moment because we don't have a platform to suit x, y, or z. We can use that information to then drive decisions around whether or not we need to look into improved tooling or patterns that our engineering teams can use to avoid storing secrets in their source code.

Automated validity checks are very helpful; we use them to prioritise incidents, as they give us a quick understanding as to which secrets are still valid. They also help us to confirm that token invalidation - which sometimes has to be done by another team or a third party - has worked as expected.

We also utilize some of the automated playbooks, specifically those around automatic incident closure, allowing us to spend less time making sure that the incidents closed by changes to code are getting closed out.

Instantaneous notifications connected to our Slack platform allow us to deal quickly with incidents if and when they occur.

One of the best features of the solution, though, is the ability to use pre-push hooks. Preventing our developers from committing secrets into their source code before they hit the remote GitHub servers is ideal; it can be quite challenging and time consuming to remediate and rotate secrets once pushed to the remote.

The reporting feature has improved quite a bit since we first used it around five years ago, with filters that allow us to set up quick groups of or collections of filters and statuses to determine which secret detections are still unassigned and which are new. It allows us to easily ship those off to the developers involved in those incidents to get them remediated.

We'd love to see notification updates in Slack, as the system does not provide feedback on updates to incidents, which can be problematic when developers resolve issues.

ie. if a developer commits code that triggers an incident, the alert comes into Slack, but by the time someone looks at it through the Slack alerting channel, the developer might have gone and already fixed or closed the issue. There's no feedback loop back into the notification channel to show that it's been addressed.

Another thing that would be good to see is some more metrics on the usage of the GitGuardian pre-push hooks. It would be helpful to see which GitHub users have or do not have the pre-push hook capability turned on. That would allow us to chase people and say that we noticed that you're making commits, but you're not using GitGuardian, and encourage them to install ggshield before an accident happens.

My experience with the solution started in November 2020, which is approximately four or five years.

It's generally quite stable.

There has been a little bit of downtime of late, and it has been reasonably impactful when it's not been scanning. We set up our repositories in GitHub with GitGuardian as a required check.

We had an incident for about four hours last week and another one about a month before that. Prior to that, it's been really stable.

It handles all the repositories and commit activity we have.

I would rate their technical support an eight out of ten.

No

We didn't have to do much. They manage all of the backend for us. All we have to do is integrate it into our GitHub organizations, and doing that is straightforward.

The solution does not require any maintenance.

In-house.

It's challenging to quantify, but it has saved us from a bit of panic because we know the state of our source code. It's hard to determine what savings might come from having the tooling or not.

It's fairly priced, as it performs a lot of analysis and is a valuable tool.

We have tested it against other solutions, such as TruffleHog, the open-source solution, and found the GitGuardian Platform to be about significantly better in terms of detection capabilities. TruffleHog focuses on secrets that it can validate, but in an Enterprise world with lots of internal tools, APIs and platforms it can miss a lot of secrets.

The new multi-vault feature looks useful; we are planning to connect it up to AWS Secrets Manager and HashiCorp Vault.