GitGuardian Platform Reviews

We use it for secrets detection.

Before we had GitGuardian we were "blind." We had no detections, which was very bad. We were using another product on GitHub, similar to GitGuardian, but it was not really as good as GitGuardian. The graphical interface and the detail GitGuardian gives you are really amazing. And there are fewer false positives than any other platform. We are able to notify developers of issues on the spot and tell them, "You have exposed a secret." It is absolutely brilliant.

It has definitely helped to efficiently support a shift-left strategy. Before this, we didn't have any detection, and we had a lot of false positives with other products. That meant people were spending and wasting a lot of time on false positives. That is not the case now. GitGuardian has fewer false positives, which is very advantageous. It has decreased our false positives by a minimum of 20 percent. The secrets detection is more accurate. Before, we had 20 false positives for every real incident. Now, we only get the one, real incident.

In terms of developers and our security team collaborating on remediation, GitGuardian has made everyone feel better. Usually, for developers, security is an overhead, but GitGuardian has never been an overhead. It is always helping developers understand where they did something wrong, and the need to fix it. That's what has allowed us to protect the developers and the company assets from security breaches.

The scope of GitGuardian's detection capabilities is better than anything else. When they give you a description of what happened, it's really easy to follow and to retest. And the ability to retest is something that you don't have in other solutions. If a secret was detected, you can retest if it is still there. It will show you if it is in the history.

It also helps to quickly prioritize remediation. They provide a score and, although it depends on the context, because what GitGuardian might say is a high-risk vulnerability might not be for us, it does the job properly. The scoring it gives is amazing.

There is room for improvement in GitGuardian on Azure DevOps. The implementation is a bit hard there. This is one of the things we requested help with. I would not say their support is not good, but they need them to improve in helping customers on that side.

I have been using GitGuardian Internal Monitoring for the last year.

Every single time I have accessed the platform, it has been available. And every single time I tried to use a feature, it was working. The stability is spot-on.

In the beginning, they were covering GitHub and then they started doing Azure DevOps. It is scalable and they are getting there.

As long as our company grows and we have more developers, we are going to increase our usage of GitGuardian. It's becoming a very heavy-duty tool that we depend on every single day.

GitGuardian's support is amazing. They helped us to set it up properly all the way. And whenever we give them feedback, they take it into consideration, if it is a new feature. And if it is a bug, they work on it and fix it. The support is superb.

The preparation needed on our side to start using GitGuardian wasn't anything out of the normal. It included the types of activities we have had to do with any other product. The onboarding was really good because they were there. They helped us the entire time.

Between developers and security personnel, we have about 25 users, but it does not require any type of maintenance on our side.

There's no direct return on investment. Security is overhead, but at least I'm sure that we are protecting our company assets, and that's a return on its own.

The pricing and licensing are fair. It isn't very expensive and it's good value.

We evaluated Dependable and GuardDuty. One of the main differences between these solutions and GitGuardian is the interface. The GitGuardian GUI is very good and much easier to use than anything else. It's very user-friendly. It gives you what you want. You can do as much filtering as you want. 

And another important difference over other technologies is that GitGuardian has fewer false positives, which is very advantageous. Dependable and Guard Duty give you things that are not relevant or that are false positives, at times. That does not happen often with GitGuardian.

If someone at another company were to say to me that secrets detection is not a priority, I would say that's not a very smart approach. Secrets detection is a very essential part of security. It's one of the basics that you need to cover all the time. Otherwise, you're going to expose your endpoints online and you're going to suffer endless attacks. You definitely need to have secrets detection tools. We use a combination of tools, but GitGuardian is my preferred tool.

When it comes to application development, secrets detection is essential to a security program. You need to have it. Otherwise, you'll fail.

In this technology, nothing is perfect yet and it's going to take time. But so far, GitGuardian is the best I've seen. Overall, it's a very good product.

Mainly we use GitGuardian to keep secrets out of our source code. That is something that we wanted to get serious about getting our hands around. This was the main driver because I had tried other tools like TruffleHog. It was cumbersome to manage the unwieldy Git history and to figure out. When you run TruffleHog, you have no way of knowing what's in the current branch versus your Git history. Hence, it's tough to decipher what secrets are still possibly valid.

We didn't have a secret detection tool in place before GitGuardian, so we had no solution that could detect when secrets were committed and sourced. With GitGuardian, we get an instant notification every time a secret is committed, so we can immediately triage it.

GitGuardian has absolutely supported our shift-left strategy. We want all of our security tools to be at the source code level and preferably running immediately upon commit. GitGuardian supports that.

We get a lot of information on every secret that gets committed, so we know the history of a secret. For example, if there are SMTP credentials that get used and reused, we can see where the secret may have traveled, so GitGuardian may give us a little more information about that secret because it can tie together the historical context and tell you where the secret has been used in the past. You can say, "Oh, this might be related to some proof-of-concept work. This could be a low-risk secret because I know it was using some POC work and may not be production secrets." 

I don't know how to quantify how much time it has saved our security team because we didn't have anything similar in place before GitGuardian. I can say that tracking down a secret, getting it migrated out of source code, getting the secret rotated, and cleaning the Git history took much longer from commit until the full resolution before GitGuardian. We weren't notified until it was too late, but with GitGuardian, we know almost instantly. 

We have standard operating procedures for every notification. We know how to rotate the secret. We know how to remove it from the source code. We have documented procedures for how to do that. We can rip it from the code, rotate it, and clean the Git history in a couple of hours. If something gets committed, it sits there for a while before we notice it.

Overall, GitGuardian has also helped us develop a security-minded culture. We're serious about shift-left and getting better about code security. I think a lot of people are getting more mindful about what a secret is. It's like back in the day before campaigns like Cofense PhishMe became a big thing. People were clicking phishing links all the time. Now you have these training programs where people see these things, and they're more aware of it. 

It's a similar situation when you're writing code as well. I think people are getting more aware of secrets. What is a secret? Does this belong in the source code? Sometimes they even come out and ask, "Is this a safe thing to commit to the source?" before they even commit it. They don't want to be "yelled at" by the GitGuardian. I think that it has had a positive impact on the culture itself.

You're only as good as the software you write, and you're in for a world of hurt if you put the keys to the castle inside of that source code that could be somehow reverse-engineered. By separating the two, the source code and the keys, you're one step ahead of that. I think it's essential.

The most valuable thing about GitGuardian is the speed with which it works. If you accidentally commit a private key to a public repo, you need to know that instantly. GitGuardian has this thing called "Dev in the loop." The developer who committed the secret is notified, and they get a form to fill out so they can give us instant feedback, which is super helpful for us. Due to the nature of the software we write, sometimes we get false positives. When that happens, our developers can fill out a form and say, "Hey, this is a false positive. This is part of a test case. You can ignore this." What's more, the tool helps us with triage. As soon as the secret is committed, we receive Slack alerts and jump right on it.

GitGuardian's "Dev in the loop" feature has sped up our time to remediation quite a bit. Of course, not every developer is responding, but that's just the nature of the organization itself. It's not the fault of the product. It's just that some people are not as quick to act. So when developers do respond, I would say issues get resolved several times faster because we know from the jump if it's an issue or not.

It's hard to evaluate how accurate the tool is because of the type of software we write. We're a vulnerability company here, so we write a lot of test cases using test data that are looking for things like secrets, so we have false positives. Some of GitGuardian's detectors take that information into account. With things like a general high-entropy detector, we expect a potentially high false-positive rate. However, for something like an AWS key detector, GitGuardian's efficacy is near a hundred percent, if not 100%. I can't recall any instances off the top of my head where it inaccurately flagged an AWS key or an Azure key.

One improvement that I'd like to see is a cleaner for Splunk logs. It would be nice to have a middle man for anything we send or receive from Splunk forwarders. I'd love to see it get cleaned by GitGuardian or caught to make sure we don't have any secrets getting committed to Splunk logs. That was an issue that I brought up a while ago. However, my workload just hasn't allowed me to sit down and figure out how to solve that. That is one thing that I wanted to see if I can use in that regard because secrets are a thing that ends up in logs, and that's not something we want.

The first time I looked at GitGuardian was about a year ago now. We have open-source information on public GitHub, but all of our proprietary code is on an internal GitHub Enterprise Server. When we set up our internal GitHub Enterprise Server and deployed GitGuardian, it had no network path out to the public GitHub. I worked with GitGuardian, and they set me up with public monitoring. I would monitor all of my public open-source information with the public offering. Then I would also have my internal monitoring setup for everything on our GitHub Enterprise Server.

GitGuardian has been pretty stable probably 99% of the time. There was one time where I had a slight hiccup, so I restarted the cluster, and it was good to go.

I think GitGuardian scales well. It's adequately scaled for what we are using it for right now. I don't see that growing. Right now, we just have it hooked up to our source, and it can handle that. Now, if we were to expand into possibly doing the Splunk use case, that might bring in an API. In that case, I'm not sure what the performance impact would be, but I don't think it would be that bad. You throw a couple of extra nodes out there, and it should be fine. It's currently being used by all of our developers. Everyone who commits code is using it. It scans all of our code.

GitGuardian's support is fantastic. I don't think I could rate them anything less than a 10 out of 10. We had a few questions about how to stand up our deployment. The SRE assigned to our project was readily available and very knowledgeable. He jumped on a call and spent crazy hours helping us out. I thought they were very flexible and easy to work with. I've never had an issue with their support. They've given us everything I've needed when I needed it.

Positive

We installed the software and connected it to our GitHub. Literally within minutes, it was scanning and finding secrets in our GitHub. It doesn't take long to get it up and running and we didn't have to make any significant architectural changes before deploying GitGuardian. We only had to stand up a VM and then set up the network pathways to talk to our GitHub. That was a very minimal amount of work from our CIS ops team to put that out. After installation, it doesn't require much maintenance. When they tell me a new release is out, I log into the console, click the upgrade button, and it does its thing. 

We've absolutely seen ROI. For example, if somebody accidentally commits an AWS key to your public GitHub, somebody can take that key and spin up EC2 instances, which can cost us thousands of dollars. The fact that we can catch it is almost invaluable, but it's worth the investment to have the tool. Everything is cheaper if we can find an issue and resolve it sooner. It's much more affordable to remove a secret well before it gets merged into a master branch than it is to try to rip out the historical commit. It affects the bottom line in that regard.

I think GitGuardian's price isn't too expensive. I'm not sure about any add-ons or additional costs because I wasn't involved in purchasing GitGuardian. I know the ballpark price, but I did not handle the pricing. Other people in our organization negotiated the pricing, but I'm not aware of any hidden costs or anything like that. 

We looked at some open-source solutions like TruffleHog, and we also looked at the GitHub secrets detection, but the issue was that it was bundled with their advanced security, which we were not planning to purchase. GitGuardian just made perfect sense for us.

GitGuardian has the GUI that TruffleHog doesn't have. TruffleHog can scan your GitHub and tell you where secrets live. But it does not do a perfect job of telling you where those secrets live within your timeline. GitGuardian does an excellent job of telling you the branch where those secrets live and where they are on the timeline. The Github tool does pretty much the same thing, but it was off the table for us because we were not planning on purchasing their advanced security toolkit.

I rate GitGuardian 10 out of 10. It does everything that I need it to do, and I'm excited about the new features that are coming along at this point. It has really helped us change our culture, and it's impressive to see that. People are now more mindful of what gets committed to source code. I would recommend GitGuardian.