GitGuardian Platform Reviews

We use the solution to detect any secret exposure.

The overall breadth of the solution is good. It's been able to detect most of the secrets that we have.

The accuracy of the solution is generally good, but we have had a number of false positives. For example, sometimes we would commit a test secret, and it would not follow the action of a secret. This is because the secret contained a prefix that is commonly used in passwords, such as "password". We have been able to take action to suppress these false positives moving forward.

The solution helps to quickly prioritize remediation. When we go back to the historical scan, it can tell us not only what vulnerabilities were exposed, but also the general risk level of each vulnerability. This allows us to prioritize remediation efforts and focus on the more critical vulnerabilities first.

The solution helped to decrease the overall false positive rate. We have been able to decrease the number of false positives by about seven percent. When we receive alerts now, they are usually general alerts. We do not receive alerts that are specific to a door without the pull being put in place when we investigate.

The solution increased our secret detection rate by around 80 percent.

We detected a security issue, and we were able to fix it in the system within half a day. This was possible because we reduced the number of follow-up steps required. The solution saved our security team about 25 percent of their time. This means that we probably removed about a week's worth of incident management work. This is a significant improvement in security, and it saved our team a lot of time.

The solution also helped reduce our mean time to remediation.

At the start, historical scanning was very useful because it was the first time we had done it. It allowed us to see how many secrets we had exposed. If we had only focused on current secrets, we would have missed all the secrets that had been committed in the past. So, initially, the historical scan was really useful.

Presently, we find the pre-commit hooks more useful. These hooks allow us to set up a local development environment where we can scan for secrets before we commit them to the repository. This saved us a lot of time.

It took us a while to get new patterns introduced into the pattern reporting process. If there is a way to automate this process so that we can include our own patterns in our repositories, that would be very useful.

The authentication process could be improved. A single sign-on system would be very helpful.

I have been using GitGuardian Internal Monitoring for one and a half years.

The solution is stable.

The solution is scalable, so we can create instances for each scan that we run. This means that we will never have any issues with load or performance. We have 100 end users the utilize the solution.

The technical support has been very helpful. The system is also pretty intuitive, so we haven't had to contact them very often.

Positive

We have seen a 10 percent return on investment. Resource-wise, creating a secret once it has been detected is a significant undertaking. Early detection has saved a lot of time, and I think there would be various penalties. Theoretically, if we continued to explore secrets, we could also save and compromise.

I compared the solution to a couple of other solutions, and I think it is very competitively priced.

I give GitGuardian Internal Monitoring a seven out of ten. The solution is really good, but the false positives that we had to work with lower the solution's overall score.

When we first started using the solution, we had to address some areas quickly. We had pushed through some public-facing features because we wanted to start working in the open. However, this prompted us to realize that we weren't quite ready to do that. So we had to make all of our clusters private again, or as private as possible. The thought of working in the open had to be reviewed at the start.

The solution does not require maintenance. It is used extensively and is part of our security check pipeline. It is included as part of the pipeline in any repository that is created. It is also included in the repository itself. Each project is included as a pre-commit process. Additionally, it is included in our deployment pipeline because it is well integrated into our productivity tools. 

Secret detection is a very important part of a security program for application development. It gives us the confidence to commit our work to a shared environment, especially if we want to make it public. Secret detection helps to ensure that confidential information is not exposed.

For those using an open-source tool, I would suggest pointing out what sort of support they might need. If they're comfortable using it on their own, then that's fine. But if they need support, it would be helpful to have a support package available.

People should do a proof of concept first because the way it will be configured for them might be different. I don't know if we can figure it out for sales for another organization. So, having a proof of concept to fully understand how it will work best for them is useful.

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.

We use GitGuardian to check standard configurations and scan for possible leaked secrets. Developers and software engineers sometimes commit to AWS keys, login credentials, SMTP databases, and other secrets.

Given the size of our operation, there's a lot of work to do on the security side in GitHub alone. GitGuardian enables us to avoid leaks in the source code on the GitHub side and helps devise a plan to fix them. Sometimes it doesn't find the leak, but it identifies the type of leak. The solution typically does an excellent job on that part. We can locate the crucial leaks and try to remediate those first. GitGuardian makes the job easier and faster.

It improved the coordination between developers and security personnel. Having a top-down mindset is not so great in terms of security. We have some roadblocks that get in the way of security best practices. GitGuardian's features help us to improve that. People need to improve their mindsets as well. 

We don't have a security team. The company doesn't have this in the core. We began implementing security in our code with GitGuardian, so we don't have a baseline to compare it to. We had nothing, and now we have GitGuardian for GitHub. It works pretty well and helped us to improve for sure. The time-to-remediation depends on the software engineers. We do not do the remediation; they prioritize as they want, so that's the mindset issue again. 

GitGuardian helps us to quickly prioritize remediation. At the same time, we need to work on internal policies regarding what engineers should do. They do not prioritize remediation as much as we think they should. This is a company problem. We didn't have as much emphasis on IT security, cybersecurity, or DevSecOps before we started doing this. We are trying to change their mindset and show how dangerous it could be if secrets are leaked.

We didn't require much preparation to use GitGuardian except for a one-hour training session with GitGuardian. The tool is pretty easy to use and has nice consoles. In one or two hours, we are ready to utilize the tool. The rest was checking configurations and reading documentation. We had to read up on features like single sign-on and how to note a secret leak as a comment in the pull request.

The entire GitGuardian solution is valuable. The product is doing its job and showing us many things. We get many false positives, but the ability to automatically display potential leaks when developers commit is valuable. The dashboards show us recent and historical commits, and we have a full scan that shows historical leaked secrets.

I would rate the accuracy an eight out of ten. We get false positives, but it's not because the tool is working incorrectly. Our software engineers commit things like the API key because they know they're unimportant. We consider them false positives because they are not real leaks. The false positive rate is low and will probably improve with time. 

The AWS secrets tool and ggshield have the same functionalities, but I'm not sure how they do everything behind the scenes. GitGuardian has good tech knowledge, but we still see too many false positives. We don't have a granular way to tell GitGuardian on the SaaS side to ignore specific secrets. We have to filter everything after it's done.

GitGuardian has single sign-on integration, which we implemented to make tasks easier for everyone. With SSO, we can send a link to GitGuardian instead of creating a ticket for that. People couldn't engage correctly with GitGuardian before we implemented SSO.

GitGuardian could have more detailed information on what software engineers can do. It only provides some highly generic feedback when a secret is detected. They should have outside documentation. We send this to our software engineers, who are still doing the commits. It's the wrong way to work, but they are accustomed to doing it this way. When they go into that ticket, they see a few instructions that might be confusing. If I see a leaked secret committed two years ago, it's not enough to undo that commit. I need to go in there, change all my code to utilize GitHub secrets, and go on AWS to validate my key.

It would be helpful to have small instructions to show developers how to deal with an issue. They ask us what they need to do each time, but it's always more or less the same. GitGuardian could send them clear steps, so they can engage without needing help every time. 

I have used GitGuardian for around six months.

GitGuardian is stable for our use case.

We have almost a thousand report stores, and it scans correctly, so we don't face any scaling issues.

I don't remember the specifics of the contract, but we have a one-year license for a set number of developers. It's reasonably priced. 

I rate GitGuardian a ten out of ten. It's a user-friendly product that's ready to go. You don't need anything besides the initial onboarding training to use this tool. If you are concerned about your security and want something ready to go, GitGuardian is an excellent option for a fair price. I recommend it. GitGuardian is a better choice than an open source solution if you are serious about preventing leaks on GitHub and your developers lack security awareness.

Secret detection is one of the essential aspects of application development. Leaked secrets are the main reasons for getting hacked. Often, secrets are leaked by an employee searching and finding secrets they should not, or someone makes a private post public because they don't know the secrets were there. Many bad situations happen because developers don't know what they are doing or don't care. The company mindset needs to change, but we still have a long way to go. 

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 GitGuardian to detect secrets in our source code. Two security engineers use GitGuardian, and developers access it when they commit issues. We've had four developers who have accidentally committed something. We are currently using it extensively and plan to scale it to every new repository we add.

GitGuardian makes us more confident that our sensitive secrets aren't being leaked. I estimate our secret-detection rate is around three times as accurate as what we got with the previous open-source tool. In the past, we had to manually add regular expressions, etc. The other valuable thing is that it scans all Git history, so we can find old commits that might have sensitive information in them.

GitGuardian has probably increased the security team's productivity tenfold. It's hard to quantify. Using after-the-fact detection as an example, we didn't know about information in our Git history until we came across it. We went from nothing to an excellent solution for finding secrets in our Git history. It's also completely shifted the burden from our team to the development teams in terms of what to do when these issues arise again.

It's equivalent to a security engineer reviewing every pool request to look for secrets. We have dozens and dozens of pool requests and commits daily, and GitGuardian performs a security review of each commit. We couldn't scale by having one person perform all that work. GitGuardian saves the security team about four to six hours per incident.

It supported our shift-left strategy by reducing our overall operational burden. The developer receives a GitGuardian alert, and they're often aware of it and addressing the issue by the time I'm triaging it. 

I like that GitGuardian automatically notifies the developer who committed the change. The security team doesn't need to act as the intermediary and tell the developer there is an alert. The alert goes directly to the developer.

We haven't seen any false positives. I've been happy with the range of detected secrets, including SSH Keys, GCP, and Slack secrets. It comes with suggested remediation steps. It's handy because you're not left scratching your head trying to figure out what to do. The alert comes seconds after the commit or maybe a few minutes later, and the action you need to take is explicit.

It would be nice if they supported detecting PII or had some kind of data loss prevention feature.

I have used GitGuardian for nearly two years.

GitGuardian seems solid. I haven't noticed any issues.

GitGuardian is scalable. We've had multiple repositories come online since we started using it, and it handles them seamlessly.

I haven't had to work with support very much, but that is a positive sign that I haven't run into any issues. I don't think I've ever had to file a support ticket. 

We previously used an open-source tool called Bandit. It wasn't very good or automated like GitGuardian. We also used another tool for data loss prevention and detection in GitHub. That provided some overlapping features but wasn't as robust as the secret detection in GitGuardian.

Setting up GitGuardian is easy. I don't even remember setting it up. It was a simple "next, next, finish" installer. It was also easy to remove certain repositories from being scanned.

GitGuardian has significantly reduced the labor hours required to check codes for secrets. A leaked API credential can cost several thousand dollars in less than 24 hours.

The cost of the license is worth it. There aren't any additional costs. 

I rate GitGuardian Internal Monitoring a ten out of ten. Secrets are the keys to the castle. Once somebody has the password to a system, they can access it. I suggest trying GitGuarding on a public repository to see how easy it is to set up. GitGuardian has opened my eyes to how often these mistakes happen and how sensitive data can end up in your source control.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Positive

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

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

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

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

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

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

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

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

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

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

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