Recently, a new feature was added that I had been requesting for a while, and I'm super excited about it! This feature allows us to filter incidents by team within the available filters. This is incredibly helpful because before, we could only search for individual repositories. Some of our teams have hundreds of repositories, so filtering by team saves a lot of time and effort.

The ability to create teams is also valuable for a large organization like ours. Some vendors struggle to provide enough user organization layers, but GitGuardian excels in this area.

The core incident management features are also fantastic. For example, alerting people via email about new incidents is crucial for staying on top of things. Additionally, the dashboard allows users to mark the status of secrets, providing a convenient location to review everything.

Another area where GitGuardian shines is the breadth of secret types it covers. They can identify a vast number of secrets out-of-the-box, with minimal false positives. This means they effectively distinguish real secrets from irrelevant data, saving us time and effort. I also appreciate the context provided for developers. When they investigate secrets, they can see exactly where those secrets reside in the code, allowing for quick fixes.

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.

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.

The most valuable feature is the alerts when secrets are leaked and we can look at particular repositories to see if there are any outstanding problems. In addition, the solution's detection capabilities seem very broad. We have no concerns there.

In terms of the accuracy of detection and the solution's false positive rate, we had to make some adjustments, but now that we've made those adjustments we're very happy with where we are.

We have also used the dev in the loop feature and it works well when it comes to remediating an incident. For collaboration between developers and security teams it's very good.

I like GitGuardian's instant response. When you have an incident, it's reported immediately. The interface gives you a great overview of your current leaked secrets. It's easy to reduce the false positive rate because we can customize the detection rules to be as granular as we want. We can set up rules to say certain things should never be detected. We're happy with the false positive rate, but we notice a lot from our test certificates in our code. There is no clear way to define if a certificate is a test certificate apart from the name. I think it's a good thing that they have these false positives rather than false negatives.

We use some of the playbooks. They help us prioritize security incidents. We're only using a limited set at the moment, but the ones we use help us identify and prioritize security incidents. 

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

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

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

GitGuardian offers a range of features that align perfectly with our requirements. With internal policies in place to prevent secret exposure, especially concerning our code hosted on GitLab, GitGuardian's pre-receive hook stands out as a crucial feature. By activating this hook on the remotes, it effectively blocks commits from being pushed to the repository, ensuring that secrets never reach GitLab and remain protected from exposure.

The tool provides comprehensive coverage, including classic technologies such as SMTP credentials, along with Slack tokens and AWS secrets in our specific use case. Its ability to manage various types of secrets, including database connections, APIs, and RSA keys, streamlines our workflow by consolidating detection efforts. This consolidation saves us considerable time, eliminating the need for back-and-forth verification with the team. Once a valid issue is identified, we can promptly escalate it to the team for remediation

The most valuable feature of GitGuardian is its core secret detection mechanism. It covers a broad range of technologies. The detection accuracy is extremely good. It correctly detects in about 99 percent of cases. Every false positive we've had wasn't an actual false positive. It was a case where a developer copied a sample code from somewhere, including a dummy password or session ID.  GitGuardian may trigger this, but I think that's a good thing because we know it's there, and it is alert.

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.

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

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.

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

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.

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.

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.

The solution offers reliable, actionable secrets detection with a low false-positive rate. That low false-positive rate was one of the reasons we picked it. There are always going to be some, but in reality, it's very low compared to a lot of the other, open source tools that are available.

Accurate secrets detection is notoriously challenging. GitGuardian provides a rich and easy-to-use interface that enables engineers or security teams to jump on issues and manage their remediation. It offers functionality to prevent issues from creeping in.

GitGuardian has pretty broad detection capabilities. It covers all of the types of secrets that we've been interested in. For example, it covers AWS Keys. There isn't anything specific that it couldn't detect in the stack that we use. That breadth is also evident because we have a lot of different languages that it supports as well.

The "detector" concept, which identifies particular categories or types of secrets, allows an organization to tweak and tailor the configuration for things that are specific to its environment. This is highly useful if you're particularly worried about a certain type of secret and it can help focus attention, as part of early remediation efforts.

The ability to check for secrets as part of pre-push hooks is fantastic, as it helps identify issues before they reach the main codebase, and that was the ultimate goal for us.

Another positive feature is that it quickly prioritizes remediation. That quick feedback loop is very helpful. Based on the detector that finds the problem, you can use that to almost rate the issue. For example, if it's an AWS Key, you would rate it very high so you can jump the prioritization accordingly, once you've got those alerts triggered. And issues can be assigned to individual developers to help gain traction on fixes.

And the Dev in the loop feature, which our developers use, is pretty important when it comes to remediation because that's what helps make the engineer responsible for having done the thing that needs remediation. This feature is effective in terms of helping collaboration between developers and our security team. It's automated, to a large extent. The "in the loop" feature will notify the engineer of what's happened and will give the security team oversight, but it deliberately puts the onus on the engineer to fix it.  

In addition, the out-of-the-box reporting mechanisms allow for easy data presentation to both specific engineering teams and senior leadership.

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

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

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

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

There are also a lot of integrations. 

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

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

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

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

The scope of GitGuardian's detection capabilities is better than anything else. When they give you a description of what happened, it's really easy to follow and to retest. And the ability to retest is something that you don't have in other solutions. If a secret was detected, you can retest if it is still there. It will show you if it is in the history.

It also helps to quickly prioritize remediation. They provide a score and, although it depends on the context, because what GitGuardian might say is a high-risk vulnerability might not be for us, it does the job properly. The scoring it gives is amazing.

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.