GitGuardian Platform Reviews

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.

We use it mostly to look for secrets in our repositories so we can inform the developers not to do that.

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

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

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

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

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

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

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

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

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

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

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

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

This is our second year of using this solution.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We use it for detecting secrets in our code repositories.

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

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

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

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

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

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

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

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

There are also a lot of integrations. 

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

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

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

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

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

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

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

We haven't had any issues with their support.

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

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

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

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

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

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

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

Secrets detection is very important to security.

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

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

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.