GitGuardian Platform Reviews

We use GitGuardian to check standard configurations and scan for possible leaked secrets. Developers and software engineers sometimes commit to AWS keys, login credentials, SMTP databases, and other secrets.

Given the size of our operation, there's a lot of work to do on the security side in GitHub alone. GitGuardian enables us to avoid leaks in the source code on the GitHub side and helps devise a plan to fix them. Sometimes it doesn't find the leak, but it identifies the type of leak. The solution typically does an excellent job on that part. We can locate the crucial leaks and try to remediate those first. GitGuardian makes the job easier and faster.

It improved the coordination between developers and security personnel. Having a top-down mindset is not so great in terms of security. We have some roadblocks that get in the way of security best practices. GitGuardian's features help us to improve that. People need to improve their mindsets as well. 

We don't have a security team. The company doesn't have this in the core. We began implementing security in our code with GitGuardian, so we don't have a baseline to compare it to. We had nothing, and now we have GitGuardian for GitHub. It works pretty well and helped us to improve for sure. The time-to-remediation depends on the software engineers. We do not do the remediation; they prioritize as they want, so that's the mindset issue again. 

GitGuardian helps us to quickly prioritize remediation. At the same time, we need to work on internal policies regarding what engineers should do. They do not prioritize remediation as much as we think they should. This is a company problem. We didn't have as much emphasis on IT security, cybersecurity, or DevSecOps before we started doing this. We are trying to change their mindset and show how dangerous it could be if secrets are leaked.

We didn't require much preparation to use GitGuardian except for a one-hour training session with GitGuardian. The tool is pretty easy to use and has nice consoles. In one or two hours, we are ready to utilize the tool. The rest was checking configurations and reading documentation. We had to read up on features like single sign-on and how to note a secret leak as a comment in the pull request.

The entire GitGuardian solution is valuable. The product is doing its job and showing us many things. We get many false positives, but the ability to automatically display potential leaks when developers commit is valuable. The dashboards show us recent and historical commits, and we have a full scan that shows historical leaked secrets.

I would rate the accuracy an eight out of ten. We get false positives, but it's not because the tool is working incorrectly. Our software engineers commit things like the API key because they know they're unimportant. We consider them false positives because they are not real leaks. The false positive rate is low and will probably improve with time. 

The AWS secrets tool and ggshield have the same functionalities, but I'm not sure how they do everything behind the scenes. GitGuardian has good tech knowledge, but we still see too many false positives. We don't have a granular way to tell GitGuardian on the SaaS side to ignore specific secrets. We have to filter everything after it's done.

GitGuardian has single sign-on integration, which we implemented to make tasks easier for everyone. With SSO, we can send a link to GitGuardian instead of creating a ticket for that. People couldn't engage correctly with GitGuardian before we implemented SSO.

GitGuardian could have more detailed information on what software engineers can do. It only provides some highly generic feedback when a secret is detected. They should have outside documentation. We send this to our software engineers, who are still doing the commits. It's the wrong way to work, but they are accustomed to doing it this way. When they go into that ticket, they see a few instructions that might be confusing. If I see a leaked secret committed two years ago, it's not enough to undo that commit. I need to go in there, change all my code to utilize GitHub secrets, and go on AWS to validate my key.

It would be helpful to have small instructions to show developers how to deal with an issue. They ask us what they need to do each time, but it's always more or less the same. GitGuardian could send them clear steps, so they can engage without needing help every time. 

I have used GitGuardian for around six months.

GitGuardian is stable for our use case.

We have almost a thousand report stores, and it scans correctly, so we don't face any scaling issues.

I don't remember the specifics of the contract, but we have a one-year license for a set number of developers. It's reasonably priced. 

I rate GitGuardian a ten out of ten. It's a user-friendly product that's ready to go. You don't need anything besides the initial onboarding training to use this tool. If you are concerned about your security and want something ready to go, GitGuardian is an excellent option for a fair price. I recommend it. GitGuardian is a better choice than an open source solution if you are serious about preventing leaks on GitHub and your developers lack security awareness.

Secret detection is one of the essential aspects of application development. Leaked secrets are the main reasons for getting hacked. Often, secrets are leaked by an employee searching and finding secrets they should not, or someone makes a private post public because they don't know the secrets were there. Many bad situations happen because developers don't know what they are doing or don't care. The company mindset needs to change, but we still have a long way to go. 

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. 

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.

Neutral

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.