We just raised a $30M Series A: Read our story

GitGuardian Internal Monitoring OverviewUNIXBusinessApplication

What is GitGuardian Internal Monitoring?

GitGuardian Internal Monitoring is an automated secret detection & remediation solution. It integrates with the Version Control System to further secure the software development life cycle. It scans existing code as well as incremental changes to detect secrets (API keys, database credentials, certificates). 

Scanning is done continuously but also on git history to ensure total coverage. The secret detection engine covers 250+ API providers, database connection strings, private keys, certificates, usernames and passwords and allows also to build custom detectors.

GitGuardian uses sophisticated pattern matching techniques to detect credentials that cannot be strictly defined with a distinctive pattern (like unprefixed credentials). The precision of the detection engine is very high as it returns 91% “true positive” feedback following our alerts, as reported by our users. The developer and the application security team get the alert and can start the remediation process immediately.

GitGuardian has a native integration with GitHub, GitLab and Bitbucket and there is both a Saas and an on-premise version available. It is also integrated with most common SIEM, ITSM, ticketing systems and chat to integrate with companies’ alerting flows.

Buyer's Guide

Download the Application Security Buyer's Guide including reviews and more. Updated: November 2021

GitGuardian Internal Monitoring Customers

Genesys, Seequent, Iress, Stedi, Now:Pensions, Cloudbakers

GitGuardian Internal Monitoring Video

Pricing Advice

What users are saying about GitGuardian Internal Monitoring pricing:
  • "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... 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."
  • "It's a little bit expensive."

GitGuardian Internal Monitoring Reviews

Filter by:
Filter Reviews
Industry
Loading...
Filter Unavailable
Company Size
Loading...
Filter Unavailable
Job Level
Loading...
Filter Unavailable
Rating
Loading...
Filter Unavailable
Considered
Loading...
Filter Unavailable
Order by:
Loading...
  • Date
  • Highest Rating
  • Lowest Rating
  • Review Length
Search:
Showingreviews based on the current filters. Reset all filters
DC
Chief Software Architect at a tech company with 501-1,000 employees
Real User
Top 20
Automates tasks and allows more individuals to be in involved in remediation, and the integration process is simple

Pros and Cons

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

What is our primary use case?

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.

How has it helped my organization?

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.

What is most valuable?

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.

What needs improvement?

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.

For how long have I used the solution?

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

What do I think about the stability of the solution?

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.

What do I think about the scalability of the solution?

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.

How are customer service and technical support?

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.

Which solution did I use previously and why did I switch?

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.

How was the initial setup?

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.

What about the implementation team?

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

What was our ROI?

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.

What's my experience with pricing, setup cost, and licensing?

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.

Which other solutions did I evaluate?

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.

What other advice do I have?

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.

Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Flag as inappropriate
BK
Dev SecOps Engineer at a computer software company with 1,001-5,000 employees
Real User
We get an instant notification every time a secret is committed, so we can immediately triage it

Pros and Cons

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

What is our primary use case?

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.

How has it helped my organization?

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.

What is most valuable?

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.

What needs improvement?

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.

For how long have I used the solution?

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.

What do I think about the stability of the solution?

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.

What do I think about the scalability of the solution?

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.

How are customer service and support?

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.

How would you rate customer service and support?

Positive

How was the initial setup?

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. 

What was our ROI?

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.

What's my experience with pricing, setup cost, and licensing?

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. 

Which other solutions did I evaluate?

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.

What other advice do I have?

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. 

Which deployment model are you using for this solution?

On-premises
Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Flag as inappropriate
Find out what your peers are saying about GitGuardian, SonarSource, Checkmarx and others in Application Security. Updated: November 2021.
552,695 professionals have used our research since 2012.
IK
Director of Development at a computer software company with 1,001-5,000 employees
Real User
Gives us more visibility into secrets in our code and helps to create awareness of security

Pros and Cons

  • "The most valuable feature of GitGuardian is that it finds tokens and passwords. That's why we need this tool. It minimizes the possibility of security violations that we cannot find on our own."
  • "There is room for improvement in its integration for bug-tracking. It should be more direct. They have invested a lot in user management, but they need to invest in integrations. That is a real lack."

What is our primary use case?

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

We started with public monitoring and switched to internal.

How has it helped my organization?

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

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

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

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

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

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

What is most valuable?

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

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

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

What needs improvement?

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

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

For how long have I used the solution?

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

What do I think about the stability of the solution?

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

What do I think about the scalability of the solution?

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

I also plan to start utilizing webhooks for integrations.

How are customer service and support?

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

How would you rate customer service and support?

Positive

How was the initial setup?

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

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

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

What was our ROI?

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

What's my experience with pricing, setup cost, and licensing?

It's a little bit expensive.

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

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

Which other solutions did I evaluate?

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

What other advice do I have?

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

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

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

Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Flag as inappropriate