GitGuardian Platform Reviews

We work for a research institute and there are a lot of disparate security practices. A lot of people work for us for short periods of time, through internships and other temporary positions, and it's been hard to communicate security best practices across the company. GitGuardian helps prevent the leaking of secrets, but it's also for educating our company about our policies.

The main benefit is that, previously, secrets would be leaked and nobody would ever hear about it. Now, we actually have alerts and the opportunity to follow up with researchers to deal with these problems. It has provided the opportunity to collaborate on remediation rather than not knowing there are issues.

In addition, we do a review of security alerts when we open-source software. We used to have a script that we wrote that we would run to scan these repositories. It would produce a lot of noise. Now, we go to GitGuardian and immediately we have a dashboard that tells us what vulnerabilities there are.

GitGuardian has helped to modestly increase security team productivity whenever we do a review of open-source software for security leaks. Previously, that would take about an hour per repository and now it takes five minutes. We have 1,500 repositories, which is a lot. We're open-sourcing them weekly, so it doesn't amount to a huge number of hours, but it's turned something from fairly inconvenient, that had the potential to take an hour out of someone's day, to something that's just quick, easy, minimal, and more effective.

It has also helped to decrease false positives.

The most valuable feature is the alerts when secrets are leaked and we can look at particular repositories to see if there are any outstanding problems. In addition, the solution's detection capabilities seem very broad. We have no concerns there.

In terms of the accuracy of detection and the solution's false positive rate, we had to make some adjustments, but now that we've made those adjustments we're very happy with where we are.

We have also used the dev in the loop feature and it works well when it comes to remediating an incident. For collaboration between developers and security teams it's very good.

We have been somewhat confused by the dashboard at times.

We've been using GitGuardian Internal Monitoring for about a year.

I have no concerns about its stability at all.

We also have no concerns about its scalability. Maybe we'll hit something, but I've seen no evidence of scalability issues.

We're using it for about one-third of our organization. We'd like to use it for more.

We've always gotten quick, thorough responses from their technical support.

Positive

We did not have a previous solution.

It was very easy to get started. There was an amazing trial where they showed us vulnerabilities we already had.

It requires no maintenance on our side.

It's not cheap, but it's not crazy expensive either. We negotiate a price and it stays at that price, which is very nice.

We did evaluate other products over a fairly long period of time, but GitGuardian stood out in that it was something we would pay for and we wouldn't have to worry about it. It would just work.

I would tell a security colleague who says that secrets detection is not a priority that it might be worth trying this tool out and seeing what it shows you before jumping to that conclusion.

The importance of secrets detection to a security program for application development is tough to determine because the biggest players already detect secrets on GitHub and disable those tokens. If I pretend those don't exist, then it's extremely important. Since they do exist, it's somewhat important.

Try out GitGuardian Internal Monitoring. It's easy to try it out and you can go from there.

We use it to detect if our engineers are leaking secrets on public GitHub repositories. If any Payfit employee is leaking secrets in their own repositories or, in the Payfit repositories, they will be flagged by either the GitGuardian internal solution or the public one.

Overall, it has given us more trust in our engineers and in our global security. We know that if someone is leaking something critical or a secret, it will be detected pretty fast by GitGuardian and we will be alerted in minutes. It has helped us be more relaxed about those situations.

Its false positive rate is also really low. With the Public Monitoring solution, we have not had any false positives. With the Internal Monitoring solution, we have had a few, but that has been completely manageable. We can see them directly when checking the dashboard. It has definitely helped decrease false positives. In fact, GitGuardian helped us to be much more accurate because we used to use a tool we had built internally but it did not work very well. So we decided to go with GitGuardian and the accuracy is very nice.

In addition, it has definitely helped increase our secrets detection rate. Before we used this solution, we were doing manual research and that was not very effective. GitGuardian has increased our detection rate by a factor of 10 at least. And our mean time to remediation has been decreased because we are warned pretty fast when there is a leak.

It's also nice because it finds personal secrets of our developers. We have had a few situations where we detected a secret that was leaked in a personal repository of one of our engineers. The secret was not one from our company, it was the employee's. We warned them about this and they were pretty happy.

One thing I really like about it is the fact that we can add search words or specific payloads inside the tool, and GitGuardian will look into GitHub and alert us if any of these words is found in a repository. For example, if I put "Payfit" in the tool, I will be alerted every time someone is committing with that word in the code. It's really useful for internal domain names, to detect if someone is leaking internal code. With this capability in the tool, we have good surveillance over our potential blind spots.

It can detect a leak in 10 minutes. We had an experience with one of our engineers who had leaked a secret, and 10 minutes afterward we had a warning from GitGuardian about the leak. It's very effective. We looked at the commit date and the current date with hours and minutes and we could see that the commit had been made 10 minutes ago. As a result, we are sure it is pretty fast.

Another feature, one that helps prioritize remediation, is that you can filter the findings by criticality. That definitely helps us to prioritize which secrets we should rotate and delete.

I would like to see improvement in some of the user interface features. Some things are not that easy to use. The most impactful is the occurrences feature. When one secret is leaked in multiple files or multiple repositories, it will appear on the dashboard. But when you click on that secret, all the occurrences will appear on the page. It would be better to have one secret per occurrence, directly, so that we don't have to click to get to the list of all the occurrences.

I have been using GitGuardian Public Monitoring for about eight months.

The stability is pretty good. We have not had any outages.

The scalability is nice because their infrastructure is pretty powerful. They are able to monitor all our repositories and, with all the GitHub repositories they have to monitor for all their customers, it's working really fast and well.

We have 130 people using the solution, mostly engineers, but there are some project managers who use it as well.

We had regular contact with their technical support for onboarding meetings and the like. They were very helpful. They asked us for our feedback a lot and asked if we had any ideas for improving the tool. And they have provided features for us based on our feedback.

Positive

Our ROI is in the fact that we have detected a lot of secrets that were publically leaked, as well as secrets in our repositories that were not in the vault.

It's a bit expensive, but it works well. You get what you pay for. You get something that is fully managed with a lot of features, and a tool that is very efficient.

We looked at other options. We looked at open-source solutions such as TruffleHog and Gitleaks, but they were not as effective as GitGuardian and they did not have any alerting feature, which was very important for us.

My advice would be to compare this solution with open-source solutions. If you're not convinced about GitGuardian, benchmark it with other tools. Open-source tools are nice because most of the time they're free, if you don't take the support. But if you compare GitGuardian with other solutions, you will see that the efficiency is really not the same.

If a colleague in security said to me that secrets detection is not a priority, I would say that's a mistake. Most of the big security problems come from either social engineering attacks or credential stuffing. So it's really important to know that your engineers and your employees are going to leak secrets. That's life. Most of the time, it's due to mistakes. But if it happens, we need to act on it, and a solution such as GitGuardian is a really nice way to monitor and really efficiently detect these leaks.

Secrets detection is important to a security program for application development, especially if your company is growing and you have a lot of engineers. The more engineers there are, the more there is potential for leaks to happen.

There is no maintenance of the solution on our side, except for putting the GitHub API token inside Gitguardian so that it has access to our repositories to detect potential secrets.

We use the solution to detect any secret exposure.

The overall breadth of the solution is good. It's been able to detect most of the secrets that we have.

The accuracy of the solution is generally good, but we have had a number of false positives. For example, sometimes we would commit a test secret, and it would not follow the action of a secret. This is because the secret contained a prefix that is commonly used in passwords, such as "password". We have been able to take action to suppress these false positives moving forward.

The solution helps to quickly prioritize remediation. When we go back to the historical scan, it can tell us not only what vulnerabilities were exposed, but also the general risk level of each vulnerability. This allows us to prioritize remediation efforts and focus on the more critical vulnerabilities first.

The solution helped to decrease the overall false positive rate. We have been able to decrease the number of false positives by about seven percent. When we receive alerts now, they are usually general alerts. We do not receive alerts that are specific to a door without the pull being put in place when we investigate.

The solution increased our secret detection rate by around 80 percent.

We detected a security issue, and we were able to fix it in the system within half a day. This was possible because we reduced the number of follow-up steps required. The solution saved our security team about 25 percent of their time. This means that we probably removed about a week's worth of incident management work. This is a significant improvement in security, and it saved our team a lot of time.

The solution also helped reduce our mean time to remediation.

At the start, historical scanning was very useful because it was the first time we had done it. It allowed us to see how many secrets we had exposed. If we had only focused on current secrets, we would have missed all the secrets that had been committed in the past. So, initially, the historical scan was really useful.

Presently, we find the pre-commit hooks more useful. These hooks allow us to set up a local development environment where we can scan for secrets before we commit them to the repository. This saved us a lot of time.

It took us a while to get new patterns introduced into the pattern reporting process. If there is a way to automate this process so that we can include our own patterns in our repositories, that would be very useful.

The authentication process could be improved. A single sign-on system would be very helpful.

I have been using GitGuardian Internal Monitoring for one and a half years.

The solution is stable.

The solution is scalable, so we can create instances for each scan that we run. This means that we will never have any issues with load or performance. We have 100 end users the utilize the solution.

The technical support has been very helpful. The system is also pretty intuitive, so we haven't had to contact them very often.

Positive

We have seen a 10 percent return on investment. Resource-wise, creating a secret once it has been detected is a significant undertaking. Early detection has saved a lot of time, and I think there would be various penalties. Theoretically, if we continued to explore secrets, we could also save and compromise.

I compared the solution to a couple of other solutions, and I think it is very competitively priced.

I give GitGuardian Internal Monitoring a seven out of ten. The solution is really good, but the false positives that we had to work with lower the solution's overall score.

When we first started using the solution, we had to address some areas quickly. We had pushed through some public-facing features because we wanted to start working in the open. However, this prompted us to realize that we weren't quite ready to do that. So we had to make all of our clusters private again, or as private as possible. The thought of working in the open had to be reviewed at the start.

The solution does not require maintenance. It is used extensively and is part of our security check pipeline. It is included as part of the pipeline in any repository that is created. It is also included in the repository itself. Each project is included as a pre-commit process. Additionally, it is included in our deployment pipeline because it is well integrated into our productivity tools. 

Secret detection is a very important part of a security program for application development. It gives us the confidence to commit our work to a shared environment, especially if we want to make it public. Secret detection helps to ensure that confidential information is not exposed.

For those using an open-source tool, I would suggest pointing out what sort of support they might need. If they're comfortable using it on their own, then that's fine. But if they need support, it would be helpful to have a support package available.

People should do a proof of concept first because the way it will be configured for them might be different. I don't know if we can figure it out for sales for another organization. So, having a proof of concept to fully understand how it will work best for them is useful.

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

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

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

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

It also supports a shift-left strategy.

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

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

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

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

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

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

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

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

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

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

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

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

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

Positive

We didn't have a previous solution.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I have used GitGuardian for nearly two years.

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

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

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

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

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

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

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

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

We use it for detecting secrets in our code repositories.

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

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

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

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

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

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

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

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

There are also a lot of integrations. 

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

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

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

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

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

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

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

We haven't had any issues with their support.

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

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

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

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

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

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

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

Secrets detection is very important to security.

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

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