We use GitGuardian to detect secrets that have inadvertently been committed to our source code. GitGuardian monitors every Git push and commits we make, and it analyzes the files, looking for things like access tokens, passwords, session ID cookies, etc. If that happens, GitGuardian raises a ticket in our internal ticketing system, and we remedy it.

When we first deployed GitGuardian, we went back through all of the commits that we did over the course of the last five or six years that the company existed. It immediately found more than a hundred. We detected all sorts of secrets in those repositories. It had a pretty substantial impact from the first day. That was during our trial run, but now it's incorporated into our deployment pipelines. The impact is still there, and it's still tremendous. It's probably not as instantaneous or the same avalanche of detections that we saw on day one. That was impressive, but we don't get that anymore. It has been a constant trickle of tickets.

GitGuardian helps us prioritize remediation. You need to incorporate it into your existing processes, but GitGuardian provides you with the flexibility and the tools. For example, in our environment, we implement ticket creation through webhooks. We have some logic rules stating that our production repositories are a higher priority than our dev or sandbox repositories. Our developers commit all sorts of weird things to those. GitGuardian gives you the tools to do that, but it may not necessarily do that right out of the box when you first deploy it.

To have collaboration between our security and dev teams, you need to have a detection. Previously, we did not have a functional equivalent to GitGuardian in our environment, and it introduced that process, so we could begin having that conversation. The security team is more focused on remediating to ensure that API token or password is invalidated as soon as possible after it was committed. Developers are more focused on why the secret was committed and environment variables to store that particular secret. The collaboration exists in our company largely thanks to GitGuardian.

A webhook creates a ticket in our internal ticketing system, and the ticket goes to the security guys. They look through it. They make sure the secret is invalidated and start that conversation with the developer to say that they committed this, so please don't do that again. That's the end of the story. We don't use 100 percent of GitGuardian's functionality. We are a fairly small company, so we probably don't need all of that. This simple approach works pretty well for a company of our size.

GitGuardian has improved our security team's productivity if we measure it in security incidents per week, hour, etc. Now, we have a separate stream of secret detection tickets going into our system. It's much better to have those during the deployment phase instead of discovering them after a breach or down the road.

It's hard to quantify the time saved. Finding a secret that was accidentally committed to a repo is like searching for a needle in a haystack. And you don't even know if the needle is in that haystack. Now you have something like X-ray vision that lets you see through that haystack and find right where the needle is. It unlocked a new angle on our application security process that did not exist. When a secret was accidentally committed to a repo, it could have been noticed by a security guy or another developer, or maybe not.

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.

GitGuardian had a really nice feature that allowed you to compare all the public GitHub repositories against your code base and see if your code leaked. They discontinued it for some reason about eight months ago, it was in preview and kinda exploratory phase, but for whatever reason, they chose not to move forward with it.

That is unfortunate because it immediately detected a leak of our company code that one of our contractors committed. They leaked our intellectual property into one of their public reports.

I have used GitGuardian for 14 or 15 months.

I have never experienced a single instance of downtime, but I don't sit there 24/7. It's just a useful thing that is sitting in the corner humming and doing its thing. I have never noticed any outages.

We are a small company, and it performs beautifully for a company of our size, but I think it will also perform well for a company 20 times our size. If we're talking at the scale of a company the size of Google, then I don't know.

I rate GitGuardian support eight out of ten.

We didn't have a secret detection solution because it's a fairly new area. However, we also use Snyk to supplement GitGuardian. It does things that GitGuardian doesn't do, like dependency detection and static code analysis. GitGuardian is also doing things that Snyk isn't, so the two complement each other nicely.

GitGuardian is a SaaS solution, and the integration process is pretty straightforward. It's similar to other things you integrate with our repository and version control systems. It doesn't require any maintenance. It adds new repositories automatically.

The purchasing process is convoluted compared to Snyk, the other tool we use. It's like night and day because you only need to punch in your credit card, and you're set. With GitGuardian, getting a quote took two or three weeks. We paid for it in December but have not settled that payment yet.

It's also worth mentioning that GitGuardian is unique because they have a free tier that we've been using for the first twelve months. It provides full functionality for smaller teams. We're a smaller company and have never changed in size, but we got to the point where we felt the service brought us value, and we wanted to pay for it. We also wanted an SLA for technical support and whatnot, so we switched to a paid plan. Without that, they had a super-generous, free tier, and I was immensely impressed with it.

When we acquired GitGuardian, I compared it to GitHub Advanced Security, an additional premium subscription from GitHub that you can purchase on top of your existing one. It claims to do similar things to what GitGuardian does, but GitGuardian is far superior in terms of the types of secrets it can detect.

I'm not sure if GitHub has caught up since then. I picked GitGuardian over GitHub Security because it had better functionality. Also, not all of our repositories are in GitHub. We also used Azure DevOps. GitHub Advanced Security sort of locks you down within that GitHub sandbox. With GitGuardian, we could scan both GitHub and Azure DevOps repositories and have identical functionality across the two. If we implement a policy in GitGuardian, we would know that it equally applies to secrets committed to both systems.

You also have the option of open-source solutions, but one of our core principles is to lean heavily toward solutions that are not self-hosted, whether it's in the cloud or on-premises. To have an open-source solution, you need to run it somewhere and maintain it. GitGuardian is a software as a service. You sign up and forget about it until your next detection. If a company wants to minimize administrative overhead, GitGuardian is a pretty much no-brainer.

I rate GitGuardian eight out of 10. Secret detection is critical to application security. You might assume that your developers have a security mindset. Many don't. Sometimes, it isn't even a mistake. They might not realize exactly what they are doing and the amount of damage that could occur because of what they commit to a repo.

When you implement GitGuardian, there will be an influx of detections if you're developing any software that connects to anything with a database, third-party REST API, etc. I recommend looking through the initial list of detections and identifying the most susceptible projects or repositories. Also, look at the developers who produce the most detections. Those are the people who lack a security mindset. Identify the high-risk category of developers.

We utilize GitGuardian to scan for secrets within our codebase. Our implementation includes pre-receive and pre-commit hooks, dashboard scans, and CI/CD integration within GitLab.

Secret detection is pivotal for development security, ensuring no secrets exist in packages, libraries, dependencies, or code. Even with a locked-down application, explicit permissions could grant easy access to the environment and connected resources. GitGuardian serves as an essential tool for every development team.

GitGuardian aids in prioritizing remediation efforts by promptly notifying us of reported issues. This informs our approach; we prioritize valid reports over invalid ones or those that failed checks. Automation plays a significant role, swiftly addressing invalid reports and saving valuable time.

The solution aligns with our shift-left strategy, empowering developers with security responsibilities through pre-receive hooks that act as security controls. Developers can quickly identify secrets, enhancing security awareness at the development level.

GitGuardian significantly reduces manual work through automation, streamlining incident resolution processes and allowing proactive measures like permissions revocation. While not fully automated, leveraging automated solutions has notably increased productivity, enabling us to focus more on governance and essential tasks.

Our secret detection capabilities have improved dramatically with GitGuardian. Initially facing over 10,000 incidents, we reduced them to 2,700, marking a 60 to 70 percent increase in detection efficiency.

Validation features save considerable time by eliminating the need for manual verification, allowing us to focus on remediation. While accuracy varies based on use cases, we've encountered only a handful of false positives, with the false positive rate correlating strongly with the number of secrets present.

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 GitGuardian hook and dashboard scanners are essential components that should seamlessly integrate to provide comprehensive security coverage. However, we've encountered instances where discrepancies arise, with the dashboard scan detecting issues not reflected on the hook. This inconsistency requires fine-tuning to ensure efficient detection and resolution, as we aim to avoid unnecessary time wastage.

Moreover, the historical scan feature could benefit from improvement. Occasionally, it fails to efficiently track changes in updated histories, leading to delays in data history updates. This can be frustrating, especially when the reported secret remains unchanged or changed in history. Addressing this issue is crucial to alleviate the burden on the team and streamline our workflow. We hope to see enhancements in this aspect from GitGuardian.

I have used GitGaurdian for two years.

Earlier, we had some challenges and problems with the dashboard crashing, but there have been many improvements since then. We haven't seen any crashes lately.

The scalability depends on the deployment model. Our engineers understand how to deploy the solution directly. We have two environments: production and dev. We haven't seen any major hassles, and it doesn't impact the development workflow.

I rate GitGuardian support nine out of ten. GitGuardian support has been great. They respond fast. If something requires investigation, they also resolve the issue quickly. Recently, we had to upgrade because of a bug. They were happy to help us.

I used Trufflehog at a previous company. It's hard to compare the two. Both have their strengths and weaknesses. I've used a couple of the other solutions, and GitGuardian stands out.

It was straightforward. We had deployed it on EKS with nodes for dashboard and other aspects of the app.

It was a joint effort. Their support engineers were very skillful and did provide all required help.

Every company has a budget to spend on security tools, so it depends on what you want to spend on security at each stage in their maturity walk. You can have a vulnerability in your code with a firewall in front, but you don't want an application exposing secrets. An attacker knows how to crawl your application and extract information. It depends on how much you want to prioritize the cleanness of your code from a secrets perspective.

We looked at a few other products but primarily chose GitGuardian because of the price. It also has some advantages regarding dashboard maturity and the number of available integrations. We also like the auto-validation and the way the pre-commit hook works. It was also a lot easier to implement GitGuardian.

I recommend open source for other things but not secrets detection. There's an inherent vulnerability to an open source solution that could leave your secrets exposed.

I rate GitGuardian Internal Monitoring nine out of ten. Before deployment, it's crucial to thoroughly understand your environment. For users of public cloud services, ensuring compatibility with GitGuardian's features is essential to maximize benefits. While the SaaS solution offers simplicity, our air-gapped internal deployment had minor restrictions on available features. Despite this, we opted to continue with GitGuardian as it satisfied our core needs.

Understanding your environment and version control system is paramount. Determine your implementation approach, considering options like starting with dashboard scans rather than hooks, which I don't recommend initially. Beginning with dashboard scans on your version control system, such as GitHub, and conducting historical scans is advisable. As teams become more acquainted with the tool, gradual implementation of more advanced features like hooks can be considered.