We use the GitGuardian Platform for internal security monitoring. Initially, we employed it to identify any secrets from our internal repositories that might have been accidentally exposed publicly and then expanded our use of GitGuardian to remove secrets from our private repositories, also.

Our company has grown through acquisitions. To address this complexity, we've integrated GitGuardian with our development teams. This allows them to identify secrets within any repository so they can be quickly remediated, ultimately enhancing the security of our codebase.

GitGuardian helps us prioritize remediation quickly. The alerting component is helpful because it lets people know immediately when something suspicious appears. Additionally, the code context feature is valuable as it shows developers exactly where the issue occurs in their code. They can even click a link to jump directly to that location in GitHub. These features significantly speed up the process for developers to identify and remove vulnerabilities.

GitGuardian effectively supports a shift-left security strategy. This is because it integrates directly with the code repository, allowing for near real-time feedback on potential security issues before code is merged into production branches. This early detection is highly valuable. Furthermore, GitGuardian's command-line interface provides another layer of convenience. Developers can proactively search for and address security concerns before pushing their code.

GitGuardian improves collaboration between our developers and security teams on remediation efforts. The centralized dashboard is tremendously helpful for managing across a multitude of teams and hundreds of engineers. It allows me to see the progress of each team. This visibility makes it much easier to communicate with them. For instance, I can identify teams that might need assistance or recognize those that are successfully reducing vulnerabilities.

GitGuardian has dramatically improved our ability to detect secrets by shedding light on previously hidden vulnerabilities.

Our security productivity has increased significantly. Simply by making this information readily available to developers, we've empowered them to take action. Previously, this wasn't easy, especially when dealing with inherited legacy code. Developers often wouldn't know where these secrets were hidden within the codebase. This improved visibility has made security issues much more actionable for our developers.

With over 6,000 repositories, GitGuardian's automation capabilities have saved us many months of research.

GitGuardian has reduced our mean time to remediation. This ability to track security issues and communicate proactively with teams undoubtedly means we can also remediate them faster.

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.

While they do offer some basic reporting, more comprehensive reporting would be beneficial in the long run. This would allow me to demonstrate the value of the product over time to continue to effectively budget for this subscription, especially as they add features that may come at an additional cost. I appreciate the improvements made to reporting over the past year, but continued development in this area will be appreciated.

We have encountered occasional difficulties with the Single Sign-On process. There is room for improvement in its current implementation. It works, but was not quite as smooth as the rest of the GitGuardian experience.

I have been using the GitGuardian Platform for one year.

GitGuardian is stable. I have not had any problems.

GitGuardian scales incredibly well. We bombarded them with a massive number of repositories, and they ingested everything much faster than I anticipated. This allowed for a swift evaluation process. Their ability to handle large deployments is evident, and I'm confident they support companies even bigger than ours.

The technical support team responded quickly and was able to resolve my issues the following day. There were no problems with their service.

Before implementing the GitGuardian platform, we lacked a solution to identify secrets in our code. This created a significant security blindspot for us.

The initial setup was straightforward. However, we did need to establish the initial connection between the repositories. This process went fairly smoothly overall. While connecting the repositories on GitHub was easy, it was a bit trickier on the Azure side. So, some preparatory work was required there. Once that was done, the internal monitoring setup was complete and went quickly. Additionally, we had to set up teams and invite members, but this also went quickly.

The deployment took a couple of days. The repository connections (6,000+ repositories) took an hour or two to fully populate. One person was required for the deployment.

The implementation was completed in-house.

GitGuardian is not inexpensive. It's one of the more expensive tools in our portfolio, especially considering its focused functionality. However, while it may not offer a wide range of features, it acts as a form of critical security insurance. It safeguards our most vulnerable points, and a data breach can lead to legal repercussions that can be very costly for years to come. In that light, the cost is warranted and rational.

After considering several options, we determined that GitGuardian was the most robust solution for our organization's needs.

We evaluated several open-source solutions for secret detection. We also considered other security tools with similar capabilities but found that those not specifically focused on secret detection fell short. These tools often treated secret detection as an afterthought, resulting in limited effectiveness. While they might identify some basic secrets, they lacked the depth and comprehensiveness of GitGuardian. This is why we decided to invest in a dedicated secrets detection tool.

I would rate the GitGuardian Platform 10 out of 10.

Concerning maintenance, there may be a rare exception that we need to enter into the platform when new repos are added, but these have been very infrequent. The tool requires very little ongoing maintenance, beyond what teams need to triage.

While there are open-source secret detection tools available, they can be limited. GitGuardian, with its dedicated development team, offers a more comprehensive solution. Their support, including responsive sales reps and customer service, ensures you get the help you need to keep your system secure. Open-source solutions often lack this level of dedicated support, which can leave you troubleshooting issues on your own. For critical security needs, the additional features and support offered by GitGuardian are a worthwhile investment.

It's critical to our application development security program to have a robust secrets management solution. This is especially important when we have a large development team. In such an environment, the risk of human error increases, often due to unintentional mistakes. People might forget things, miss something during development due to time pressure, and so on. However, even a single mistake can have serious consequences. Therefore, careful management of secrets is essential. It safeguards our relationships with vendors, protects our internal data, and offers numerous other benefits.

My recommendation is to prioritize setting up SSO as first step, before onboarding any other users, if you're planning to implement it. Do it first. That was the only real challenge we faced; trying to get it working later created some complications. The actual setup process of getting GitGuardian to scan our repositories was straightforward and fast.

We noticed a problem with developers putting secrets in their code, and we needed a solution for this. I had previously used GitGuardian in my own hobby projects, so I knew what it was all about. I was asked to look into alternatives to ensure we had considered every possibility, but we quickly found that GitGuardian was the right solution for our use case. The company has around 100 users.

Using GitGuardian has made developers more aware of secrets. The senior leadership at the company is impressed with how well GitGuardian works. We've also heard some good comments about how snappy the website is. We do not have a shift-left culture at our company, but we are moving toward it, and GitGuardian definitely helps with this.

GitGuardian has improved the collaboration between the security and dev teams. The developers have taken to the tool nicely and are using it efficiently. At the same time, it doesn't require any communication between the developers and the security team in terms of remediation because it's intuitive enough for the developers to know they need to fix an issue when they get an email notifying them about it. They also know how to fix it because GitGuardian shows that in the remediation steps.

The solution has greatly increased our secret detection rate. When we did it manually, it took about an hour to find 50. Now, we get around 250 in an hour, and they appear instantly when we sign in. It has improved the remediation time quite a bit. We're down to nine minutes now, which is a vast improvement compared to when it was a manual process.

GitGuardian has increased the security team's productivity by shifting the responsibility to the developers. We are almost never inside GitGuardian monitoring it. It's mostly when we need to do our weekly reporting. We generally leave it up to the developers to fix their code. That's just how the company works.

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.

GitGuardian encompasses many secrets that companies might have, but we are a Microsoft-only organization, so there are some limitations there in terms of their honey tokens. I'd like for it to not be limited to Amazon-based tokens. It would be nice to see a broader set of providers that you could pick from.

The company has only been using GitGuardian for a couple of months now, but I have used it for many years.

I rate GitGuardian nine out of ten for stability.

I rate GitGuardian ten out of ten for scalability.

I rate GitGuardian support ten out of ten. We had some issues with GitGuardian failing to detect some secrets. We contacted support. They resolved the problem swiftly and kept us informed throughout the process. They started the process of creating a new detection, and it's a new feature that they're working on.

I previously used some open-source solutions, but they were not quite on par with GitGuardian. An open-source solution is only as good as the developers maintaining it. The developers maintaining it are not paid to maintain it, unlike those who are paid to keep a commercial solution updated. The paid solutions are way better.

GitGuardian is a SaaS platform, so you don't need to deploy it. It's just a matter of onboarding users. It doesn't require any maintenance on our side.

We have only used GitGuardian for four months, so it's hard to calculate a return. However, it will save us a lot of headaches with the new EU regulations in the long run.

When we're talking about security, there is no price that is too high to keep a company safe.

I rate GitGuardian nine out of ten. A secrets detection program is one of the most critical things in application development. It's easy enough to implement GitGuardian, so you don't need to test it, but you can always go with a trial because you need to know if this is the right solution for you. It's so easy to get started with GitGuardian that you don't need to go through all the bureaucracy.

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.