GitGuardian Platform Reviews

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 it mostly to look for secrets in our repositories so we can inform the developers not to do that.

The recommendation is always get this out of your code. One of the things that they added over the year was the ability to reach out to the developer directly to get feedback. This helps us know if the developer is aware of it or it is actually not a secret. So, we don't have to break out of the app, then go into Slack and ask.

We consider all secrets in the source code a Priority 1. We expect every developer to remediate them as soon as they are notified. We don't have a ranking of what is important. We consider them all Priority 1, getting them done first.

It definitely gets us to catch these secrets earlier, instead of after they have made it into production.

With the new feedback system, it has definitely improved our lives. When my security team gets alarms and we don't immediately know that it is a false positive because it is in the test directory, we have questions sometimes whether it is a secret. We then need to work with them to find out what this thing can actually do. The security team has the ability to immediately reach out to the developer and get feedback via email in a portal, where the developer can see what we see and put comments on it, which has drastically improved our lives. We are a worldwide company so we have engineers in a dozen countries. Sometimes, the engineer who made the bad commit isn't even awake, so sending a Slack message doesn't get a response. This is more pressing, so it helps us.

Every engineer has to use it. As we grow, obviously more engineers will be using it. We will probably be at about 100 engineers by this time next year. I don't think that they have any other features or things that we would grow into on the internal side. 

The scanning on pull requests has been the most useful feature. When someone checks in code and they are waiting for another engineer to approve that code, they have a tool that scans it for secrets. There are three places where engineers could realize that they are about to do something dangerous: 

1. On their own machine. They have to set up tools on their machine to do that, and a lot of the time, they are not going to do that. 
2. On pull requests before it gets into our main code branch. 
3. Once it is already in our code branches, which is the least optimal place. This is where we can inject a check before it makes it into our main code branch. This is the most valuable spot since we are stopping bad code from making it into production.

The solution has a 90% to 95% accuracy of detection for its false positive rate. The only time that it is not accurate is when we purposely check in fake secrets for unit tests. That is on us. They have the ability for us to fix this by excluding the test directory, and we are just too nervous to do that.

It could be easier. They have a CLI tool that engineers can run on their laptops, but getting engineers to install the tool is a manual process. I would like to see them have it integrated into one of those developer tools, e.g., VS Code or JetBrains, so developers don't have to think about it. However, it is moving in the right direction.

I would like to see them take their CLI tooling and make first-level plugins for major development platforms so I don't have to write a script to help engineers set up the CLI tool for their own workstations. That could use some improvement. 

When we add new repositories, they don't immediately get a historical scan. Every now and then, when I log into the interface, it is like, "You have five repositories that haven't had a historical scan," and I have to go enable it. That seems weird. It should be automatic.

It is email, so it is out-of-band, which is what we need. It would be cooler if it could be done through Slack or some other means for more urgency. However, it meets our needs. Most of the time, our security team is US-based. A lot of our engineers are in European countries and even places like Australia, so there is a lot of asynchronous work.

This is our second year of using this solution.

It has never gone down, so it seems pretty stable.

Besides clicking the button to say, "Go do historical scans," it takes care of itself once it has been set up. Every now and then, I just happen to be in there, see it, and I push the button. So, there is about a week a year when I get around to doing this action. We almost never need to go into the console, because going into the console is just something you do as a check up to make sure everything is healthy.

We have over 500 repositories. We get detections within seconds of people making those commits. It seems like it can scale to any size that we would need.

We are a very flat organization. Everybody is essentially a software engineer, including our security team. We have about 70 engineers today who are all just building software.

I haven't actually needed to use the technical support. I would assume it is great. Everything that we have done with them so far has been great.

The breadth of the solution’s detection capabilities is the best one out there. I came from a very large Fortune 100 insurance company where we used a couple different products. They were full of false positives and noise, and in my opinion, not that valuable. I have not received a single false positive, which wasn't quickly apparent that it was something like a test credential, since we have been using this product.

We had some internal scanning previously. I don't have really strong metrics of how it was before, but there was always a concern, "Are there things we are missing?" When you use homegrown tools, you don't know. Now, we have about a 20-hour mean time remediation, which is less than a day. That is really good. We have scanned over 20,000 commits in the last month and found 256 secrets that would have made it to production. That is very impactful to me.

We have tried a bunch of open-source solutions, the biggest one being TruffleHog. The main reason for switching was lack of good detection. It pretty much thinks any complex string is a password, so the signal-to-noise ratio was extremely high. That was a huge toil for us, trying to tune it and get rid of all the noise so the engineers could actually work.

It was very painless. We just had to give it access to our GitHub environment, then we immediately got value. The only place where it takes preparation is if you want to move it all the way into a developer's workstation because they need an API key and a binary. They have to configure Git to use it. That is six or seven steps, which is a little toilsome.

There was one requirement. When we set up SSO, the documentation wasn't super clear. We had to go back and forth during implementation to get the right settings so we could single sign-on into it. There were some requirements where we had to get information from their implementation on what we needed to put into Okta and how to configure it. 

We have definitely seen a return on investment when it finds things that are real. We have caught a couple things before they made it to production, and had they made it to production, that would have been dangerous. For example, AWS secrets, if that ever got leaked, would have allowed people full access to our environment. Just catching two or three of those a year is our return on investment. 

It definitely increased our secrets detection rate. My personal opinion is that our custom-built tooling was basically useless, so it has increased our detection rate by 100% because we didn't have metrics prior to it. Our engineers were shocked and surprised at how often they were getting notifications, which tells me that our secrets detection rate has vastly improved.

The solution has helped to increase our security team's productivity. We don't have to spend our time running scans in repositories to see if they contain secrets. Within 10 seconds of a commit, we know whether it contains a secret. 

I would probably spend a couple hours a week just running open-source tools, trying to find secrets and seeing if anything bad was going on. Now, we just get low-priority service tickets, when they get opened, and whomever is on-call deals with those. I have seen a couple a week now and then, but they usually take five to 10 minutes to resolve.

The solution has reduced our mean time to remediation. We are down to less than a day. In the past, without context, knowing who made the commit, or kind of secret it was, sometimes it was taking us a lot longer to determine the impact and what actions needed to be taken. 

I know they do public monitoring, which is a different product, but it is a little expensive and we don't have anything public. So, we probably wouldn't go that way. 

The internal side is cheap per user. It is annual pricing based on the number of users.

It was a trivial cost compared to pretty much any security tool in our organization. It was a no-brainer for me to do. 

It is a trivial cost compared to static code analysis, where we are paying something like $50 a user. I don't know what this is per user, but it is probably less than $10. It provides a lot more value and is just the right thing to do.

We looked at Snyk, GitHub CodeQL that has some secrets detection, and another solution. They either lacked depth or were more expensive.

Read the news. Source code is a huge wealth of knowledge. It also happens to exist on pretty much every developer's workstation, which they probably take home with them. You probably don't want your secrets being all over the country.

Make the detection of a secret a blocking action so you can't deploy until you have resolved it. When we first started, we had it as a non-blocking informative action and were shocked at how many times an engineer just wants to go home on a weekend and pushes the button anyway. Then, you have clean-up and investigative work to do. Make it blocking so they have to do the right thing. One of the things that we have as a motto is, "Our goal is security. Make it easy to do the right thing so you do the right thing and don't try to work around it." If you know this will block, then you will make sure it doesn't happen.

There is a lot of disagreement on what a secret is. For example, Slack has webhook URLs, where when you send a message to it, it will then post it into a company's Slack. A lot of developers have said that because those are publicly available on the Internet, if you find one, you can post to it. That means it is not a secret, but I would disagree, because you can use it for phishing attacks or to confuse the company. They can take bad actions or sometimes start automations. We spend a lot of time discussing whether a finding is a real secret when it probably always is, from my perspective, but we have to convince developers that it is.

Secrets detection as a security program for application development is table stakes. You need to have it.

I would rate GitGuardian Internal Monitoring as 9 out of 10. The CLI needs to be easier. The rest of it is perfect.

We monitor our GitHub repositories for security violations and secrets. We have our organization on github.com for infrastructure as code and our use case is to find security violations as soon as possible. When development uses active tokens or passwords on github.com, we need to immediately escalate things to the right person, so they will be removed.

We started with public monitoring and switched to internal.

We have not tracked whether there has been a decrease in false positives, but GitGuardian has helped us to keep input clean, as much as possible, for infrastructure. 

It also gives us more visibility and helps to create awareness about security in our code.

Another benefit is that the speed of remediation has been significantly improved because we get notification immediately, as issues are detected, very close to the check-in time. We are then able to assign them to the responsible party for correction, according to our SLA.

There are times where it finds issues every two days, but of course, some of them are false positives. But our data for October, 2021 shows a 48 percent decrease in incidents from previous months, and that's a very good sign that development is reading our reports.

GitGuardian also efficiently supports our shift-left strategy. It gives us the ability to provide more information, and earlier, to development. That means when the time comes for releases, the code is clean from a security standpoint.

Using the solution, we have also seen an increase in the secrets-detection rate. We didn't have a previous solution, so in that sense, when we started to use it, the increase was 100 percent. For infrastructure as code, the increase is significant. Compared to the previous year, the dashboard shows it is 73 percent.

The most valuable feature of GitGuardian is that it finds tokens and passwords. That's why we need this tool. It minimizes the possibility of security violations that we cannot find on our own. We need to find out immediately when development breaks the rules.

Issues are detected pretty quickly. The tool, from an administration standpoint, is very easy to support, and it has good audit-log visibility.

The breadth of GitGuardians' detection capabilities is very good. I like it. 

In three years, we have had only one major hiccup, a development bug that was very quickly fixed. 

There is room for improvement in its integration for bug-tracking. It should be more direct. They have invested a lot in user management, but they need to invest in integrations. That is a real lack.

We have used GitGuardian Internal Monitoring for the last three years.

It's very stable. We haven't had any issues.

The scalability is pretty good. Currently, we use it for internal monitoring but I'm looking to extend it to external as well. It depends on budget, but I'm trying to get us to start using it for that in the next few months.

I also plan to start utilizing webhooks for integrations.

We have used their standard technical support once. Our experience with them was good. It was pretty quick and it was during a moment when we had a bad release and we had to do a rollback. They were quick to respond.

Positive

It was a pretty easy, straightforward installation, and we got results immediately.

In terms of maintenance of the solution, because we have an on-premises installation, we have to do upgrades periodically. But the maintenance does not require a lot of time, maybe an hour per month. It's pretty cheap to support. It's very easy to upgrade, and they happen once every couple of months. We are using version 1.29.1. In a reply from one of my administrators about the upgrade, he said it was done during a coffee break.

We have a little under 100 people who use it actively, in our security team and development management.

We have seen ROI because GitGuardian has found some secrets that were checked in as part of the code and it helped us to prevent an area of possible attack on our corporate network and resources. In the same way, it protects our customers. 

It's a little bit expensive.

When you have a large organization, you would like to involve as many of your developers as possible. It's really expensive when you have 600 or 1,000 developers. That will push your price to close to $100,000 a year. So it's not a cheap solution. You have to create the correct interface to keep it in line with your budget.

For us, there are no additional costs beyond the standard licensing fees because we deploy it internally. If we deployed it in the cloud, we would incur infrastructure costs.

We compared GitGuardian to GitHub's features. GitGuardian was chosen because it has superior functionality when it comes to detection.

If a colleague in security at another company were to tell me that secrets detection isn't a priority, I would tell him I highly recommend this product. We have achieved very good results. Secrets detection is one of the top-five priorities in a security program for any development. It defends the company's interests and secrets. There's an old saying, "You cannot trust your developers." You always need to check their work.

The only issue that I can see is that sometimes an organization deploys a tool but does not utilize it as much as it could. That is the impression I have gotten from speaking with my colleagues at different companies.

Overall, I like this tool. We have used it for a few years and I'm very impressed. I'm happy with it as a tool and with the vendor as a company.

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.

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.

We procured it as a secrets and code detection solution. We have code bases, some of which are 10-years-old. We needed a way to comb through all of the Git histories to see if any developers had committed secrets to our code in the past as well as catch any new secrets that developers may accidentally commit in the future.

We are using GitGuardian Internal Monitoring.

Without GitGuardian, we wouldn't be doing real-time detection of secrets. It would be something that we did periodically. Maybe quarterly or semi-annually, we would review our code for secrets. This means that the mean time to detection would be much longer. GitGuardian reduces our mean time to detect substantially. In addition, we would be finding out about secrets much further away from the time that they were introduced into the code base. We would be chasing people down to give us information about things that they did weeks or months ago. This would drastically reduce the effectiveness of us being able to triage and remediate the leaked secrets.

We don't have to do a periodic review to see if there are any secrets in our code bases. I would estimate, if we were to do that on a quarterly basis, we would be spending an entire week per quarter on it that we don't have to spend now. Therefore, it saves us a week every quarter in pure effort.

If we did not have GitGuardian, our mean time to detection would be much longer. We would have a substantial amount of risk that a set of credentials or a secret was being used maliciously. Every quarter, there was a security incident that came from the risk of these credentials living in our code bases. That might be another week worth of effort that our security team would have to deal with. Since we are catching things immediately, that risk is inherent in our environment and we don't have to worry about a security incident happening. The chances are much lower. We take a week of pure effort to review secrets that went away. Then, there is a week of dealing with security incidents that come from the secrets living in our code bases.

The solution efficiently supports our shift-left strategy.

The secrets detection and alerting is the most important feature. We get alerted almost immediately after someone commits a secret. It has been very accurate, allowing us to jump on it right away, then figure out if we have something substantial that has been leaked or whether it is something that we don't have to worry about. This general main feature of the app is great.

Recently, they added a feature that checks the validity of leaked secrets. It will actually reach out and see if the secret that leaked was valid or not. I have found, over the past couple months, this to be a super useful feature. We can go through a lot of the secrets in our code base, which have been detected, and dismiss them if we know that they are invalid secrets that can't be used anyway. This saves us a bunch of time, which is why this has been a really neat feature that has been useful.

I have found that I have been very satisfied with the breadth of the solution's detection capabilities. I don't think it has missed anything. The false positive rate has been very low. Every single time something is detected, it is something that we should look at. It does a very good job of detecting things that we should look at and make a decision on. We don't waste a lot of time chasing down false positives. This means that we feel safe because we don't have valid credentials sitting in our code repositories. If any of our code was breached or any of our developer work stations were compromised or stolen, no one would be able to get valid API credentials out of the Git repositories on those workstations.

The solution helps to quickly prioritize remediation because it allows us to tell which keys are valid versus which ones are invalid. We prioritize the valid ones first. It also lets us sort by detection type, e.g., what kind of secret is it detecting. There are ones that we would obviously prioritize over others, like SSH keys or AWS credentials, versus less sensitive credentials that aren't as concerning. I think it does a great job of helping us prioritize.

GitGuardian provides a feedback form feature that we utilize heavily. When a secret is detected, our process is to generate a feedback form link in GitGuardian, then provide that to the developer. The developer will give us contextual information about the secret, then we can take action. They have also recently released a feature, which we haven't started using yet, called automated playbooks where you can set it up to automatically create that feedback form. Then, it will be emailed to the developer so they get automatically notified that they introduce a secret with a feedback form to fill out. I suspect this will improve our developer's ability to resolve the secrets faster.

Six months ago, I would have said improving the ability to automatically get feedback from a developer so we wouldn't need to take action when reaching out, but that has been addressed.

They could give a developer access to a dashboard for their team's repositories that just shows their repository secrets. I think more could be exposed to developers.

I have been using the solution for 15 months.

I haven't noticed any downtime nor had any issues accessing it. So far, stability and reliability have been excellent.

GitGuardian does not require any maintenance on our side.

So far, I haven't hit any scalability issues at all.

We have three security engineers who are actively using the service. We also have about 80 developers who are indirectly using the service through the feedback forms.

So far, the support has been great. The only issues that we initially had were with the initial SSO integrations, and they were pretty responsive with that. I think the support has been great, though we haven't needed it much.

I would rate them as nine out of 10. They respond to me almost immediately every time that I have a question, which has been great. I haven't experienced any delays or not had an issue solved.

Positive

The solution has increased our secrets-detection rate. Previously, we only detected secrets when someone saw them, which was rare. Especially since a large portion of our secrets are in the Git history, not in the current state of the repository, we were only made aware of 10% of the secrets before. Now, we are probably in the 90 percentile.

There was a ramp up period. When we set it up and linked it up, we had to review all the initial findings and process them. That took a significant amount of time.

We just weren't doing this before we had GitGuardian. It has enabled us to do something that we weren't able to do before. If we were doing it manually, then we might have spent 200 hours doing this manually over the past year. So, we just wouldn't do it if we didn't have something like GitGuardian.

The solution has significantly reduced our mean time to remediation, by three or four months. We wouldn't know about it until we did our quarterly or semi-annual review for secrets and scan for secrets.

We have seen a return on investment. The amount of time that we would have spent manually doing this definitely outpaces the cost of GitGuardian. It is saving us about $35,000 a year, so I would say the ROI is about $20,000 a year.

If you were to run a proof of concept with GitGuardian and see all of the things that it detects, then you would probably be very surprised. You can tell very quickly what the return on investment will be and how much risk a tool like this can mitigate.

We evaluated TruffleHog, but we liked GitGuardian better.

My advice would be to talk with them about your needs. There are different use cases between security personnel working with GitGuardian versus developer personnel working with GitGuardian.

Secrets being used to access resources is probably one of the most common ways to be involved in a high profile breach these days. If you are not detecting secrets in code, then every developer's machine is a security breach waiting to happen. A developer in your org is going to leave their laptop at a coffee shop one of these days. If they have the code base checked out, and there are valid secrets in that code base, then it is only a matter of time before they get used to accessing resources that they are unauthorized to access. 

This is one of the higher priority things right now because developers are way more likely to commit secrets than I would have ever expected.

We haven't adopted any of the GitGuardian's shield functionalities. We just haven't taken the time to roll that out to all our developers. They have the functionality there, and it works great, but we haven't been able to prioritize the rollout on our end.

Security engineering is using the solution pretty extensively. We are not making use of a lot of the shift-left features. We would like to roll them out over the course of the coming year.

I have been super happy with it. I would rate this solution as nine out of 10. I am just leaving room for building out more features for looping in developers.

We needed a detection tool that would work across all languages and help us identify problem areas. That was especially important where a codebase is made up of several different development languages written over several years (or decades).

GitGuardian efficiently supports a shift-left strategy. As a result, it has made things materially more secure. It's helped us to stop secrets from reaching our codebase.

The platform has helped to facilitate a better security culture within our organization. In addition to highlighting problems, it shows engineers how to properly remove them from the code, and provides advice on rotation.

The Dev in the loop feature has helped us to learn about problems and has helped us get our hands on remediating. We've gone from having very long-lived incidents to having much shorter incidents.

And because we didn't have any solution like this before, of course it has increased our secrets detection rate.

And in terms of security team productivity, using GigGuardian helped us deliver a key, strategic roadmap item for our organization.

The solution offers reliable, actionable secrets detection with a low false-positive rate. That low false-positive rate was one of the reasons we picked it. There are always going to be some, but in reality, it's very low compared to a lot of the other, open source tools that are available.

Accurate secrets detection is notoriously challenging. GitGuardian provides a rich and easy-to-use interface that enables engineers or security teams to jump on issues and manage their remediation. It offers functionality to prevent issues from creeping in.

GitGuardian has pretty broad detection capabilities. It covers all of the types of secrets that we've been interested in. For example, it covers AWS Keys. There isn't anything specific that it couldn't detect in the stack that we use. That breadth is also evident because we have a lot of different languages that it supports as well.

The "detector" concept, which identifies particular categories or types of secrets, allows an organization to tweak and tailor the configuration for things that are specific to its environment. This is highly useful if you're particularly worried about a certain type of secret and it can help focus attention, as part of early remediation efforts.

The ability to check for secrets as part of pre-push hooks is fantastic, as it helps identify issues before they reach the main codebase, and that was the ultimate goal for us.

Another positive feature is that it quickly prioritizes remediation. That quick feedback loop is very helpful. Based on the detector that finds the problem, you can use that to almost rate the issue. For example, if it's an AWS Key, you would rate it very high so you can jump the prioritization accordingly, once you've got those alerts triggered. And issues can be assigned to individual developers to help gain traction on fixes.

And the Dev in the loop feature, which our developers use, is pretty important when it comes to remediation because that's what helps make the engineer responsible for having done the thing that needs remediation. This feature is effective in terms of helping collaboration between developers and our security team. It's automated, to a large extent. The "in the loop" feature will notify the engineer of what's happened and will give the security team oversight, but it deliberately puts the onus on the engineer to fix it.  

In addition, the out-of-the-box reporting mechanisms allow for easy data presentation to both specific engineering teams and senior leadership.

I've used the solution for one year.

I've had no issues with the stability of the service.

I implemented it on a very large codebase, with no scalability concerns. The SaaS offering made the integration simple.

GitGuardian's technical support is very good. They are very proactive and keen about any feedback on the detectors.

Positive

I've previously implemented open source alternatives. These proved cumbersome, unscalable, and with such large false-positive rates as to make the output useless.

There wasn't much preparation needed on our side to start using GitGuardian. There was just the standard opt-in to integration and we then used OKTA to manage SSO and set up integrations with GitHub. It is pretty easy.

There is no maintenance necessary because it's offered as a service.

It was a pleasure working with their implementation team to integrate it with our source control, and they were available to listen to any feedback we had.

There are cheaper alternatives and competitors, but you get what you pay for. I've tried to implement a number of alternatives in the past, but those solutions have quickly become unmanageable due to their false-positive rates and poor interfaces.

Depending on the number of engineers committing to the codebase, pricing will very likely be a factor in any decision made. However, if you're after a great secrets detection platform, you'd be hard-pressed to beat GitGuardian.

If a colleague in security at another company were to say to me that secrets detection is not a priority, I'd ask them why that's the case. Arguably, secrets in source code are a very large risk, especially given the distributed nature of working at the moment. Secrets detection is pretty core for us, when it comes to application development, because we're spread out in terms of work locations. People may be using different kinds of machines to do their work, and we need to make sure that sensitive data is kept out of our codebase.

GitGuardian is a really good, well-crafted, and polished tool. You get what you pay for. It's one of the more expensive solutions, but it is very good, and the low false positive rate is a really appealing factor. And it has taught us the size of the problem that we are facing, which was something we didn't know before. It's pretty near to perfect.