GitGuardian Platform Reviews

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. 

GitGuardian Internal Monitoring is a tool we use to deal with internal credential leaks. We found that our development teams included sensitive credentials in merge requests with concerning frequency in the early days of our startup. 

We have 45 GitGuardian users. Most are developers or engineering managers, and a few are security team members. Our development team is much larger than our security team, so GitGuardian's ability to pull developers in and turn them into security analysts is quite helpful. GitGuardian notifies developers of the credential leak they created and lets them take the appropriate steps to remediate it. That's preferable to having our limited security team take care of it for them.

GitGuardian has improved our visibility, which is crucial for a startup with a small security team. The ability to automate detection and response for credential leaks is massive. We're an early-stage startup that is moving extremely quickly. When you're moving fast, you might ignore your code's structure and security. 

Periodically, a developer would accidentally leak a key or short-circuit some logic on their machine, which led to credential leaks throughout the code base. GitGuardian helped us handle the technical debts of moving extremely quickly. 

It enables us to identify leaks that happened in the past and remediate current leaks as they happen in near real-time. When I say "near real-time," I mean within minutes. These are industry-leading remediation timelines for credential leaks. Previously, it might have taken companies years to get credentials detected or remediated. We can do it in minutes.

GitGuardian is crucial for our shift-left strategy. We use GitLab because of our choice of SCM providers. It doesn't support pre-commit hooks on the server side. When deployed through developers, pre-commit hooks require the developers to opt-in and actually use them.

Although we could potentially prevent secrets from ever reaching the remote, it's notable from a technical aspect. We must detect it as soon as it hits the remote, which is precisely what GitGuardian does. I understand there is a way to do pre-commit hooks with GitHub, and I think there is also one self-hosted on GitLab. It's a third-party technical issue for us. Given our choice of SCM providers, we push it as far left as possible.

I spend a lot less time triaging reports about potentially detected credentials. Once things are pushed to GitHub or GitLab, they are difficult to remove. It's useful to prove that to the developer and hold them accountable for timely remediation. If we find something in a repository, we notify the entire team and ensure that multiple team members are available to remedy any issues. It keeps everybody on the team aware of this problem and helps us work toward safer development practices. 

We aren't using the playbooks extensively. I think only one or two people use them. The playbook I'm currently using notifies the developer duplicated in the credential leak. That one is useful. The ability to automatically grant access to the developer involved in the incidents is helpful because it eliminates a step needed for a security team member to act. We also have the resolved incidents playbook enabled. When we have credentials from a third-party source like AWS that are remediated outside the platform, the incident is automatically closed for us. That saves the security analyst the hassle of tracking down a user and closing an incident.

It reduces work for the security team because they don't need to reach out to a user to ask them about the risk of a particular credential being in source control. They don't need to track remediation through a third-party tool. We no longer have to take these steps because we can deal with the incident directly.

GitGuardian increased security team productivity relative to our open-source detection tools. While we benefited from using those tools, the false positive rate was too high to be viable for us long term. With GitGuardian, our false positive rate is nearly zero.

We're only spending about a minute on each incident now, and the time saved scales up depending on the number of incidents. The development teams are aware of this tool, which notifies them when credentials are leaked, so they are much more conscientious about it. Leaks are becoming rarer because GitGuardian shaped developer behavior, saving the development and security teams time. It's difficult to quantify precisely how much time is saved because the number of incidents has been reduced over time. GitGuardian is more of a trusted watchman than an incident response tool. 

Although developers are familiar with the operational side of Git, they're not as aware of how pervasive credential leaks are once they reach a remote. It's crucial to be mindful of the risk of a valid credential leak and a generalized knowledge about what happens to a commit once it hits GitHub or GitLab. Secret detection must occur as early as possible in the development pipeline as an insurance measure.

Before I joined the company, the mean time for remediation was from weeks to months. I've heard that it has been a pervasive problem in the industry. GitGuardian can scan the entire repo and see the backlog of unhandled credentials. This was an immediate benefit of the tool. Now that we have paid off the debt of having credentials in source code, it acts as a monitoring tool. We are jumping on that incident as soon as we are notified. It takes less than a minute for us to get in there and understand the potential scope of a credential leak. Getting a developer looped in takes a few additional minutes and deciding on the resolution takes a few extra minutes. In some cases, we've reduced the resolution time to a few minutes from months or years.

I previously worked with open source secret detection solutions and found the efficacy of those tools to be highly suspect. We tried some off-the-shelf tools and found that they had massive amounts of false positives. I like that GitGuardian is highly accurate. It finds legitimate credential leaks 99 percent of the time. A low footprint of false positives means we can use the tool effectively. 

The false positive rate is near zero, which sets GitGuardian apart from other solutions. I've worked with open source tooling that had extremely high false positive rates. When using your credential schemes as a security company, you must be careful about how you use them. They exist in a manner that isn't documented, such as a third-party credential. Generic secret detection for high entry protection is essential. 

The reports we got from the solutions we used before GitGuardian were almost unusable. The noise-to-signal ratio was far too great. Now, I get maybe one report a week containing an incident that we need to investigate. There aren't any incorrect findings. It will be a credential or a testing credential that we can ignore. 

We had concerns about the historical aspects when we implemented GitGuardian because we have a massive repo that about 50 developers are using simultaneously. It's three years old, so it contains a lot of data, and we had issues with some scans timing out. However, we contacted GitGuardian's support, and they loosened some restrictions. We've had no problems since then.

GitGuardian discovered some credentials we didn't know existed for services that haven't been documented anywhere. It helps to prioritize remediation by testing credentials for validity. If I have a potential leak of an AWS key or an access key, it can tell me whether those are valid. It makes a lot of difference.

We've integrated GitGuardian into multiple notification channels for redundancy. For example, I am generally on Slack, and we get a Slack message from a webhook we've set up for GitGuardian. It will tell me precisely what the credential is and where it was leaked. 

When I click on it, it takes me directly to the finding within the platform. I can see the validity and history of the leak. Sometimes, developers leave it in their commit history but haven't pushed code to the remote for a long time. It will be embedded in the commit history. Maybe they've removed it so that it wouldn't be readily detectable at that point. At the same time, the validity of the secret determines our next steps for remediation. It could be used for developer education, or we may need to shift the team into incident response mode and resolve the issue as soon as possible.

I'm interested in their new product features. Honeytokens are something we deployed when it was an open source project. Now that is integrated into the platform. It's in beta right now, and they're branching out into additional vulnerabilities. 

We've used GitGuardian for more than a year.

I haven't had any problems with GitGuardian. 

We're throwing a lot at GitGuardian. A monorepo with around 50 developers and three and a half years of development in it is no small feat for it to handle. It handles the task wonderfully.

I rate GitGuardian's support a nine out of ten. I've called them a few times, and they resolved all my issues in one working day. They do everything they can. Support engineers are responsive, knowledgeable, present, polite, and helpful. 

However, other solutions have a live chat feature that provides instant results. Waiting for an agent to reply to an email is less ideal than an instant conversation with a support employee. That's a complaint so minor I almost hesitate to mention it.

Positive

We were trying various open source solutions when we bought GitGuardian. There was maybe one other well-regarded commercial option, but it was technically incompatible. 

GitGuardian doesn't require much preparation other than setting up a GitLab credential. I would like to have some integration that enabled us to provision users automatically ahead of time. We use SAML, so developers are able to SSO into the tool but can't link the developer to an incident if they don't already have access to the platform.

It doesn't require much maintenance. Sometimes, we have reports that have been deprecated and are no longer valid. I will go and remove them. Otherwise, it doesn't require any consistent maintenance.

The main return on investment is reduced time spent investigating historical credential leaks. That was a large upfront return that we saw immediately after allowing GitGuardian to scan our repositories. We hook it up, let it do its thing, and stay out of the way until something bad happens. I don't have to spend time messing with CI/CD pipeline or onboarding new repos and developers. Everything happens natively within the platform.

The pricing is reasonable. GitGuardian is one of the most recent security tools we've adopted. When it came time to renew it, there was no doubt about it. It is licensed per developer, so it scales nicely with the number of repositories that we have. We can create new repositories and break up work. It isn't scaling based on the amount of data it's consuming. 

We deployed a few open source solutions into our CI/CD pipelines, but we were underwhelmed with the results. Ultimately, we selected GitGuardian for its accuracy and collaborative features. We also like the built-in validity checks and all the other options we didn't have when we were deploying tools directly into our CI/CD. It's a night-and-day difference between the pain of dealing with an open source solution and the joy of dealing with a full-fledged operational platform like GitGuardian.

I rate GitGuardian Internal Monitoring a ten out of ten. GitGuardian is my favorite security tool. It is a joy to use and so effective. I highly recommend trying GitGuardian. It's easy to set up and provides extremely accurate results. If I could only pick one tool for application security, this would be it.

The biggest lesson I've learned using GitGuardian is just how many credentials make it into source control. It is much more frequent than I would've ever believed. 

I'm not immune as a developer. I've accidentally committed credentials and tried to remove them with limited success. GitGuardian is a platform that pushes the envelope on detection and response. It has become one of the cornerstones of any application security program.

The main goal is to be alerted and to react when a secret has been leaked in our code base.

We have GitGuardian linked to our code-based storage on GitHub. GitGuardian also has a notification integration with Slack which is what we use internally for communication. We are alerted on Slack, "There's an incident here on GitGuardian for a secret leak on GitHub." From there, we can go into incidents and start managing the incident.

Before this solution, we didn't have anything for secret detection. We went from zero to having something. We really needed it. It was really a big risk for us without it. The more the company grows, and the more we have employees coming and leaving, the risk of secrets leaks in our asset base is really big. Thanks to the tool, we have decreased the risk.

Before, what we did was check the code manually to detect secrets. Now, it's automated, and that's a big change for us. Security team productivity has also increased because it helps us manage incidents. Everything that GitGuardian does is something we don't have to do manually. That is definitely increasing our productivity.

It also supports a shift-left strategy.

Dev in the loop is pretty good when it comes to collaboration between developers and security teams. The fact that GitGuardian is very fast in detecting and alerting makes remediation easier. When a secret leaks, we get the alert within 30 seconds, or a maximum of one minute, which is very fast. Once we get the alert, we can warn the developer and it will not require a big change because they would have just committed the secret. It won't be a secret that was committed multiple days before. The few times we used it, it definitely made remediation faster.

The detection feature works really well. It's pretty fast and we are alerted very well.

Also, the breadth of the solution detection capabilities is pretty good. They have good categories and a lot of different types of secrets. There is one generic type when they don't know specifically what it is, but it gives us a great range when it comes to types of secrets, and that's good for us.

The detection accuracy is also good. We haven't had a lot of false positives, which is nice. We are not aware of any false negatives, such as not being alerted when a real secret has leaked.

The web interface helps to quickly prioritize remediation as you can manage incidents. You have to indicate the severity of an incident after seeing the secret, knowing where it is used. We definitely use this feature.

The good thing about GitGuardian is that we don't get many false positives. The issue with this kind of tool is that it detects secrets but it can also detect some things that are not secrets, and you have to manage an incident for something that is not an incident. But we tested multiple secret detection tools and GitGuardian was pretty good, not having many false positives.

There is also something we shared with them already about user management with teams. They have an integration with Okta to manage our employees' access to the tools. It would be best to have different teams. In our engineering department we have a lot of different teams, and the more we grow the more teams we will have. But currently, you can only assign one person to an incident. We would like to have the ability to assign it to a team because code, in our company, is owned by a team and not one person. That's one feature that's really lacking in GitGuardian.

I have been using GitGuardian Internal Monitoring for about 10 months.

We haven't had any issue with its reliability. It has always worked and we have never had downtime with GitGuardian. It's very good.

The scalability is definitely not bad, but it's not the biggest strength, for sure. But it's not a "no-go, definitely do not use this tool."

There are some features that are lacking in GitGuardian. The more we grow and the more engineers we have, the more difficult it will become to assign an incident because the assignment is not automatic. I know they are working on that and we are waiting for it.

We currently have 52 members using it. It checks our entire developer worker base. We're satisfied with the current usage, but we'll increase the number of members as we grow.

There have only been rare cases where they didn't answer all my questions. Some things were not possible, but they are very responsive and try to do their best to answer my concerns.

Positive

We didn't have a previous solution.

I don't remember that there was a lot of preparation involved. It was really just a matter of doing the integration between GitGuardian, GitHub, and Slack. That's all. The implementation of GitGuardian is really easy. You just have to set up the integration, which takes, maybe, five minutes, maximum.

There is no maintenance. We have to manage incidents, but that's the point of the tool. But we don't have to maintain the tool itself. It's SaaS and it works on its own.

We checked Gitleaks, which is a free tool for detecting secrets. Detections were pretty much the same in both GitGuardian and Gitleaks. The main difference was that with Gitleaks, you don't have the interface for incident management. It's really just detection. GitGuardian was the whole environment that we really needed to work at scale.

The tool itself mainly helps us with detection. The whole remediation is done outside of the tool. Once GitGuardian has detected a secret leak, we are alerted and an incident is created in the tool itself. After that, the revocation or rotation of the secret will be done outside of the tool. We use GitGuardian to track the incident and the comments on it, but we don't really manage the secrets directly in it.

We had some issues with the Dev in the loop feature, so we don't use it that much. Dev in the loop is used to share an incident with the developer who committed the secret. But to manage our database in our GitHub organization, we let our developers use their personal emails. Because an email is sent to that address about a secret leak, we are not very fond of it. It works well and is helpful because we don't have to manually send a message to the developer for an incident. We can let the developer manage the whole thing on their own, which is good. We just have this email issue, but other than that, the feature in itself works well.

If a security colleague at another company were to say to me that secrets detection is not a priority, I would disagree. The risk is pretty big when you think about what a secrets leak could do. You don't need to start with a solution like this when your company has, say, five people. But at a certain point, you definitely have to have a secrets detection tool.

We use GitGuardian to detect secrets in our source code. Two security engineers use GitGuardian, and developers access it when they commit issues. We've had four developers who have accidentally committed something. We are currently using it extensively and plan to scale it to every new repository we add.

GitGuardian makes us more confident that our sensitive secrets aren't being leaked. I estimate our secret-detection rate is around three times as accurate as what we got with the previous open-source tool. In the past, we had to manually add regular expressions, etc. The other valuable thing is that it scans all Git history, so we can find old commits that might have sensitive information in them.

GitGuardian has probably increased the security team's productivity tenfold. It's hard to quantify. Using after-the-fact detection as an example, we didn't know about information in our Git history until we came across it. We went from nothing to an excellent solution for finding secrets in our Git history. It's also completely shifted the burden from our team to the development teams in terms of what to do when these issues arise again.

It's equivalent to a security engineer reviewing every pool request to look for secrets. We have dozens and dozens of pool requests and commits daily, and GitGuardian performs a security review of each commit. We couldn't scale by having one person perform all that work. GitGuardian saves the security team about four to six hours per incident.

It supported our shift-left strategy by reducing our overall operational burden. The developer receives a GitGuardian alert, and they're often aware of it and addressing the issue by the time I'm triaging it. 

I like that GitGuardian automatically notifies the developer who committed the change. The security team doesn't need to act as the intermediary and tell the developer there is an alert. The alert goes directly to the developer.

We haven't seen any false positives. I've been happy with the range of detected secrets, including SSH Keys, GCP, and Slack secrets. It comes with suggested remediation steps. It's handy because you're not left scratching your head trying to figure out what to do. The alert comes seconds after the commit or maybe a few minutes later, and the action you need to take is explicit.

It would be nice if they supported detecting PII or had some kind of data loss prevention feature.

I have used GitGuardian for nearly two years.

GitGuardian seems solid. I haven't noticed any issues.

GitGuardian is scalable. We've had multiple repositories come online since we started using it, and it handles them seamlessly.

I haven't had to work with support very much, but that is a positive sign that I haven't run into any issues. I don't think I've ever had to file a support ticket. 

We previously used an open-source tool called Bandit. It wasn't very good or automated like GitGuardian. We also used another tool for data loss prevention and detection in GitHub. That provided some overlapping features but wasn't as robust as the secret detection in GitGuardian.

Setting up GitGuardian is easy. I don't even remember setting it up. It was a simple "next, next, finish" installer. It was also easy to remove certain repositories from being scanned.

GitGuardian has significantly reduced the labor hours required to check codes for secrets. A leaked API credential can cost several thousand dollars in less than 24 hours.

The cost of the license is worth it. There aren't any additional costs. 

I rate GitGuardian Internal Monitoring a ten out of ten. Secrets are the keys to the castle. Once somebody has the password to a system, they can access it. I suggest trying GitGuarding on a public repository to see how easy it is to set up. GitGuardian has opened my eyes to how often these mistakes happen and how sensitive data can end up in your source control.

We use it for detecting secrets in our code repositories.

Transferring code from another platform to GitGuardian enabled us to see open passwords in old repositories and enabled us to clean them well and create a barrier against security leaks.

It has also increased our secrets detection rate by 99 percent.

It has also helped to increase our security team's productivity. We have around 110 repositories and if we had to remove something one-by-one it would be very hard, but with this solution we can do so from all of them at the same time, which saves us months—not even days—but months.

Similarly, our mean time to remediation has gone from months to days.

The most valuable feature is the one that validates the secrets.

The accuracy of the solution is around 90 percent, which is a great rate.

If someone steals and posts your repository, GitGuardian tells you that there's a duplicate repository out there. It warns you to have a look at that. It also warns you about similar repositories. If you have five similar repos, it will warn you to check on them. 

You can also assign tasks to specific teams or people to complete, such as assigning something to the "blue team" or saying that this person needs to do this, and that person needs to do that. That is a great feature because you can actually manage your team internally in GitGuardian.

There are also a lot of integrations. 

Another useful feature is that GitGuardian sends us warning emails if anything goes wrong. 

And you can filter on severity levels. That is helpful because you can choose what to look at based on if it's something critical. You can also filter on whether it's a test environment or a production environment. You can indicate that this script needs to be revoked and this one shouldn't be revoked so don't show it as a password.

It also warns you that it's dangerous to use certain things in the code because you have used them in 10 repositories. 

And when it comes to CI/CD, where the code is built and sent to the area where it needs to be deployed, GitGuardian checks if anything is abnormal during the send, and if it is, the code won't be deployed. It then tells you to fix this issue by assigning a task to people in your team.

An area for improvement is the front end for incidents. The user experience in this area could be much better.

We did the free trial of GitGuardian Internal Monitoring first, and then we went to the Business version. We've been using it since February of 2022, so it has been about six months.

Our DevOps personnel use the solution as admins, and our developer team is using it as members. We have eight people using it at the moment, but we're planning to grow that to 10 to 15 people in the near future.

We haven't had any issues with their support.

We were using a platform called Beanstalk. It was our own platform but it was not cloud, so there were some repositories that we weren't monitoring. With GitGuardian actions, we were able to take all repos to the cloud, which is better.

We also weren't able to see the coding history before, such as who left a password in the code. With GitGuardian, you can see everything in the history. You can clean things well when you are able to see the historical changes in the code.

We also tried open-source tools, but the false positives made them a waste of time.

We didn't really need to do anything to prepare to start using GitGuardian. It was really easy.

In terms of maintenance, the only thing that took time, about a month, was the CI/CD part, to integrate it with a pipeline.

Everything is included in the Business version, so there are no extra costs. You can't take some parts out and add other parts in and change the price.

In response to a security colleague who said that secrets detection is not a priority, I would ask what service they are using and what the pros and cons are of that service. And I would also tell them to compare their service with GitGuardian.

Secrets detection is very important to security.

The biggest lesson we have used from using GitGuardian is that we should have started using it earlier.

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. 

The GitGuardian Platform is primarily used for dependency checks within our development process. This allows us to create a catalog of all dependencies used throughout our code repositories.

We've been impressed with the detection capabilities of the GitGuardian Platform. In fact, it's performing very well compared to other solutions we've evaluated that meet FDA compliance standards. To this end, we're currently in the midst of a trial period with GitGuardian to further assess its effectiveness for our needs.

While GitGuardian is a powerful solution, it's important to consider false positives. Some tools overwhelm users with alerts for unimportant issues, creating a flood of low-severity incidents. This can lead to alert fatigue and make it harder to identify critical problems. In my experience, GitGuardian strikes a good balance between accuracy and false positives, earning it a rating of eight out of ten.

GitGuardian significantly improves our ability to prioritize remediation efforts. Previously, without automatic detection, incidents could take anywhere from one day to a month to fix after being discovered manually. Now, thanks to GitGuardian's alert system, we're notified of new incidents immediately, allowing us to address them quickly – typically within a couple of hours. This ensures that the most critical issues are prioritized and resolved swiftly.

It integrates well with our shift-left strategy. This means it identifies and addresses security vulnerabilities early in the development process, before they can impact our production environment. A good security solution shouldn't disrupt production. If implementing GitGuardian had caused any issues in production, it wouldn't be a suitable choice for our needs.

The use of GitGuardian impacted our developers' and security team's ability to work together on resolving security issues. Our current system routes all new incident alerts directly to both teams. Ideally, upon identifying a clear security issue, we would engage with developers to collaboratively determine the appropriate solution and prioritize based on both severity and urgency.

GitGuardian has helped increase our secrets detection rate.

GitGuardian has significantly boosted our security team's productivity. We've transitioned from manual secret scanning in our repositories to an automated system, making automation the key improvement. This shift has saved the security team valuable time, reducing the time spent per incident by a couple of hours.

The only preparation we had to do to start using GitGuardian was to integrate it into our GitHub account.

In application development security, detecting secrets is one of the most crucial practices. A single exposed secret can inflict enormous damage on a company.

The most valuable feature is its ability to automate both downloading the repository and generating a Software Bill of Materials directly from it. This allows us to efficiently obtain the complete SBOM, including all dependencies, for either a new repository or a previously selected one.

One of our current challenges is that the GitGuardian platform identifies encrypted secrets and statements as sensitive information even though they're secured. This leads to unnecessary incidents being flagged, causing problems for our workflow. To address this, a context-based secret scanning feature would be a valuable improvement. This functionality would allow the platform to understand the context of the data before flagging it as a secret, reducing the number of false positives.

I have been using the GitGuardian Platform for six months.

I would rate the stability of the GitGuardian Platform ten out of ten.

GitGuardian meets our scaling needs.

I'm impressed with the technical support team. We have bi-weekly meetings where we discuss any issues, and whenever I need something, I've received a response within a few hours.

The customer success team is another group I truly value meeting with. Their focus aligns directly with the challenges we face. They are incredibly responsive, and if we ever need clarification on anything, they get back to us within a couple of days. Additionally, the onboarding documentation on their website, along with the videos they produce on YouTube, are more than sufficient for getting developers up to speed.

Positive

In addition to GitGuardian Platform, we are also evaluating GitHub Dependabot and Snyk. One of the key features that impressed us with GitGuardian Platform is its ability to automatically create incidents for security vulnerabilities. This is particularly helpful because it allows us to prioritize these incidents based on their CVSS score, ensuring we address the most critical issues first.

I would rate the GitGuardian Platform nine out of ten.

Our GitGuardian users are developers.

No maintenance is required from our end.

I recommend GitGuardian because the setup is easy.

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.