IT Central Station is now PeerSpot: Here's why

GitGuardian Internal Monitoring OverviewUNIXBusinessApplication

GitGuardian Internal Monitoring is #4 ranked solution in top Data Loss Prevention (DLP) tools, #8 ranked solution in AST tools, and #9 ranked solution in application security tools. PeerSpot users give GitGuardian Internal Monitoring an average rating of 8 out of 10. GitGuardian Internal Monitoring is most commonly compared to Snyk: GitGuardian Internal Monitoring vs Snyk. GitGuardian Internal Monitoring is popular among the small business segment, accounting for 97% of users researching this solution on PeerSpot. The top industry researching this solution are professionals from a computer software company, accounting for 57% of all views.
What is GitGuardian Internal Monitoring?

GitGuardian Internal Monitoring helps organizations detect and fix vulnerabilities in source code at every step of the software development lifecycle. With GitGuardian’s policy engine, security teams can monitor and enforce rules across their VCS, DevOps tools, and infrastructure-as-code configurations.

Widely adopted by developer communities, GitGuardian is used by more than 200 thousand developers and is the #1 app in the security category on the GitHub Marketplace. GitGuardian is also trusted by leading companies, including Instacart, Genesys, Orange, Iress, Beyond Identity, NOW: Pensions, and Stedi.

GitGuardian Internal Monitoring is an automated secrets detection and remediation platform. By reducing the risks of secrets exposure across the SDLC, GitGuardian helps software-driven organizations strengthen their security posture and comply with frameworks and standards.

Its detection engine is trained against more than a billion public GitHub commits every year, and it covers 350+ types of secrets such as API keys, database connection strings, private keys, certificates, and more.

GitGuardian brings security and development teams together with automated remediation playbooks and collaboration features to resolve incidents fast and in full. By pulling developers closer to the remediation process, organizations can achieve higher incident closing rates and shorter fix times.

The platform integrates across the DevOps toolchain, including native support for continuously scanning VCS platforms like GitHub, Gitlab, and Bitbucket or CI/CD tools like Jenkins, CircleCI, Travis CI, GitLab pipelines, and many more. It also integrates with ticketing and messaging systems like Splunk, PagerDuty, and Slack to support teams with their incident remediation workflows. GitGuardian is offered as a SaaS platform but can also be hosted on-premise for organizations operating in highly regulated industries or with strict data privacy requirements.

GitGuardian Internal Monitoring Buyer's Guide

Download the GitGuardian Internal Monitoring Buyer's Guide including reviews and more. Updated: May 2022

GitGuardian Internal Monitoring Customers

Automox, 66degrees (ex Cloudbakers), Instacart, Genesys, Iress, Now:Pensions, Orange, Seequent, Stedi, Talend

GitGuardian Internal Monitoring Video

GitGuardian Internal Monitoring 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."
  • "The internal side is cheap per user. It is annual pricing based on the number of users."
  • "We have seen a return on investment. The amount of time that we would have spent manually doing this definitely outpaces the cost of GitGuardian. It is saving us about $35,000 a year, so I would say the ROI is about $20,000 a year."
  • "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."
  • "It's a little bit expensive."
  • "The pricing and licensing are fair. It isn't very expensive and it's good value."
  • 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
    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: PeerSpot 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.
    Security Engineer at a tech services company with 11-50 employees
    Real User
    Catches secrets before they have made it into production
    Pros and Cons
    • "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."
    • "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."

    What is our primary use case?

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

    How has it helped my organization?

    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. 

    What is most valuable?

    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.

    What needs improvement?

    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.

    For how long have I used the solution?

    This is our second year of using this solution.

    What do I think about the stability of the 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.

    What do I think about the scalability of the solution?

    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.

    How are customer service and support?

    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.

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

    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.

    How was the initial setup?

    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. 

    What was our ROI?

    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. 

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

    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.

    Which other solutions did I evaluate?

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

    What other advice do I have?

    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.

    Disclosure: PeerSpot 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
    Buyer's Guide
    GitGuardian Internal Monitoring
    May 2022
    Learn what your peers think about GitGuardian Internal Monitoring. Get advice and tips from experienced pros sharing their opinions. Updated: May 2022.
    596,362 professionals have used our research since 2012.
    DevSecOps Engineer at a computer software company with 1,001-5,000 employees
    Real User
    Top 20
    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: PeerSpot 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
    Jon-Erik Schneiderhan - PeerSpot reviewer
    Senior Site Reliability Engineer at a computer software company with 501-1,000 employees
    Real User
    Top 20
    We feel safe because we don't have valid credentials sitting in our code repositories
    Pros and Cons
    • "The secrets detection and alerting is the most important feature. We get alerted almost immediately after someone commits a secret. It has been very accurate, allowing us to jump on it right away, then figure out if we have something substantial that has been leaked or whether it is something that we don't have to worry about. This general main feature of the app is great."
    • "They could give a developer access to a dashboard for their team's repositories that just shows their repository secrets. I think more could be exposed to developers."

    What is our primary use case?

    We procured it as a secrets and code detection solution. We have code bases, some of which are 10-years-old. We needed a way to comb through all of the Git histories to see if any developers had committed secrets to our code in the past as well as catch any new secrets that developers may accidentally commit in the future.

    We are using GitGuardian Internal Monitoring.

    How has it helped my organization?

    Without GitGuardian, we wouldn't be doing real-time detection of secrets. It would be something that we did periodically. Maybe quarterly or semi-annually, we would review our code for secrets. This means that the mean time to detection would be much longer. GitGuardian reduces our mean time to detect substantially. In addition, we would be finding out about secrets much further away from the time that they were introduced into the code base. We would be chasing people down to give us information about things that they did weeks or months ago. This would drastically reduce the effectiveness of us being able to triage and remediate the leaked secrets.

    We don't have to do a periodic review to see if there are any secrets in our code bases. I would estimate, if we were to do that on a quarterly basis, we would be spending an entire week per quarter on it that we don't have to spend now. Therefore, it saves us a week every quarter in pure effort.

    If we did not have GitGuardian, our mean time to detection would be much longer. We would have a substantial amount of risk that a set of credentials or a secret was being used maliciously. Every quarter, there was a security incident that came from the risk of these credentials living in our code bases. That might be another week worth of effort that our security team would have to deal with. Since we are catching things immediately, that risk is inherent in our environment and we don't have to worry about a security incident happening. The chances are much lower. We take a week of pure effort to review secrets that went away. Then, there is a week of dealing with security incidents that come from the secrets living in our code bases.

    The solution efficiently supports our shift-left strategy.

    What is most valuable?

    The secrets detection and alerting is the most important feature. We get alerted almost immediately after someone commits a secret. It has been very accurate, allowing us to jump on it right away, then figure out if we have something substantial that has been leaked or whether it is something that we don't have to worry about. This general main feature of the app is great.

    Recently, they added a feature that checks the validity of leaked secrets. It will actually reach out and see if the secret that leaked was valid or not. I have found, over the past couple months, this to be a super useful feature. We can go through a lot of the secrets in our code base, which have been detected, and dismiss them if we know that they are invalid secrets that can't be used anyway. This saves us a bunch of time, which is why this has been a really neat feature that has been useful.

    I have found that I have been very satisfied with the breadth of the solution's detection capabilities. I don't think it has missed anything. The false positive rate has been very low. Every single time something is detected, it is something that we should look at. It does a very good job of detecting things that we should look at and make a decision on. We don't waste a lot of time chasing down false positives. This means that we feel safe because we don't have valid credentials sitting in our code repositories. If any of our code was breached or any of our developer work stations were compromised or stolen, no one would be able to get valid API credentials out of the Git repositories on those workstations.

    The solution helps to quickly prioritize remediation because it allows us to tell which keys are valid versus which ones are invalid. We prioritize the valid ones first. It also lets us sort by detection type, e.g., what kind of secret is it detecting. There are ones that we would obviously prioritize over others, like SSH keys or AWS credentials, versus less sensitive credentials that aren't as concerning. I think it does a great job of helping us prioritize.

    GitGuardian provides a feedback form feature that we utilize heavily. When a secret is detected, our process is to generate a feedback form link in GitGuardian, then provide that to the developer. The developer will give us contextual information about the secret, then we can take action. They have also recently released a feature, which we haven't started using yet, called automated playbooks where you can set it up to automatically create that feedback form. Then, it will be emailed to the developer so they get automatically notified that they introduce a secret with a feedback form to fill out. I suspect this will improve our developer's ability to resolve the secrets faster.

    What needs improvement?

    Six months ago, I would have said improving the ability to automatically get feedback from a developer so we wouldn't need to take action when reaching out, but that has been addressed.

    They could give a developer access to a dashboard for their team's repositories that just shows their repository secrets. I think more could be exposed to developers.

    For how long have I used the solution?

    I have been using the solution for 15 months.

    What do I think about the stability of the solution?

    I haven't noticed any downtime nor had any issues accessing it. So far, stability and reliability have been excellent.

    GitGuardian does not require any maintenance on our side.

    What do I think about the scalability of the solution?

    So far, I haven't hit any scalability issues at all.

    We have three security engineers who are actively using the service. We also have about 80 developers who are indirectly using the service through the feedback forms.

    How are customer service and support?

    So far, the support has been great. The only issues that we initially had were with the initial SSO integrations, and they were pretty responsive with that. I think the support has been great, though we haven't needed it much.

    I would rate them as nine out of 10. They respond to me almost immediately every time that I have a question, which has been great. I haven't experienced any delays or not had an issue solved.

    How would you rate customer service and support?

    Positive

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

    The solution has increased our secrets-detection rate. Previously, we only detected secrets when someone saw them, which was rare. Especially since a large portion of our secrets are in the Git history, not in the current state of the repository, we were only made aware of 10% of the secrets before. Now, we are probably in the 90 percentile.

    How was the initial setup?

    There was a ramp up period. When we set it up and linked it up, we had to review all the initial findings and process them. That took a significant amount of time.

    What was our ROI?

    We just weren't doing this before we had GitGuardian. It has enabled us to do something that we weren't able to do before. If we were doing it manually, then we might have spent 200 hours doing this manually over the past year. So, we just wouldn't do it if we didn't have something like GitGuardian.

    The solution has significantly reduced our mean time to remediation, by three or four months. We wouldn't know about it until we did our quarterly or semi-annual review for secrets and scan for secrets.

    We have seen a return on investment. The amount of time that we would have spent manually doing this definitely outpaces the cost of GitGuardian. It is saving us about $35,000 a year, so I would say the ROI is about $20,000 a year.

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

    If you were to run a proof of concept with GitGuardian and see all of the things that it detects, then you would probably be very surprised. You can tell very quickly what the return on investment will be and how much risk a tool like this can mitigate.

    Which other solutions did I evaluate?

    We evaluated TruffleHog, but we liked GitGuardian better.

    What other advice do I have?

    My advice would be to talk with them about your needs. There are different use cases between security personnel working with GitGuardian versus developer personnel working with GitGuardian.

    Secrets being used to access resources is probably one of the most common ways to be involved in a high profile breach these days. If you are not detecting secrets in code, then every developer's machine is a security breach waiting to happen. A developer in your org is going to leave their laptop at a coffee shop one of these days. If they have the code base checked out, and there are valid secrets in that code base, then it is only a matter of time before they get used to accessing resources that they are unauthorized to access. 

    This is one of the higher priority things right now because developers are way more likely to commit secrets than I would have ever expected.

    We haven't adopted any of the GitGuardian's shield functionalities. We just haven't taken the time to roll that out to all our developers. They have the functionality there, and it works great, but we haven't been able to prioritize the rollout on our end.

    Security engineering is using the solution pretty extensively. We are not making use of a lot of the shift-left features. We would like to roll them out over the course of the coming year.

    I have been super happy with it. I would rate this solution as nine out of 10. I am just leaving room for building out more features for looping in developers.

    Disclosure: PeerSpot 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
    Senior Security Engineer at a insurance company with 201-500 employees
    Real User
    Highlights problems and shows engineers how to properly remove them from code, making us materially more secure
    Pros and Cons
    • "GitGuardian has pretty broad detection capabilities. It covers all of the types of secrets that we've been interested in... [Yet] 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."

      What is our primary use case?

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

      How has it helped my organization?

      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.

      What is most valuable?

      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.

      For how long have I used the solution?

      I've used the solution for one year.

      What do I think about the stability of the solution?

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

      What do I think about the scalability of the solution?

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

      How are customer service and support?

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

      How would you rate customer service and support?

      Positive

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

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

      How was the initial setup?

      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.

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

      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.

      What other advice do I have?

      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.

      Disclosure: PeerSpot 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
      Director of Development at a computer software company with 1,001-5,000 employees
      Real User
      Top 10
      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: PeerSpot 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
      Abbas Haidar - PeerSpot reviewer
      Head of InfoSec at a tech services company with 51-200 employees
      Real User
      Top 10
      Supports our shift-left strategy with more accurate secrets detection, but Azure DevOps side could be made easier
      Pros and Cons
      • "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."
      • "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."

      What is our primary use case?

      We use it for secrets detection.

      How has it helped my organization?

      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.

      What is most valuable?

      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.

      What needs improvement?

      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.

      For how long have I used the solution?

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

      What do I think about the stability of the solution?

      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.

      What do I think about the scalability of the solution?

      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.

      How are customer service and support?

      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.

      How would you rate customer service and support?

      Neutral

      How was the initial setup?

      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.

      What was our ROI?

      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.

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

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

      Which other solutions did I evaluate?

      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.

      What other advice do I have?

      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.

      Disclosure: PeerSpot 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