We use GitGuardian Public Monitoring for code that is exposed in public.

GitGuardian Public Monitoring's detection capabilities are good. I'm still learning the ropes of using some search techniques. However, it's impressive how we can find information even if it's been deleted. That's helpful!

The more I use GitGuardian Public Monitoring, the easier it becomes to identify false positives. When I started this role less than a year ago, it was my first time working with code. It took some time to adjust. However, I'm now getting faster at reviewing alerts and determining the risk. I can often tell if something is a genuine threat or just someone testing something out. In those cases, I can quickly confirm with the developer whether it's an actual secret. Overall, my detection skills are improving. This helps me filter through alerts more efficiently. When the system was first implemented last May, we had a lot of data to sift through, and GitGuardian Public Monitoring has made that process much faster.

GitGuardian Public Monitoring helps us prioritize remediation tasks efficiently. It allows me to assign severity levels to detections. I can mark high-risk ones for immediate attention while leaving others in their triggered detection status. This way, I can easily filter detections later based on the assigned severity levels that are set by me or others to quickly find the ones I'm currently working on or those requiring the most critical attention.

The Public Monitoring Explore feature is a powerful tool. It allows me to create searches beyond our usual parameters. They even have a helpful cheat sheet available. I've found it very useful, uncovering surprising information that required further action. Overall, it's a valuable resource.

The Explore feature has been very helpful in uncovering potential issues that we can address immediately. These are issues that wouldn't have been identified through our regular alerts. In this way, Explore allows us to delve deeper and identify additional exposures and potential risks that we might otherwise miss.

I'm currently using GitGuardian Public Monitoring to detect secrets and identify any exposure to our company's intellectual property code. That's the extent of our use case for now. I'm aware that GitGuardian is planning to release additional features, such as public Postman monitoring, which I'm very interested in. I believe we'll be incorporating that functionality in the future. As for honey tokens, I haven't had a chance to use them yet, but I'm familiar with the concept. I think utilizing honey tokens could also be beneficial, potentially helping us gauge how quickly exposed secrets are exploited. We initiated a trial of GitGuardian Public Monitoring last May, which lasted for several months. While it generated a significant number of alerts initially, which could be overwhelming, we were able to identify valuable findings during the trial period that demonstrated the product's worth.

GitGuardian Public Monitoring improves our overall security visibility by eliminating blind spots. This helps us identify potential security risks that might otherwise go unnoticed for extended periods.

GitGuardian has been very effective in helping us monitor our developers' public activity. I'd like to spend more time exploring its capabilities and using it to its full potential. While I'm confident we're currently up-to-date, there are likely additional features I haven't discovered yet. However, I trust GitGuardian to notify us promptly of any new threats that emerge. Overall, I'm impressed with its ability to catch a wide range of issues.

Initially, users were unresponsive to our emails and questions, and they often became defensive. However, with increased interaction, I believe they're starting to understand that our primary goal is to comprehend and document the exposed information to help improve our meantime to remediation.

GitGuardian has been very effective in detecting and alerting us to security leaks quickly. It's identified issues that we likely wouldn't have caught ourselves, either because we lack the resources or simply weren't actively searching for them. This has been helpful because it allows us to address these leaks promptly.

The Explore function is valuable for finding specific things I'm looking for. I also appreciate that critical or high-priority issues are sent directly to my email. This ensures I'm notified even if I'm not actively checking the website.

I'm excited about the possibility of Public Postman scanning being integrated with GitGuardian in the future. Additionally, I'm interested in exploring the potential use of honeytokens, which seems like a compelling approach to lure and identify attackers.

I have been using GitGuardian Public Monitoring for less than one year.

I've never had any problems with GitGuardian's stability. The only issue I ran into was when our free trial expired. Until we renewed it, I couldn't access the product, which caused some delays with my follow-up tasks. It's important to note that this wasn't a problem with GitGuardian itself, but rather a limitation of the free trial. Overall, I've been very impressed with the stability of their product.

Right now, we're only considering using GitGuardian for public GitHub repositories. While it offers additional features, we don't have a current need for them. It's a powerful tool with capabilities we might explore in the future, but for now, our focus is on its basic functionalities.

The customer support has been very responsive to our requests and inquiries. They are very quick to take action, and I learn more about the product each time I reach out to them. They have been great to work with.

The technical support team is very responsive and thorough. Whenever I have a question, I simply email them. Even if I don't send it to the right person initially, they'll be sure to forward it to the appropriate support agent. When I receive a response, it's often more detailed than I expect. They explain not only how to solve my specific issue, but also provide additional information that helps me better understand and utilize the tool. This feedback allows me to learn a lot and improve my skills.

We have used other solutions to find secrets in the code. However, we did not have a specific tool to look for public exposure of our code.

We're still deploying GitGuardian. It's proving to be more complex than anticipated. I suspect this is due to internal processes rather than GitGuardian itself. When I tested it out, it was quite straightforward to get started. However, the onboarding process seems to involve a lot more bureaucracy.

We have half a dozen people involved in the deployment.

The implementation was completed in-house.

I would rate GitGuardian Public Monitoring nine out of ten.

Once deployed GitGuardian will only require minimal maintenance.

For organizations that don't prioritize secret detection, deploying honeytokens can be a wake-up call. They'll quickly see the importance of implementing secret detection measures.

Secret detection is crucial for a security program aimed at application developers. Exposing secrets in code is akin to giving away your house keys.

I recommend evaluating GitGuardian Public Monitoring through a trial, similar to our experience. This was very helpful in understanding the system, developing workflows, and determining how we could best utilize it. Unfortunately, when I was assigned to work with it, I didn't receive any initial training. My manager simply informed me that we would be using the tool. While I was able to learn it independently, a demo or introduction from GitGuardian beforehand would have been beneficial. This would have allowed me to explore the functionalities before diving in and figuring things out on my own.

I recommend GitGuardian Public Monitoring to others.

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.