GitGuardian Platform Reviews

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I've used the solution for one year.

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

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

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

Positive

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We've used GitGuardian for more than a year.

I haven't had any problems with GitGuardian. 

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

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

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

Positive

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

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

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

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

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

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

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

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

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

We are using GitGuardian Internal Monitoring on our GitHub Enterprise repositories to make sure that our developers are not introducing any secrets into the code. Those secrets could be things like database passwords, connection strings, or AWS credentials. We use it when they commit code to our GitHub internal repositories.

We want to make sure that none of our secrets get committed and GitGuardian is doing a great job identifying them. It has the ability to scan our repositories and identify older commits that have secrets, meaning in code that was committed even four or five years ago, and that has gone unnoticed until we implemented GitGuardian.

Most of our dev teams have a GitGuardian CLI installed on their local machines. Even before a commit gets to GitHub, the CLI identifies secrets within the code and doesn't allow the commit to go ahead. That drastically reduced the number of secrets being committed.

We use Azure DevOps for our CICD and GitGuardian helps support a shift-left strategy. There is all the pipeline-related code that is checked into the repositories and secrets tend to creep into that code, such as RAML files and environment secrets. GitGuardian helps us identify those secrets when they are committed. Not all our dev teams are using GitGuardian's CLI—we are trying to get them to adopt it 100 percent, but we're not there yet—and there are occasions where someone is testing out a pipeline and, by mistake, they don't declare the secrets properly in the code that is being checked into Azure. We get notified and, immediately, the teams work to remove those secrets.

Historically, in our organization, people have been committing AWS secrets, such as access IDs and secret code into our GitHub repositories, because they were testing out something. It could be that they were doing a PoC, and not implementing a full-blown secrets manager where they store and pull the secrets from. After implementing GitGuardian, we were notified of these secrets immediately. And even though they were doing PoCs, we were able to get them revoked immediately, which means removing the secrets from AWS as well as the code and issuing new secrets.

We were also able to help the teams to use AWS Secrets Manager or the Vault to store their secrets. GitGuardian actually provides sample code snippets, which are pretty decent, for pulling secrets from AWS Secrets Manager or Vault.

In addition, the solution has increased our secrets detection rate by almost 100 percent. Pretty much any secret that gets committed is identified and the team is notified. We have almost 100 percent coverage and that is pretty robust.

When it comes to our security team's productivity, because our processes are being monitored by GitGuardian, we don't have to run any scripts or scans or out-of-the-box solutions. We don't worry about secrets being leaked or introduced into our repositories. We rely on the product to keep us aware of our secrets management in our repositories and that enables our security team to focus on other security-related tasks. They don't have to spend a lot of time worrying about how to detect issues and, instead, depend on GitGuardian. They have confidence in the ability of the product to identify the types of secrets that our people are committing. They are definitely being flagged.

Now, we may be spending a couple of hours and a week addressing incidents that come up or addressing the old ones that are still being tracked for remediation. We had around 500 secrets management incidents when we fully implemented GitGuardian. We are now down to 20 or 30, which are old but still need remediation. Those old secrets have been revoked, but they are still sitting in our GitHub history. We need to reach out to GitHub support to get those taken out, replace those repositories, and run garbage collection on them.

And because identification of the secrets being introduced is almost instant, the pull request doesn't go through, and Slack alerts are immediately sent out. As a result, the mean time to remediation is within a day, if not even sooner. These secrets are mainly dummy secrets that people are using for testing code. But we don't want even those to be introduced. The idea is to have teams use secrets management services like AWS Secrets Manager or Vault from the get-go. We are close to 90 percent utilization of AWS Secrets Manager or Vault to store secrets because of GitGuardian Internal Monitoring.

We mainly depend on its ability to identify secrets and we also use the entire workflow of secrets management. That means we're able not only to identify secrets, but we can reach out to the owners of those repositories by opening up an incident ticket within GitGuardian. It actually creates an incident ticket for us. We can now go end-to-end after a secret has been identified, to track down who owns the repository and who is responsible for cleaning it up. We can also monitor what actions they are taking, such as revoking the secrets and ultimately closing out an incident, making sure that commit no longer has any secrets.

We tested out the secret identification using thousands of samples and some of them were purely false positives. GitGuardian was able to identify 85 to 90 percent of the false positives. We are fairly confident when we see a secret reported. Of course, we always verify them before we chase down teams to fix them.

We have defined our teams and their members so the teams are typically associated with the repositories on GitHub. Whenever a secret is identified, those team members are immediately notified by GitGuardian via an email and a Slack message, thanks to integration with Slack. In addition, the application security team also gets the information in the Slack message and we can keep track of the remediation efforts.

I would like to see more fine-grained access controls when tickets are assigned for incidents. I would like the ability to provide more controls to the team leads or the product managers so that they can drive what we, the AppSec team, are doing. They should have the ability to close out tickets and we would review them. 

Right now, we cannot give them that control because if they close out a ticket, we won't have the visibility into them unless we build something with the APIs that GitGuardian provides. 

The UI has matured quite a bit since we started using it, and they have introduced new features, such as the teams feature. That was introduced three or four months ago. We put in the requests for such features. There are a few more requests that we think would make the product even better, and one of them is that fine-grained access control so that we have additional roles we can assign to other teams. That would help things to be more of a self-service model.

I have been using GitGuardian Internal Monitoring for almost two years.

Very rarely does GitGuardian go down or the monitoring fail or we have issues with the APIs. It's available 95 percent of the time. There have been a few times when we were notified that the service would be down because of maintenance. Like with any product, there are maintenance windows, which are not a problem. But I don't recall more than one or two instances of the internal monitoring not being available when we expected it to be.

We have a lot of repositories and we have not had a problem with GitGuardian monitoring all of them and doing what it is supposed to do. Deploying it at scale is pretty much seamless. You don't have to do anything special once you have onboarded it. GitGuardian has the ability to scan all the repositories in your GitHub Enterprise account, if that is what you choose to do. 

There are no performance issues. We have around 800 or 900 active repositories and 400 that are archived. We have quite a big code base to cover but there are no additional tasks needed to scale it as your number of repositories increases.

We have contacted their support about a few enhancements. In addition, we came across a couple of UI bugs where the stylesheet didn't render properly and the information we were looking for was overlapped by some other UI elements. But they were very quick fixes. 

We also had some rate-limiting issues with the APIs and they were fixed early on in our engagement.

They are very responsive and have a fairly quick turnaround time. We have developed quite a good rapport, not only with the customer support team but with their support engineers as well. 

Initially, we had calls once a month and now we have calls about once a quarter. They get on a call with us to find out if we have any pain points or new feature requests.

Positive

To start using GitGuardian there is some groundwork that needs to be done. You start off with a few repositories and do a trial to get an understanding of how the UI works. You have to give permissions to GitGuardian to access your internal depositories and then organize the repositories around team structure. Those are the housekeeping tasks that need to be done to onboard with GitGuardian.

Initially, to get the program up and running, we relied on GigGuardian's playbooks quite a bit, and we do refer to them whenever the need arises. When you're starting off with GitGuardian and secrets management, GitGuardian lays out the basics of why it is a bad idea to have your secrets committed to internal or external repositories and the dangers associated with that practice. They outline baby steps to start taking control of secrets being committed. 

They also give you good guidelines on how to use ggshield, which is their CLI product, as well as the web UI, and how to organize your teams and repositories around GitGuardian. 

For AppSec teams, playbooks give you the ability to control what the repository owners are capable of through permissions. For example, you don't want all team members to have permission to repress incidents that are identified. We'd rather have them as collaborators or viewers. They can view the incident and fix it, while the AppSec team can actually suppress the incident and use the functionalities of the management console within GitGuardian. All these features are part of its playbooks. They're a good resource.

The playbooks helped us to understand how the product works and what we needed. They helped my team to implement GitGuardian in the most effective manner, such as how to use the product better to manage workflows.

In terms of maintenance of GitGuardian, there is none required on our side.

We looked at a few other solutions before we started to work with GitGuardian and what we found was that it provides the best solution for secrets management. We have a few other products that we use within our systems, products that also provide secrets management, but they don't come anywhere close to GitGuardian's ability to detect secrets, track them, and ultimately, get rid of them. GitGuardian is the leader in this space. Many times, what we identify in GitGuardian is not identified by those products.

I would tell a security colleague, using an open-source secrets detection solution at another company, to take a good look at GitGuardian. It definitely helps not only manage secrets but also the entire workflow around secrets management, from detection to remediation. It helps put best practices in place. It would save them quite a bit of time, rather than using an open-source solution. Open source is okay for some features, but you don't have all the tools you need for full-blown secrets management in the organization. That's what you get when you use GitGuardian.

Secrets detection is as important, if not more important, to a security program as having a firewall and a vulnerability management program. Your secrets are the easiest way for bad actors to access your environment, without doing any work at all. You need to lock down what type of information is being committed to both your open-source and internal repositories to ensure that no secrets are being committed. And if you have any secrets that were committed in the past, you need to identify them and make sure they are removed and, if possible, reach out to the organization, like GitHub, and work with their support teams to clean up the history as much as possible. Secrets committed in your repositories are keys to your organization's infrastructure.

We have been retraining our teams to not commit even false or dummy secrets into the repository. It's fine for them to do a test but we don't want to have to deal with false positives. Getting distracted by even 10 percent of false positives is not fun. Rebasing the commits is a pain. That retraining, to not use even dummy secrets, has worked for us to reduce the number of secrets being committed.

In addition, we had a number of brown bag sessions with our dev teams over the course of several months, where we would demo what secrets we found on GitHub repositories and how GitGuardian is helping us identify them. The idea was to make them more aware that this tool is monitoring all the repositories and every commit is being scanned. But the goal was to ensure that secrets don't even get to the point of being committed. And when someone mistakenly commits a secret, they immediately inform us. Dev teams are now trained not to do it, but if something happens by mistake, they are immediately on top of it to revoke it themselves and inform us. We have everything recorded on GitGuardian, but proactive action is being taken.

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

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

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

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

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

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

GitGuardian has helped increase our secrets detection rate.

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

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

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

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

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

I have been using the GitGuardian Platform for six months.

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

GitGuardian meets our scaling needs.

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

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

Positive

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

I would rate the GitGuardian Platform nine out of ten.

Our GitGuardian users are developers.

No maintenance is required from our end.

I recommend GitGuardian because the setup is easy.

We use it for 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.

Mainly we use GitGuardian to keep secrets out of our source code. That is something that we wanted to get serious about getting our hands around. This was the main driver because I had tried other tools like TruffleHog. It was cumbersome to manage the unwieldy Git history and to figure out. When you run TruffleHog, you have no way of knowing what's in the current branch versus your Git history. Hence, it's tough to decipher what secrets are still possibly valid.

We didn't have a secret detection tool in place before GitGuardian, so we had no solution that could detect when secrets were committed and sourced. With GitGuardian, we get an instant notification every time a secret is committed, so we can immediately triage it.

GitGuardian has absolutely supported our shift-left strategy. We want all of our security tools to be at the source code level and preferably running immediately upon commit. GitGuardian supports that.

We get a lot of information on every secret that gets committed, so we know the history of a secret. For example, if there are SMTP credentials that get used and reused, we can see where the secret may have traveled, so GitGuardian may give us a little more information about that secret because it can tie together the historical context and tell you where the secret has been used in the past. You can say, "Oh, this might be related to some proof-of-concept work. This could be a low-risk secret because I know it was using some POC work and may not be production secrets." 

I don't know how to quantify how much time it has saved our security team because we didn't have anything similar in place before GitGuardian. I can say that tracking down a secret, getting it migrated out of source code, getting the secret rotated, and cleaning the Git history took much longer from commit until the full resolution before GitGuardian. We weren't notified until it was too late, but with GitGuardian, we know almost instantly. 

We have standard operating procedures for every notification. We know how to rotate the secret. We know how to remove it from the source code. We have documented procedures for how to do that. We can rip it from the code, rotate it, and clean the Git history in a couple of hours. If something gets committed, it sits there for a while before we notice it.

Overall, GitGuardian has also helped us develop a security-minded culture. We're serious about shift-left and getting better about code security. I think a lot of people are getting more mindful about what a secret is. It's like back in the day before campaigns like Cofense PhishMe became a big thing. People were clicking phishing links all the time. Now you have these training programs where people see these things, and they're more aware of it. 

It's a similar situation when you're writing code as well. I think people are getting more aware of secrets. What is a secret? Does this belong in the source code? Sometimes they even come out and ask, "Is this a safe thing to commit to the source?" before they even commit it. They don't want to be "yelled at" by the GitGuardian. I think that it has had a positive impact on the culture itself.

You're only as good as the software you write, and you're in for a world of hurt if you put the keys to the castle inside of that source code that could be somehow reverse-engineered. By separating the two, the source code and the keys, you're one step ahead of that. I think it's essential.

The most valuable thing about GitGuardian is the speed with which it works. If you accidentally commit a private key to a public repo, you need to know that instantly. GitGuardian has this thing called "Dev in the loop." The developer who committed the secret is notified, and they get a form to fill out so they can give us instant feedback, which is super helpful for us. Due to the nature of the software we write, sometimes we get false positives. When that happens, our developers can fill out a form and say, "Hey, this is a false positive. This is part of a test case. You can ignore this." What's more, the tool helps us with triage. As soon as the secret is committed, we receive Slack alerts and jump right on it.

GitGuardian's "Dev in the loop" feature has sped up our time to remediation quite a bit. Of course, not every developer is responding, but that's just the nature of the organization itself. It's not the fault of the product. It's just that some people are not as quick to act. So when developers do respond, I would say issues get resolved several times faster because we know from the jump if it's an issue or not.

It's hard to evaluate how accurate the tool is because of the type of software we write. We're a vulnerability company here, so we write a lot of test cases using test data that are looking for things like secrets, so we have false positives. Some of GitGuardian's detectors take that information into account. With things like a general high-entropy detector, we expect a potentially high false-positive rate. However, for something like an AWS key detector, GitGuardian's efficacy is near a hundred percent, if not 100%. I can't recall any instances off the top of my head where it inaccurately flagged an AWS key or an Azure key.

One improvement that I'd like to see is a cleaner for Splunk logs. It would be nice to have a middle man for anything we send or receive from Splunk forwarders. I'd love to see it get cleaned by GitGuardian or caught to make sure we don't have any secrets getting committed to Splunk logs. That was an issue that I brought up a while ago. However, my workload just hasn't allowed me to sit down and figure out how to solve that. That is one thing that I wanted to see if I can use in that regard because secrets are a thing that ends up in logs, and that's not something we want.

The first time I looked at GitGuardian was about a year ago now. We have open-source information on public GitHub, but all of our proprietary code is on an internal GitHub Enterprise Server. When we set up our internal GitHub Enterprise Server and deployed GitGuardian, it had no network path out to the public GitHub. I worked with GitGuardian, and they set me up with public monitoring. I would monitor all of my public open-source information with the public offering. Then I would also have my internal monitoring setup for everything on our GitHub Enterprise Server.

GitGuardian has been pretty stable probably 99% of the time. There was one time where I had a slight hiccup, so I restarted the cluster, and it was good to go.

I think GitGuardian scales well. It's adequately scaled for what we are using it for right now. I don't see that growing. Right now, we just have it hooked up to our source, and it can handle that. Now, if we were to expand into possibly doing the Splunk use case, that might bring in an API. In that case, I'm not sure what the performance impact would be, but I don't think it would be that bad. You throw a couple of extra nodes out there, and it should be fine. It's currently being used by all of our developers. Everyone who commits code is using it. It scans all of our code.

GitGuardian's support is fantastic. I don't think I could rate them anything less than a 10 out of 10. We had a few questions about how to stand up our deployment. The SRE assigned to our project was readily available and very knowledgeable. He jumped on a call and spent crazy hours helping us out. I thought they were very flexible and easy to work with. I've never had an issue with their support. They've given us everything I've needed when I needed it.

Positive

We installed the software and connected it to our GitHub. Literally within minutes, it was scanning and finding secrets in our GitHub. It doesn't take long to get it up and running and we didn't have to make any significant architectural changes before deploying GitGuardian. We only had to stand up a VM and then set up the network pathways to talk to our GitHub. That was a very minimal amount of work from our CIS ops team to put that out. After installation, it doesn't require much maintenance. When they tell me a new release is out, I log into the console, click the upgrade button, and it does its thing. 

We've absolutely seen ROI. For example, if somebody accidentally commits an AWS key to your public GitHub, somebody can take that key and spin up EC2 instances, which can cost us thousands of dollars. The fact that we can catch it is almost invaluable, but it's worth the investment to have the tool. Everything is cheaper if we can find an issue and resolve it sooner. It's much more affordable to remove a secret well before it gets merged into a master branch than it is to try to rip out the historical commit. It affects the bottom line in that regard.

I think GitGuardian's price isn't too expensive. I'm not sure about any add-ons or additional costs because I wasn't involved in purchasing GitGuardian. I know the ballpark price, but I did not handle the pricing. Other people in our organization negotiated the pricing, but I'm not aware of any hidden costs or anything like that. 

We looked at some open-source solutions like TruffleHog, and we also looked at the GitHub secrets detection, but the issue was that it was bundled with their advanced security, which we were not planning to purchase. GitGuardian just made perfect sense for us.

GitGuardian has the GUI that TruffleHog doesn't have. TruffleHog can scan your GitHub and tell you where secrets live. But it does not do a perfect job of telling you where those secrets live within your timeline. GitGuardian does an excellent job of telling you the branch where those secrets live and where they are on the timeline. The Github tool does pretty much the same thing, but it was off the table for us because we were not planning on purchasing their advanced security toolkit.

I rate GitGuardian 10 out of 10. It does everything that I need it to do, and I'm excited about the new features that are coming along at this point. It has really helped us change our culture, and it's impressive to see that. People are now more mindful of what gets committed to source code. I would recommend GitGuardian. 

We use it for secrets detection.

Before we had GitGuardian we were "blind." We had no detections, which was very bad. We were using another product on GitHub, similar to GitGuardian, but it was not really as good as GitGuardian. The graphical interface and the detail GitGuardian gives you are really amazing. And there are fewer false positives than any other platform. We are able to notify developers of issues on the spot and tell them, "You have exposed a secret." It is absolutely brilliant.

It has definitely helped to efficiently support a shift-left strategy. Before this, we didn't have any detection, and we had a lot of false positives with other products. That meant people were spending and wasting a lot of time on false positives. That is not the case now. GitGuardian has fewer false positives, which is very advantageous. It has decreased our false positives by a minimum of 20 percent. The secrets detection is more accurate. Before, we had 20 false positives for every real incident. Now, we only get the one, real incident.

In terms of developers and our security team collaborating on remediation, GitGuardian has made everyone feel better. Usually, for developers, security is an overhead, but GitGuardian has never been an overhead. It is always helping developers understand where they did something wrong, and the need to fix it. That's what has allowed us to protect the developers and the company assets from security breaches.

The scope of GitGuardian's detection capabilities is better than anything else. When they give you a description of what happened, it's really easy to follow and to retest. And the ability to retest is something that you don't have in other solutions. If a secret was detected, you can retest if it is still there. It will show you if it is in the history.

It also helps to quickly prioritize remediation. They provide a score and, although it depends on the context, because what GitGuardian might say is a high-risk vulnerability might not be for us, it does the job properly. The scoring it gives is amazing.

There is room for improvement in GitGuardian on Azure DevOps. The implementation is a bit hard there. This is one of the things we requested help with. I would not say their support is not good, but they need them to improve in helping customers on that side.

I have been using GitGuardian Internal Monitoring for the last year.

Every single time I have accessed the platform, it has been available. And every single time I tried to use a feature, it was working. The stability is spot-on.

In the beginning, they were covering GitHub and then they started doing Azure DevOps. It is scalable and they are getting there.

As long as our company grows and we have more developers, we are going to increase our usage of GitGuardian. It's becoming a very heavy-duty tool that we depend on every single day.

GitGuardian's support is amazing. They helped us to set it up properly all the way. And whenever we give them feedback, they take it into consideration, if it is a new feature. And if it is a bug, they work on it and fix it. The support is superb.

Neutral

The preparation needed on our side to start using GitGuardian wasn't anything out of the normal. It included the types of activities we have had to do with any other product. The onboarding was really good because they were there. They helped us the entire time.

Between developers and security personnel, we have about 25 users, but it does not require any type of maintenance on our side.

There's no direct return on investment. Security is overhead, but at least I'm sure that we are protecting our company assets, and that's a return on its own.

The pricing and licensing are fair. It isn't very expensive and it's good value.

We evaluated Dependable and GuardDuty. One of the main differences between these solutions and GitGuardian is the interface. The GitGuardian GUI is very good and much easier to use than anything else. It's very user-friendly. It gives you what you want. You can do as much filtering as you want. 

And another important difference over other technologies is that GitGuardian has fewer false positives, which is very advantageous. Dependable and Guard Duty give you things that are not relevant or that are false positives, at times. That does not happen often with GitGuardian.

If someone at another company were to say to me that secrets detection is not a priority, I would say that's not a very smart approach. Secrets detection is a very essential part of security. It's one of the basics that you need to cover all the time. Otherwise, you're going to expose your endpoints online and you're going to suffer endless attacks. You definitely need to have secrets detection tools. We use a combination of tools, but GitGuardian is my preferred tool.

When it comes to application development, secrets detection is essential to a security program. You need to have it. Otherwise, you'll fail.

In this technology, nothing is perfect yet and it's going to take time. But so far, GitGuardian is the best I've seen. Overall, it's a very good product.