GitGuardian Internal Monitoring Reviews

In general, we use Gitguardian as a safety net. We have our internal tools for validating that there is no sensitive data in there. GitGuardian is a more general and robust solution to double-check our work and make sure that if we are committing something, it only contains development IDs and not anything that is production-centric or customer-centric.

The main way in which we're using it at the moment is that it is connected through the GitHub integration. It is deployed through our code review process. When pull requests are created they connect with GitGuardian, which runs the scan before there is a review by one of our senior devs. That means we can see if there are any potential risk items before the code goes into the main branch.

It automates tasks and allows more individuals at the company to handle remediation. It provides visibility for the pull requests. It is integrated into our code review and deployment processes, and that integration allows the author to address an issue almost immediately, rather than waiting for a time-consuming review, and then manually asking the author to address it. It provides a nice safety mechanism, giving us some assurance that if something got forgotten along the way, we are notified before we make it a part of our codebase. It is much harder to remove something after it is merged than to do so beforehand.

It helps in quickly prioritizing remediation. We have set up GitHub and our pull requests in a way that there are numerous checks that have to be passed. The code that is submitted can't be brought into the codebase until anything flagged is addressed as a test credential, a false positive, or the original branch is corrected. Fortunately, so far, they've all been false positives or test credentials. But it puts a stopping point in the process before it can go live with that information in there.

What is particularly helpful is that having GitGuardian show that the code failed a check enables us to automatically pass the resolution to the author. We don't have to rely on the reviewer to assign it back to him or her. Letting the authors solve their own problems before they get to the reviewer has significantly improved visibility and reduced the remediation time from multiple days to minutes or hours. Given how time-consuming code reviews can be, it saves some of our more scarce resources.

GitGuardian has also helped in bringing the responsibility of remediation to the entire team. Rather than having remediation as a part of the review process, where some of the more senior and experienced developers bring something up, it allows the whole team to handle that process. In the long run, it will encourage the team to think about those sorts of things before even submitting code, based on the responses they see from GitGuardian. It has increased the productivity of the security team by reducing the load on our small team. It puts the burden onto the entire team rather than the security team. Instead of them requesting remediation manually, it is automated as a part of our deployment process. It is definitely saving us hours per incident.

Time to remediation is now in minutes or hours, whereas it used to take days or weeks previously. That's the biggest improvement. Because it is automated and visible to the author, someone from the security team doesn't have to remind them or recheck it. That means the slowdown in the deployment process has definitely been improved by an order of magnitude. There is easily a 30-hour improvement on time to remediation, which is about an 85 percent improvement.

The Internal Monitoring is clearly the most valuable for us. We don't have a lot of public repositories, meaning the Public Monitoring is nice to have just in case something were to happen. But the Internal Monitoring catches things like IDs or tokens for some of our internal development. For that development, it's fine to have them in source control, but when those things are flagged, it is a nice reminder to the developer to double-check and make sure this is something that's only data and that there is nothing sensitive or production-related in it. In addition to being a good tool, should we have something sensitive in there, it is a nice reminder. Even though one of our senior reviewers double-checks credentials, when the developers submit something and get that warning message, they can proactively address it.

There are a lot of nice tools, in addition to the GitHub integration, to help us as our dev team grows and to give our individual developers more responsibility, instead of just having it completely on the reviewer to validate things.

If something does pop up but perhaps the developer doesn't notice it, you can send a share link to have them review it and confirm things, such as whether it is a false positive or a test credential, and that can be done right through the share link.

The breadth of its detection capabilities is very good. There are a lot of integrations with different products, which is nice. There are some test credentials in our testing environment that are not sensitive, but it has warned us about a lot of those, although I can understand how it would consider them worth flagging. Overall, I've been impressed with what it has found. It has even found old test credentials that we don't need anymore. It has resurfaced them so that we can clean them up.

Its accuracy of detection is pretty good. The only false positives that we've had are mostly related to location, meaning closeness to a couple of the strings we use. We use a lot of unique identifiers that are 32-character-long tokens, so if they are near a word like "credential" or "password," that's the most common false positive. Configuring those as a false positive means they generally don't reoccur unless we have a new ID in there, which is pretty rare. There have been a couple of such instances, but not too many overall, given the size of our code base. At this point, we don't have those false positives because we've identified them. When we started, about 10 to 15 percent of them were false positives in that category, but after we identified them, they went away.

The main thing for me is the customization for some of the healthcare-specific identifiers that we want to validate. There should be some ability, which is coming in the near future, to have custom identifiers. Being in healthcare, we have pretty specific patterns that we need to match for PHI or PII. Having that would add a little bit extra to it.

In addition to the customization, having some kind of linking on the integration would be another improvement. The product itself is very good at grouping the same incident, but if it detected a test credential that didn't have remediation and that same one comes up in a new commit, it can be harder to find the new one. If you have a new instance of an older remediation, making sure that you're seeing the same one can be a little bit tricky. We had that issue more when we first started and hadn't gone through the original list. Now that it is cleaned up, it is less of an issue.

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

It seems really stable. Searches and integration are fast, and we get a response back almost immediately when making pull requests. From there, it is a matter of using the UI to find things and to send links to people. Everything has been consolidated and we haven't had any issues.

So far, everything seems fast and easy. I know there is the option to build in a lot of rules, but we haven't really had to. We just let it group and do normal things, and then we just address things as they come up. There hasn't been an overabundance of false positives. It is intelligent enough to surface the right information without overwhelming us.

Currently, three people on our security team and 14 people on our dev team use it. The security team is double-checking the incidents that come in, but everyone on the dev team gets the alerts if a warning comes up during one of the pull requests. They can then sign in and address them as needed.

It is being used as part of our deployment process. I don't know how we would increase its usage. When they have the customization, we might increase usage, but that would just be another rule on the same integration.

We haven't had to reach out to tech support at all. I'm optimistic, given their attention to detail on getting the integration set up and how simple it was, that it would be pretty good. But being able to figure everything out on our own has been a good sign.

We did not use any other solution previously. We have some pre-commit hooks that we have written that are customized for some of our own rules, but we haven't had another solution for this type of security credentials detection.

The initial setup was very straightforward. The deployment time was five minutes. It was the easiest integration I've ever done.

We've hooked up other stuff to GitHub before, and it usually involves a few steps. But with GitGuardian, I just generated a token and walked through it. I don't think I even read the documentation. I just found what I wanted to do, made a token, and it connected right up. I wasn't sure if I had done it correctly until I saw it started popping things in there. It was a really easy onboarding process.

Its ease of integration showed the maturity of the product or their focus in getting that process right. GitHub has its own rules and it changes a lot. Seeing how solid GitGuardian was gave us confidence in the solution.

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

We have definitely seen a return on investment. There is value in having the whole team exposed to the secrets. We do manual reviews before things get deployed, and we also run automated tests. But automated tests can take a while to run, while this runs pretty quickly. Having that feedback so that something gets detected before the review starts really saves a lot of time for some of our more senior and busier devs who are doing manual reviews. That time saved gives us ROI. Rather than starting a review and then having to do a new review after the secrets have been addressed, they are now able to ensure that all secrets are addressed before they review something.

Its pricing is very reasonable for what it is. We don't have a huge number of users, but its yearly rate was quite reasonable when compared to other per-seat solutions that we looked at. I'm not aware of any costs in addition to the standard licensing fees.

Having a free plan for a small number of users was really great. If you're a small team, I don't see why you wouldn't want to get started with it.

We looked at a couple of other solutions. GitGuardian seemed to be the most robust. It had different ways to connect and validate the code. We wanted to see it with our code and the pull requests. The ease of connecting the integration was definitely a major positive. We were able to integrate it quickly and easily and see the results right away. It checked off the requirements we had. It also integrated with a lot of different things, and it had a lot of robustness not only around secrets detection but also around how they were handled. 

Seeing how quickly it could produce search results on the public side, and knowing how much is in GitHub that is public, was really impressive. We knew it wasn't going to be a burden on our deployment process or that we would be waiting for it a lot. Once it was hooked up, its speed and accuracy made it a pretty easy decision to get it.

The other solution that was in the running felt like a very new product, and there was a lot more manual customization to get it to be as clear and as well-categorized as GitGuardian. That other solution was a centralized place and more automated than our process was, but it wasn't as well thought out and as well organized as GitGuardian. We got a lot more out-of-the-box with GitGuardian than we would have gotten with the other solution. Given that it is for secrets detection, you have to have confidence in the solution you go with. The other solution not being a robust solution was something of a red flag for us. We wanted something that was very well thought out from the beginning, because of the sensitive nature of what it is doing.

I would advise others to give it a try. It is easy enough to integrate with your process, and you'll see the value right away, with a couple of quick test scenarios. Once you see it in action, it sells itself.

If a colleague at another company said to me that secrets detection is not a priority, I would ask what is more of a priority, and then I would point to a quick Google search with a myriad of issues and data breaches that have happened from leaked secrets. That is pretty easy to find. If leaks are happening, and there is a reasonable plan, or even a free plan for a small number of users, to deal with them, I don't know how much more bang for your buck you can get. I would tell him to consider the small amount that GitGuardian costs and the value and ease of integration that it provides.

Secrets detection is extremely important to a security program for application development, especially on a team of people with various experience levels. Having something automated always improves things. Having that detection on top of any of your manual processes adds an extra layer of safety. Given the ease of integration, it is extremely important and extremely valuable to have that extra layer of protection to warn you if you do forget something.

So far, GitGuardian hasn't detected any true secrets in our code. They were only internal credentials, but it has certainly brought a much-needed discussion about those test credentials. Fortunately, we've been successful at not committing production secrets since we started using this solution.

The biggest lesson that I've learned from using this solution might not be so much from secret detections, per se. It is about the ease of integration and what going the extra mile actually does. It creates a positive experience, and it also helps in creating a lot of faith in the solution, overall. With the onboarding experience being handled very well, it gave me a lot of confidence that this was the right solution. That's a lesson for our own software. It is super important to have that ease of getting started. That can go a lot farther than you might think for the effort it requires in the overall project. I'm sure a lot more resources are spent on the analysis and the tool itself, but don't skimp on the onboarding.

I would rate GitGuardian a nine out of 10. The two areas for improvement are probably the only things that are keeping me from giving it a 10. The major one of those is probably going to be addressed pretty soon. Once we can do some of those custom identifiers or custom rules, it would be a 10.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We've used GitGuardian for more than a year.

I haven't had any problems with GitGuardian. 

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

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

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

Positive

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This is our second year of using this solution.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Our main use case is operational security. We have a big IT platform. A lot of it is built in-house. We are not a focused IT company. We are a retailer. We have a lot of developers with a lot of different levels and projects. For example, with fashion brands, it is just, "Oh, we want to do this new app," and then they put it on our GitHub. Suddenly, we see all kinds of API keys and secrets in there. This solution is very useful for us because GitGuardian lets us know about them, then we can take care of it.

It is on the cloud. We gave GitGuardian access to our organization and codebase. It just scans it on an ongoing basis.

Since using GitGuardian Internal Monitoring, we have found potentially enterprise-destroying secrets in our GitHub. For example, if our Git got compromised or we had a rogue employee, they could get a lot of business-critical data, disrupt the business, or put us at very high risk. More or less, we are now somewhat protected against that. Now, we are at a stage where we are just keeping an eye on it. As soon as a developer pushes something or does something, we get informed and act on it. The exposure time is very small. Before GitGuardian, we had secrets for years that we did not know about.

As soon as a new secret is detected, we get an email. We look at it, then contact the developers. It is a very fast process. For example, if it is my code and I pushed it, that is the fastest scenario. It is my problem. GitGuardian finds it, then I can fix it myself. I don't have to call another team, talk to them, etc. It could be within a minute that it is remediated.

The most valuable feature is automatic secrets detection, which is quite intelligent. It gives us very few false positives, which is definitely worth it at the end of the day as no secrets or confidential keys are getting into our GitHub undetected.

The majority of false positives are things like test credentials or dummy data that we put in for testing, etc. Therefore, it is not really feasible for GitGuardian to understand which is dummy data and which is real data. They do well in terms of false positives. They work quite hard on them. Sometimes they understand that it is dummy data. 

For certain types of secrets, they can check if it is being used. They will go to Microsoft and check if the key is valid in Microsoft, then tell you, "Hey, this secret is actually live somehow." This is another feature that they are working on that I like.

The breadth of the solution's detection capabilities are really good. We haven't walked upon a piece of code where we question, "Oh, why isn't GitGuardian picking this up?" That's for sure. If there are some secrets in our Git that we don't know about and GitGuardian hasn't found it, I don't think it is likely that we will.

For remediation, GitGuardian is quite good at pointing out all the incidents and helping us handle them. However, remediation is mostly in our hands. We have to go in and resettle. If they could detect secrets before they end up in our GitHub, that is the only improvement that would be a meaningful improvement from what they have. 

Right now, we are like the SRE team for the company. We need to monitor all the secrets, because when we give somebody access, they either see nothing or everything in GitGuardian. We would like to be able to tune it so developers can see the secrets that GitGuardian detected in their own repositories and teams. Then, they could manage it themselves. We wouldn't have to be in the middle anymore. We could just supervise and make sure that they do fix it. For example, if they might not care about their secrets getting spilled into Git, then we need to get our stick and chase them around the office.

I have been using it for a year.

We have not had any issues at all with stability.

We do not do maintenance, per se. We do need to react to all the incidents that the solution finds. We have to triage them if we find false positive or test credentials. It is reacting to GitGuardian's information. We don't have to do anything else.

Four or five people from my team are monitoring the solution.

I haven't seen any problem with its scaling. We pay per repository, or something like that, but otherwise it is very agile and fast. 

We didn't have to use the technical support for anything. The solution has worked great and we haven't had any issues. We have just had questions, specifically regarding RBAC and self-service type of stuff, but that is more roadmap development.

We actually have a lot of tools for developers to handle and manage their secrets in regards to whatever applications or code they develop, but not all of the teams and developers know how to use those properly. This causes secrets ending up in our codebase. Before we had GitGuardian, we did not understand that certain teams had this blind spot. We thought, "Oh, they know what they are doing. They just forgot, made a mistake, or committed some code by accident." However, we found out some of them had some learning to do.

The initial setup is very quick and simple to do. It takes a few minutes and about 10 clicks to do it.

As an engineer, I am not paying for it. We just implement and use it. After using it in the trial, we went into a long-term contract with GitGuardian. That is definitely the business deciding that it is worth it. It is paying for itself.

We realized the benefits from it immediately. We started with a 30-day demo and said, "Just clean up our repository. We will be happy with that." However, it was so useful. It was immediately obvious that it would save our bacon in many situations. We decided to keep it.

GitGuardian Internal Monitoring has helped increase our secrets detection rate by several orders of magnitude. This is a hard metric to get. For example, if we knew what our secrets were and where they were, we wouldn't need GitGuardian or these types of solutions. There could be a million more secrets that GitGuardian doesn't detect, but it is basically impossible to find them by searching for them.

There are the obvious benefits, but they are very hard to count in the security business. Until you get hacked or compromised, your costs are zero, but then you are destroyed. So,  the relationship between cost and time savings is a hard thing to measure. GitGuardian is pulling a lot of the hard work when it comes to this, as it was one of our biggest holes in our security, and GitGuardian plugs it up completely.

We had issues that were ongoing for a long time before we had GitGuardian. I remember that it once took us a month to understand that we did something very bad. GitGuardian would have caught that in a minute. A month in, it was a lot harder to remediate because the solution was pushed out to other teams. It was used by a bunch of people, then we had to take it down and reset everything, etc. It was a much bigger downtime than it could have been.

It could be cheaper. When GitHub secrets monitoring solution goes to general access and general availability, GitGuardian might be in a little bit of trouble from the competition, and maybe then they might lower their prices. The GitGuardian solution is great. I'm just concerned that they're not GitHub.

We played around with others. GitHub has a big advantage because they are GitHub. Their focus is on zero false positives, but we would rather have a few false positives and get everything.

We tried TruffleHog once. I don't remember why, but it didn't work quite right for us. We did see a lot more secrets being detected by GitGuardian than TruffleHog.

We ran GitGuardian and TruffleHog in parallel. We noticed that GitGuardian was finding a bunch of random secrets that TruffleHog did not. I think that GitGuardian is using machine learning, or something like that, to understand Azure, AWS, Google API keys, or standard secrets very commonly pushed into GitHub. They figure out even random API keys or secrets that developers made up by themselves and put them in their code. Other solutions do not detect these unless we put a specific rule for that, but how can we put a rule for something that a developer just thought up in their head.

GitGuardian's surveillance perimeter is better for removing blind spots than any of the other products that we tested.

With the Git solutions, we spent a lot of time doing research. Because we have a big contract with GitHub, we were leaning heavily towards them. GitHub relies on some very hard-coded rules that they build themselves about, "What do secrets look like? What does a password look like? What does a key look like?" If you want to catch new types of secrets, you need to make the rules yourself or wait until GitHub adds new rules. While GitGuardian is very flexible, it will show you, "Hey, we think this might be something that you should look at." Then, we just say, "No, it's not," or, "Oh my God. That is definitely something that we should look at." That is the main advantage of GitGuardian.

This is where they are at a disadvantage. One of our biggest issues is that GitGuardian doesn't just search the code as it is right now. It searches the whole history of your code change in every repository. So, if we ever push a secret, even if you deleted it, it is still in the history because that is how Git works. We can reset those keys, secrets, and even delete them from the history itself. We can rewrite the history so they were never there to begin with if you search for them now. What we cannot do is delete them from pull requests and such. Those pull requests are controlled by GitHub and only GitHub can do it. We actually have to call GitHub support to erase the secrets from our requests. So, it's not really GitGuardian's problem; it's GitHub's.

We don't use it for monitoring our developer's public activities. We just focus on our own secrets. We are slowly building up our operational security and our security in general to Git. Right now, we are waiting for improvement in the RBAC support for GitGuardian.

I would say, "Good luck," to someone who says secrets detection isn't a priority. Their priorities are probably wrong. One of the easiest ways for intrusion, as well as losing a lot of money in your company, is getting your secrets leaked somehow.

Secrets detection to a security program for application development is one of the most important things. There are a few stages that application development goes through, it is:

1. on the developer's machine
2. in the code repository
3. packaged as an application
4. then it is running somewhere.

All these steps have to be secured and taken care of. The application itself needs to be secure from a hacker coming in and trying to use brute force or exploit some software. All of these steps need to be airtight since your security is only as strong as your weakest link. This is so you can make very modern, secure applications. However, if your secrets are in your GitHub and anybody can see them, then those people who have access to one application or code repository, then can see your secrets. They can then take that and do a lot of stuff with it.

I would go with nine out of 10. It would be almost a 10 if it had RBAC.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Positive

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

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

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

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

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

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

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

We are using GitGuardian Internal Monitoring.

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

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

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

The solution efficiently supports our shift-left strategy.

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

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

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

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

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

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

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

I have been using the solution for 15 months.

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

GitGuardian does not require any maintenance on our side.

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

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

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

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

Positive

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

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

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

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

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

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

We evaluated TruffleHog, but we liked GitGuardian better.

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

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

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

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

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

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

Since we have a lot of internal teams, the main team running this tool is composed of developers. Because of the security aspects of GitGuardian, they figured that we needed to bridge the gaps and work together.

GitGuardian creates a lot of alerts in the code. If someone uses new passwords or secrets, then we can see in which repository as well as who used it and left their password in the code. We monitor these things. However, they haven't given us a permission to work with alerts since it is more for analysis purposes right now, seeing what problems we have in the company, e.g., we are seeing a lot of people just dumping passwords in the code, which is not a good approach.

Our main strategy is focusing on moving testing quality and performance earlier on in the development process. Developers are focusing on this quite heavily.

We are using the latest version.

It quickly prioritizes remediation, but individual teams get to decide how they do things. The problem, where we work, is that we work in an agile setup. Each team decides how they want to do it. Sometimes, developers are prioritizing different things though. That is the reason why we started working with developers. We were trying to push the security agenda, because developers would just like to work on code. Most of them don't care about security. While this tool has helped with prioritization, a problem can be that developers are not taking the security prioritization into the mix.

Two weeks ago, I spoke with the main lead of the developer team. They said that we shouldn't close alerts ourselves, but the tool helps. From a security perspective, we collect the data since we will use it in the future with analysis, but the developers are closing the alerts. GitGuardian really helps us to collaborate since we can just copy and paste a particular incident, then ask them, "What are you doing? Why are you doing this?" That really helps.

GitGuardian has helped to increase our security team's productivity. Now, we don't need to call the developers all the time and ask what they are working on. I feel the solution bridged the gap between our team and the developers, which is really great. I feel that we need that in our company, since some of the departments are just doing whatever and you don't know what they are doing. I think GitGuardian does a good job of bridging the gap. It saves us about 10 hours per week.

I like the ease of the UI. The UI is very straightforward. It is easy to access and monitor. There are not a lot of hoops to jump through. Click on it, and everything is in the main dashboard. This is really helpful. With other systems that we are using in our company, we have a lot of other dashboards, and sometimes you need to click five times to see something. With GitGuardian, it is very easy to access alerts, which is very nice. I like the UI aspect of it because it is very easy to use.

The span of the solution's detection capabilities is good and very quick. Alerts and incidents poop up immediately.

The range of technology that the solution covers is huge, which is nice. There are broad SMTP credentials for generic passwords. 

The documentation is good and very insightful.

I am unsure if they have a mobile app. That could be a feature or improvement in the future. A lot of our security dashboards don't have a phone app. A phone app helps because you can monitor things on the go. We are using the Darktrace solution that allows alerts on our phones, and we configure the alert threshold. That helps a lot. I think that a mobile app could be something that could be added in the future pipeline, if there is any demand.

From a security perspective, we received access, as analysts, six months ago. We are using it every day to analyze things.

Performance-wise, I haven't observed any bugs or problems. It worked from day one. We never had any hiccups, and I haven't observed anything bad.

No maintenance is needed from our side.

From the developer's perspective, they have said that there may be a problem with scaling. This may be a potential problem in the future.

The technical support has been very nice. The salespeople and technical people at GitGuardian are very approachable. We have no issues connecting with them. I reach some of them on LinkedIn, so I don't even have to create a support ticket or something. If I have a question, I just write to them on LinkedIn, and say, "Hey guys, what is up with that?" or, "What is this problem?" They are very quick to answer, and I like that approach. They are very open to communication. It is not very formal. In some other companies, you have to create a ticket and wait three days. Because they started very recently, they have a different approach, which is good. I would rate them as eight out of 10.

It is easy to contact GitGuardian. Contact them for a demo. I would start there. That would be my advice because the people working there are very friendly and knowledgeable. 

They were very eager to provide a demo to us. It was just one hour and they gave us information with an explanation.  

Positive

GitGuardian was our first tool of this type.

It has worked from day one. The UI and design are very easy to understand; it is not complicated. The left menu has incidents, parameters, and API integration settings. It is so obvious, so there are no issues with it. Whereas, other systems have a problem. For example, we are using McAfee, and in order to find something, you need to jump through settings, going to this and that. With GitGuardian, I am seeing everything in one place and don't need to do a lot of button gymnastics.

GitGuardian has helped us increase our secrets detection rate by a lot, in the ballpark of 60%.

With GitGuardian, we didn't need any middlemen. 

We use the GitHub integration. In our company, we use a lot of different systems. I can see CircleCI, Azure, GitHub Actions, and other alert options. In the future, we will implement that. However, just knowing that there are options is already nice since some other security tools don't have many options. That is what I like about GitGuardian, there are a lot of choices. You can plan your strategy about how you will implement things and what you are going to do.

There are product owners, senior developers, and day-to-day developers using this solution. There are 40 members connected to it, including 35 developers who are using it. My colleagues and I spend at least two hours a day going to the dashboard and looking into things.

If a security colleague at another company said, "Secrets detection is not a priority," then he is a very bad guy. It is a huge problem now with all the secrets in the code. It is important to monitor them, as it is a growing problem. I just heard a podcast this morning about security, where they talked about Symantec who did a research study about this particular issue. It seems like a lot of apps have this problem. It is really important to monitor these things and know about them in the code. Otherwise, you risk exposing things, then malicious actors can use them. 

The security guy needs to go back to school, do some training, and really be open-minded about it since it is a growing problem. It will continue to grow as a problem since a lot of developers forget that IT security aspect. They just copy and paste stuff, then leave it in the code and forget about it. That is how attacks happen; somebody slipped, making a mistake or misconfiguration.

Secrets detection to a security program is very important for application development because developers are just ignoring it. They just commit the code, then the secrets are there. I feel GitGuardian is a good tool because it shows this to your face. As we continue monitoring, we plan to do a presentation of our findings to management.

Overall, I would give it a seven out of 10. There are a lot of good things about GitGuardian, but there were some hiccups with the development. I feel there are some small things that are not working for our developer team. The solution is great, but it would be bad to say, "10," without acknowledging some of the problems. So, seven is good and fair.

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

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

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

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

It also supports a shift-left strategy.

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

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

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

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

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

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

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

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

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

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

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

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

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

Positive

We didn't have a previous solution.

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

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

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

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

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

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