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 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 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.

In general, we use Gitguardian as a safety net. We have our internal tools for validating that there is no sensitive data in there. GitGuardian is a more general and robust solution to double-check our work and make sure that if we are committing something, it only contains development IDs and not anything that is production-centric or customer-centric.

The main way in which we're using it at the moment is that it is connected through the GitHub integration. It is deployed through our code review process. When pull requests are created they connect with GitGuardian, which runs the scan before there is a review by one of our senior devs. That means we can see if there are any potential risk items before the code goes into the main branch.

It automates tasks and allows more individuals at the company to handle remediation. It provides visibility for the pull requests. It is integrated into our code review and deployment processes, and that integration allows the author to address an issue almost immediately, rather than waiting for a time-consuming review, and then manually asking the author to address it. It provides a nice safety mechanism, giving us some assurance that if something got forgotten along the way, we are notified before we make it a part of our codebase. It is much harder to remove something after it is merged than to do so beforehand.

It helps in quickly prioritizing remediation. We have set up GitHub and our pull requests in a way that there are numerous checks that have to be passed. The code that is submitted can't be brought into the codebase until anything flagged is addressed as a test credential, a false positive, or the original branch is corrected. Fortunately, so far, they've all been false positives or test credentials. But it puts a stopping point in the process before it can go live with that information in there.

What is particularly helpful is that having GitGuardian show that the code failed a check enables us to automatically pass the resolution to the author. We don't have to rely on the reviewer to assign it back to him or her. Letting the authors solve their own problems before they get to the reviewer has significantly improved visibility and reduced the remediation time from multiple days to minutes or hours. Given how time-consuming code reviews can be, it saves some of our more scarce resources.

GitGuardian has also helped in bringing the responsibility of remediation to the entire team. Rather than having remediation as a part of the review process, where some of the more senior and experienced developers bring something up, it allows the whole team to handle that process. In the long run, it will encourage the team to think about those sorts of things before even submitting code, based on the responses they see from GitGuardian. It has increased the productivity of the security team by reducing the load on our small team. It puts the burden onto the entire team rather than the security team. Instead of them requesting remediation manually, it is automated as a part of our deployment process. It is definitely saving us hours per incident.

Time to remediation is now in minutes or hours, whereas it used to take days or weeks previously. That's the biggest improvement. Because it is automated and visible to the author, someone from the security team doesn't have to remind them or recheck it. That means the slowdown in the deployment process has definitely been improved by an order of magnitude. There is easily a 30-hour improvement on time to remediation, which is about an 85 percent improvement.

The Internal Monitoring is clearly the most valuable for us. We don't have a lot of public repositories, meaning the Public Monitoring is nice to have just in case something were to happen. But the Internal Monitoring catches things like IDs or tokens for some of our internal development. For that development, it's fine to have them in source control, but when those things are flagged, it is a nice reminder to the developer to double-check and make sure this is something that's only data and that there is nothing sensitive or production-related in it. In addition to being a good tool, should we have something sensitive in there, it is a nice reminder. Even though one of our senior reviewers double-checks credentials, when the developers submit something and get that warning message, they can proactively address it.

There are a lot of nice tools, in addition to the GitHub integration, to help us as our dev team grows and to give our individual developers more responsibility, instead of just having it completely on the reviewer to validate things.

If something does pop up but perhaps the developer doesn't notice it, you can send a share link to have them review it and confirm things, such as whether it is a false positive or a test credential, and that can be done right through the share link.

The breadth of its detection capabilities is very good. There are a lot of integrations with different products, which is nice. There are some test credentials in our testing environment that are not sensitive, but it has warned us about a lot of those, although I can understand how it would consider them worth flagging. Overall, I've been impressed with what it has found. It has even found old test credentials that we don't need anymore. It has resurfaced them so that we can clean them up.

Its accuracy of detection is pretty good. The only false positives that we've had are mostly related to location, meaning closeness to a couple of the strings we use. We use a lot of unique identifiers that are 32-character-long tokens, so if they are near a word like "credential" or "password," that's the most common false positive. Configuring those as a false positive means they generally don't reoccur unless we have a new ID in there, which is pretty rare. There have been a couple of such instances, but not too many overall, given the size of our code base. At this point, we don't have those false positives because we've identified them. When we started, about 10 to 15 percent of them were false positives in that category, but after we identified them, they went away.

The main thing for me is the customization for some of the healthcare-specific identifiers that we want to validate. There should be some ability, which is coming in the near future, to have custom identifiers. Being in healthcare, we have pretty specific patterns that we need to match for PHI or PII. Having that would add a little bit extra to it.

In addition to the customization, having some kind of linking on the integration would be another improvement. The product itself is very good at grouping the same incident, but if it detected a test credential that didn't have remediation and that same one comes up in a new commit, it can be harder to find the new one. If you have a new instance of an older remediation, making sure that you're seeing the same one can be a little bit tricky. We had that issue more when we first started and hadn't gone through the original list. Now that it is cleaned up, it is less of an issue.

We have been using GitGuardian Public Monitoring for about a month and the Internal Monitoring for about four to six months.

It seems really stable. Searches and integration are fast, and we get a response back almost immediately when making pull requests. From there, it is a matter of using the UI to find things and to send links to people. Everything has been consolidated and we haven't had any issues.

So far, everything seems fast and easy. I know there is the option to build in a lot of rules, but we haven't really had to. We just let it group and do normal things, and then we just address things as they come up. There hasn't been an overabundance of false positives. It is intelligent enough to surface the right information without overwhelming us.

Currently, three people on our security team and 14 people on our dev team use it. The security team is double-checking the incidents that come in, but everyone on the dev team gets the alerts if a warning comes up during one of the pull requests. They can then sign in and address them as needed.

It is being used as part of our deployment process. I don't know how we would increase its usage. When they have the customization, we might increase usage, but that would just be another rule on the same integration.

We haven't had to reach out to tech support at all. I'm optimistic, given their attention to detail on getting the integration set up and how simple it was, that it would be pretty good. But being able to figure everything out on our own has been a good sign.

We did not use any other solution previously. We have some pre-commit hooks that we have written that are customized for some of our own rules, but we haven't had another solution for this type of security credentials detection.

The initial setup was very straightforward. The deployment time was five minutes. It was the easiest integration I've ever done.

We've hooked up other stuff to GitHub before, and it usually involves a few steps. But with GitGuardian, I just generated a token and walked through it. I don't think I even read the documentation. I just found what I wanted to do, made a token, and it connected right up. I wasn't sure if I had done it correctly until I saw it started popping things in there. It was a really easy onboarding process.

Its ease of integration showed the maturity of the product or their focus in getting that process right. GitHub has its own rules and it changes a lot. Seeing how solid GitGuardian was gave us confidence in the solution.

We implemented it on our own. For deployment and maintenance of GitGuardian, we have two people, me and one of the other admins.

We have definitely seen a return on investment. There is value in having the whole team exposed to the secrets. We do manual reviews before things get deployed, and we also run automated tests. But automated tests can take a while to run, while this runs pretty quickly. Having that feedback so that something gets detected before the review starts really saves a lot of time for some of our more senior and busier devs who are doing manual reviews. That time saved gives us ROI. Rather than starting a review and then having to do a new review after the secrets have been addressed, they are now able to ensure that all secrets are addressed before they review something.

Its pricing is very reasonable for what it is. We don't have a huge number of users, but its yearly rate was quite reasonable when compared to other per-seat solutions that we looked at. I'm not aware of any costs in addition to the standard licensing fees.

Having a free plan for a small number of users was really great. If you're a small team, I don't see why you wouldn't want to get started with it.

We looked at a couple of other solutions. GitGuardian seemed to be the most robust. It had different ways to connect and validate the code. We wanted to see it with our code and the pull requests. The ease of connecting the integration was definitely a major positive. We were able to integrate it quickly and easily and see the results right away. It checked off the requirements we had. It also integrated with a lot of different things, and it had a lot of robustness not only around secrets detection but also around how they were handled. 

Seeing how quickly it could produce search results on the public side, and knowing how much is in GitHub that is public, was really impressive. We knew it wasn't going to be a burden on our deployment process or that we would be waiting for it a lot. Once it was hooked up, its speed and accuracy made it a pretty easy decision to get it.

The other solution that was in the running felt like a very new product, and there was a lot more manual customization to get it to be as clear and as well-categorized as GitGuardian. That other solution was a centralized place and more automated than our process was, but it wasn't as well thought out and as well organized as GitGuardian. We got a lot more out-of-the-box with GitGuardian than we would have gotten with the other solution. Given that it is for secrets detection, you have to have confidence in the solution you go with. The other solution not being a robust solution was something of a red flag for us. We wanted something that was very well thought out from the beginning, because of the sensitive nature of what it is doing.

I would advise others to give it a try. It is easy enough to integrate with your process, and you'll see the value right away, with a couple of quick test scenarios. Once you see it in action, it sells itself.

If a colleague at another company said to me that secrets detection is not a priority, I would ask what is more of a priority, and then I would point to a quick Google search with a myriad of issues and data breaches that have happened from leaked secrets. That is pretty easy to find. If leaks are happening, and there is a reasonable plan, or even a free plan for a small number of users, to deal with them, I don't know how much more bang for your buck you can get. I would tell him to consider the small amount that GitGuardian costs and the value and ease of integration that it provides.

Secrets detection is extremely important to a security program for application development, especially on a team of people with various experience levels. Having something automated always improves things. Having that detection on top of any of your manual processes adds an extra layer of safety. Given the ease of integration, it is extremely important and extremely valuable to have that extra layer of protection to warn you if you do forget something.

So far, GitGuardian hasn't detected any true secrets in our code. They were only internal credentials, but it has certainly brought a much-needed discussion about those test credentials. Fortunately, we've been successful at not committing production secrets since we started using this solution.

The biggest lesson that I've learned from using this solution might not be so much from secret detections, per se. It is about the ease of integration and what going the extra mile actually does. It creates a positive experience, and it also helps in creating a lot of faith in the solution, overall. With the onboarding experience being handled very well, it gave me a lot of confidence that this was the right solution. That's a lesson for our own software. It is super important to have that ease of getting started. That can go a lot farther than you might think for the effort it requires in the overall project. I'm sure a lot more resources are spent on the analysis and the tool itself, but don't skimp on the onboarding.

I would rate GitGuardian a nine out of 10. The two areas for improvement are probably the only things that are keeping me from giving it a 10. The major one of those is probably going to be addressed pretty soon. Once we can do some of those custom identifiers or custom rules, it would be a 10.

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. 

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.