GitGuardian Platform Reviews

My use case for the GitGuardian Platform is application security.

My impression of the GitGuardian Platform's capability to detect secrets in real time is actually really amazing, because it lets us protect or block the pipelines in which we deploy new applications so we can acknowledge when a secret is hardcoded in a repository, or when we have already hardcoded secrets within templates in our repos.

We adopted it a year ago, and it has been doing great in our teams, especially for developers. The impression so far has been good.

The severity scoring has helped us in incident management because it is doing the correct job. We got many secrets leaked within our platform and it was making the correct warnings regarding that particular secret, as we had a hardcoded Google Cloud API key. It was marked as a critical severity, so we had the chance to correct it, regenerate that secret and work again on not hardcoding secrets within our code.

GitGuardian's public leak detection significantly enhances our organization's data security by continuously monitoring public repositories. It allows us to proactively identify accidental exposures of sensitive credentials or secrets.

Regarding the exceptions in GitGuardian Platform, we know that within the platform we have a way to accept a path or a directory from a repository, but it is not that visible at the very beginning. You have to figure out where to search for it, and once you have it, it is really good, but it is not that visible at the beginning. This should be made more exposed.

The documentation could be better because it was not that comprehensively documented. When we started working with GitGuardian Platform, it was difficult to find some specific use cases, and we were not aware of that. It might have improved now, but at that time, it was not something we would recommend.

I have been using the GitGuardian Platform for almost a year now.

From 1 to 10, I rate the stability of the GitGuardian Platform a 10, as there are no downtimes.

I would rate the scalability as a 10, since we did not have any problems.

For technical support, I would give a solid 10. They have someone who speaks Spanish, which made it easier for us.

I am comparing it with Advanced Security from GitHub and Cycode.

Two of us were involved in the deployment process.

It took a week to deploy the GitGuardian Platform, just to standardize the process.

Two of us were involved in the deployment process.

Regarding return on investment, we have actually saved time and resources because before having GitGuardian Platform, we had two or three people working in every repository looking for secrets with open-source tools. It took a long time to find secrets or many patterns, and at the time, we had to configure our own patterns to find them. I cannot specify the exact return on investment, but I can surely say that we have saved significant time and resources, particularly in terms of people and automation.

I would compare the GitGuardian Platform to other solutions or vendors on the market as being easier to use, but it is not integrated with the CSM that we are using right now. That is the difference. It is easy to use, but it could be easier.

We are customers in our company's relationship with the vendor.

I work primarily with the CLI, focusing on pipelines and automations rather than the platform itself. The platform has remained almost the same within the year that we have been working with it.

We are not utilizing the automated playbooks yet.

I cannot determine if the pricing is cost-effective.

The vendor can contact me if they have any questions or comments about my review.

I have rated the GitGuardian Platform a 10 out of 10.

I use GitGuardian Platform to ensure that there are no secrets committed, such as hardcoded values, database credentials, API keys, or any secrets that could be exposed to external users of our application. To maintain security and data accuracy, confidential data should not be shared with other platforms. GitGuardian Platform checks our local code first, then it passes through our CI/CD pipeline as well. When we push code to GitHub, it scans and sends a report via Gmail, so we have to fix those security vulnerabilities.

The best features of GitGuardian Platform are that it detects everything being pushed through the repository and scans everything comprehensively. It checks the possibility of exposure, so if there are API keys or database passwords being used, it warns us to either remove, rotate, or replace them, ensuring they should not be present in a GitGuardian Platform scan.

Our company has seen many benefits from using GitGuardian Platform, especially since there have been numerous cyber attacks and security threats in the last two to three years. Our company has remained very safe in this regard because we need to secure our data effectively, being in the insurance reinsurance sector. GitGuardian Platform ensures our data is protected by regularly scanning the repositories and sending us reports on how to fix vulnerabilities, keeping us safe from cyber attacks.

GitGuardian Platform could improve by providing a more user-friendly UI with tips or solutions. With AI advancements, they could offer AI-specific solutions in scanning reports, suggesting fixes for GitGuardian Platform incidents, and even permit automated fixes, which would significantly reduce the developer's workload.

I have been using GitGuardian Platform for the last one year.

Stability and availability of GitGuardian Platform are commendable; it is stable and available.

It is stable because when I push changes, it scans immediately, confirming fixes. There is no downtime during scanning, maintaining stability and availability.

I find support good since we have not needed much help from them. The guidelines provided are sufficient for guiding us on what to fix.

There are many tools in our organization for similar purposes, but GitGuardian Platform is specifically for exposing secrets. We also use Snyk for vulnerability scanning, among others, though I cannot recall all of them.

The decision was made by my organization, not me, so I am not sure about the parameters they considered before choosing GitGuardian Platform.

GitGuardian Platform prioritizes incidents in our workflow through automated validity checks. There are high risk, low risk, and medium risk incidents raised, and the infosec team prioritizes them and approaches us, the developers who pushed those changes, to fix them accordingly.

GitGuardian Platform's public leakage detection influences our company's data security as a precaution. We are not sure if data might be exposed, but taking this precaution by scanning the repositories is crucial. A cyber attacker just needs one piece of data, so we ensure at least that one thing is secured. It is about cyber attack prevention, ensuring all our data remains safe.

It rates the effectiveness of severity in incident management based on the severity of the change. This allows us to address the most important ones first. It checks what has been pushed from the code, raising a high-level vulnerability if database-related passwords are involved and reports it urgently. For low-level issues like hardcoded values for APIs, it is reported accordingly based on priority.

I use GitGuardian Platform's automated playbooks for scanning. Productivity-wise, these playbooks help me know if I am going to push code with secrets. I am aware now, so I intentionally avoid that, ensuring I write good code. It increases my productivity by helping me fix issues proactively. If GitGuardian Platform were not here and vulnerabilities were discovered later, there could be severe consequences. Currently, that impact has been reduced, minimizing our efforts significantly through early precautions.

Our organization is currently innovating on the AI side, which includes creating a custom agent to fix vulnerabilities, similar to GitHub Copilot. This agent automates changes required based on GitGuardian Platform scanning, closing incidents directly. This support reduces our efforts and timelines.

Fixing vulnerabilities now takes approximately 60% less time. If fixing took ten days, I now do it in six. I am not sure about multi-vault integration because I am just a developer using it to fix my code changes. I am not sure if I am using GitGuardian Platform's Honey Tokens feature. I would rate this product an 8.5 overall.

GitGuardian Platform is a security tool preventing the exposure of secrets. It is particularly valuable as a tool because it doesn't just identify exposed security issues, but works as a platform that gives developers an intuitive and easy way of reacting to and fixing the issues.

GitGuardian Platform captures all the major secret types we care about. It tends to be a bit overzealous in some categories, but it covers all the ones that we want to track and keep an eye on. It has great coverage over those.

GitGuardian Platform has helped save significant time for the security team by eliminating the need to seek out development teams and work with them on exposed secrets, as much of this is now handled proactively. The built-in process for developers interacting with exposed secrets saves them time fixing security problems before returning to their tasks. We can also provide customized remediation guidelines to developers.

Automated validity checks are super critical for us. If something is confirmed as valid in the platform, we know there is some externally accessible value that's exposed somewhere. It's then the top priority for us to engage in. It also gives us a lot of confidence. When the development teams come back and say that they have fixed it, GitGuardian Platform confirms that.

We rely a lot on GitGuardian Platform's self-service functionality so that developers handle incidents without us having to take action. We don't rely on automated severity scoring for incident management. While the severity rating is decent, we focus more on the validity feature and detector categories than on GitGuardian's high-risk ratings. We have customized remediation guidelines by providing specific internal context for handling exposed secrets. We use GitGuardian's integrations with other tracking platforms, but we don't have everything funneled into Jira. We use our own prioritization to see which ones we want to funnel into Jira.

The platform has given us a clear picture of the historical landscape, showing what has been fixed versus what remains hidden in historical data. This clarity has been helpful in planning security measures around issues that don't get self-healed.

We have it scanning our GitHub environments, Atlassian suite (Jira tickets, Confluence), and Slack messages. That gives us a nice coverage across the business.

The validity and self-healing playbook features of GitGuardian Platform is one of the most useful features for us. It automatically reaches out to developers for any leaks, notifying them immediately via email. We have Slack notifications set up, allowing developers to respond, provide feedback about sensitive values, and self-close issues by attesting completion on the platform. A high number of our exposures are remediated by developers before security needs to step in, as the self-healing playbook process engages them automatically. This results in issues being resolved within minutes, saving significant effort from the security team in tracking down or communicating with developers.

The analytics in GitGuardian Platform have a significant opportunity to better reflect the value provided to security teams and demonstrate actual activity occurring. While the self-healing capability and proactive developer actions are important features, the analytics do not provide information around this activity. They only track actions inside the platform when security team members assign themselves to issues and respond. The self-healing activity by developers isn't reflected in the analytics, requiring us to collect this data ourselves. This presents an opportunity for them to better showcase their developer-first remediation mindset.

We have been using GitGuardian Platform for approximately nine months.

It's a stable platform, we don't often have to think about it. The SaaS platform has experienced two significant moments of downtime or instability in the last six months, requiring notices and retrospectives. We also run a self-hosted cluster which has not experienced these issues, though we've faced some challenges upgrading Kubernetes that required support assistance to prevent internal downtime.

It is scalable. I would rate it a nine out of ten for scalability. 

My product security team administrates the platform, with a few other security people accessing it. Access to respond to incidents is deployed for every engineer. Team-based provisioning is not yet supported with SCIM, which makes team-based grouping a hassle, so we do not use it.

I would rate their technical support a nine out of ten.

Positive

We were using a home-grown solution. 

The initial setup of the self-hosted cluster was moderately complex. We faced some issues because of the environment we had. We had to fix some installation errors and bugs in their Helm configuration.

In terms of deployment model, we self-host a cluster out of necessity. We have an internal GitHub Enterprise server. We self-host GitGuardian Platform to connect to that environment. We also use their SaaS version for Slack and Atlassian integrations.

We implemented in-house.

The majority of our incidents for critical detectors and important secret types are remediated automatically or proactively by developers through GitGuardian's notification system, without security team involvement. It saves a lot of time for the security teams and the developers. It probably saves approximately 10 hours per week. Previously, we needed an extra 20% of our time focused on this subject area, which has now been saved because of this platform.

It's competitively priced compared to others. Overall, the secret detection sector is expensive, but we are happy with the value we get.

We evaluated other vendors on the market. The secret detection capabilities of most vendors are basically equivalent, capturing all major types of secrets. The management and administration of findings after scanning is what differentiates vendors. Many alternatives lack strong administration capabilities for security teams after finding detections. GitGuardian's dashboard, self-healing playbooks, and ways for the security team to monitor, track, and deduplicate detections make it easier to manage the program compared to competitors.

I would recommend GitGuardian Platform to other users due to the ease of management for the security team with the dashboard. It offers easy administration of results. The proactive self-service capabilities provided to developers remove the burden from the security team and enable faster remediation of exposed values.

My overall rating for GitGuardian Platform is an eight out of ten.

GitGuardian Platform serves as a security shield for our organization to prevent API keys and database credentials from being pushed to GitHub. Although we know we should not push credentials, anyone can make mistakes. GitGuardian Platform has a CLI tool called gg shield, which we have set up on our laptops. Since we already use Git version control with GitHub, the process is straightforward. Whenever we push code to GitHub, it scans the code and checks for API keys and database credentials. Even if credentials are commented out, GitGuardian Platform flags them because commented credentials remain readable on GitHub and can still be caught by bad actors.

The most problematic situation occurs when a developer pushes credentials to GitHub and then attempts to remove them by pushing again. The issue is that Git does not work that way. The credential still remains in our GitHub repository history. GitGuardian Platform rescans our GitHub repositories for API keys to address this situation.

I also use GitGuardian Platform in my CI/CD pipelines with GitHub Actions. Although we store credentials in GitHub secrets, sometimes people hardcode credentials by mistake. Once the CI/CD pipeline is working properly, we do not edit it much, so if someone hardcoded credentials and everything is functioning well, no one may even review it. That credential could remain exposed for months. Even though our GitHub repositories are private, we still use GitGuardian Platform as a security measure. As a backend engineer, DevOps engineer, and AWS cloud engineer at my small company, I understand what situations could occur and these are real scenarios we face. We must use this solution even though we all know we should not do these things. However, no one knows what can happen in the future.

The public leakage detection feature of GitGuardian Platform influences my data security positively. This addresses a problem that could happen to anyone. Since we have this feature, we have peace of mind that our credentials will not be leaked or pushed somewhere by an employee.

Sometimes, I have faced a specific problem. I work in the cloud and have cloud credentials. Our developers asked me to give them credentials for debugging on their local devices. If they push credentials somewhere and cannot communicate with me since I am the admin, that time gap becomes dangerous. GitGuardian Platform provides a good security measure for any company using it, though you cannot give it a specific percentage impact on the company.

GitGuardian Platform might work on their false positives. Sometimes it flags credentials that are not actually credentials, but this does not happen frequently since we always remove our credentials before pushing anywhere. We do not really encounter these flags.

I have been using GitGuardian Platform for around one year. I have been working at my company for one and a half years, and we started using GitGuardian Platform after approximately ten months of my tenure.

GitGuardian Platform has good stability.

GitGuardian Platform has pretty good scalability. Based on our usage, it is working well. Even our code repository works well with it, and I could say it is pretty scalable for us.

I have not ever contacted the technical support or customer support for GitGuardian Platform. We do not need to contact them since the platform is simple to install. It is just there for precaution. We do not need it every day since it is simply for the rare chance that someone will accidentally push credentials and then it flags them.

I have not ever used any similar solutions to GitGuardian Platform that I can compare it with. We simply use it and it is working well for us, so we did not switch from another solution.

The initial deployment of GitGuardian Platform is pretty easy. GitGuardian Platform has a YouTube channel with three to four-minute introduction videos that show step-by-step how to install it. They also have documentation, so the setup is simple and easy.

We are on the free tier of GitGuardian Platform. They offer a free tier, so we are using it for now.

The effectiveness of GitGuardian Platform's automated severity scoring in incident management is good. When an incident happens, the incident manager receives an automated severity score based on the credential type. In my case, we mostly have development environment credentials, so the severity is not much, perhaps around six or seven.

I did not use the automated playbooks of GitGuardian Platform.

GitGuardian Platform does not require any maintenance on our end.

I rate this review an 8 out of 10.

We use GitHub as our source code platform. When we shifted from on-premise version control systems, we identified a requirement for capable tooling that could both find secrets that were committed in the past, and prevent and alert on secrets that were being accidentally committed.

GitGuardian gives us a better understanding of what's going on in our source code. Persistent use of the platform has allowed us to highlight areas where we need to improve; eg. providing training so that people know what information should and should not be in GitHub. 

We've managed to use this data to improve practices related to where teams store their secrets, and have also been able to use it to understand where we might be lacking tooling. 

When a developer commits a secret or there's a particular pattern in a repository, we often ask them about why they did this. They may turn around and say that there's no better option at the moment because we don't have a platform to suit x, y, or z. We can use that information to then drive decisions around whether or not we need to look into improved tooling or patterns that our engineering teams can use to avoid storing secrets in their source code.

Automated validity checks are very helpful; we use them to prioritise incidents, as they give us a quick understanding as to which secrets are still valid. They also help us to confirm that token invalidation - which sometimes has to be done by another team or a third party - has worked as expected.

We also utilize some of the automated playbooks, specifically those around automatic incident closure, allowing us to spend less time making sure that the incidents closed by changes to code are getting closed out.

Instantaneous notifications connected to our Slack platform allow us to deal quickly with incidents if and when they occur.

One of the best features of the solution, though, is the ability to use pre-push hooks. Preventing our developers from committing secrets into their source code before they hit the remote GitHub servers is ideal; it can be quite challenging and time consuming to remediate and rotate secrets once pushed to the remote.

The reporting feature has improved quite a bit since we first used it around five years ago, with filters that allow us to set up quick groups of or collections of filters and statuses to determine which secret detections are still unassigned and which are new. It allows us to easily ship those off to the developers involved in those incidents to get them remediated.

We'd love to see notification updates in Slack, as the system does not provide feedback on updates to incidents, which can be problematic when developers resolve issues. 

ie. if a developer commits code that triggers an incident, the alert comes into Slack, but by the time someone looks at it through the Slack alerting channel, the developer might have gone and already fixed or closed the issue. There's no feedback loop back into the notification channel to show that it's been addressed. 

Another thing that would be good to see is some more metrics on the usage of the GitGuardian pre-push hooks. It would be helpful to see which GitHub users have or do not have the pre-push hook capability turned on. That would allow us to chase people and say that we noticed that you're making commits, but you're not using GitGuardian, and encourage them to install ggshield before an accident happens.

My experience with the solution started in November 2020, which is approximately four or five years.

It's generally quite stable.

There has been a little bit of downtime of late, and it has been reasonably impactful when it's not been scanning. We set up our repositories in GitHub with GitGuardian as a required check. 

We had an incident for about four hours  last week and another one about a month before that. Prior to that, it's been really stable. 

It handles all the repositories and commit activity we have.

I would rate their technical support an eight out of ten.

Positive

No

We didn't have to do much. They manage all of the backend for us. All we have to do is integrate it into our GitHub organizations, and doing that is straightforward.

The solution does not require any maintenance.

In-house.

It's challenging to quantify, but it has saved us from a bit of panic because we know the state of our source code. It's hard to determine what savings might come from having the tooling or not.

It's fairly priced, as it performs a lot of analysis and is a valuable tool.

We have tested it against other solutions, such as TruffleHog, the open-source solution, and found the GitGuardian Platform to be about significantly better in terms of detection capabilities. TruffleHog focuses on secrets that it can validate, but in an Enterprise world with lots of internal tools, APIs and platforms it can miss a lot of secrets.

The new multi-vault feature looks useful; we are planning to connect it up to AWS Secrets Manager and HashiCorp Vault. 

My main use case for GitGuardian Platform is secret detection.

Every time we open a pull request, it scans the pull request and ensures that we did not accidentally put a database password in a pull request. That process has worked very well for my team as it has caught several things, it is very helpful, and it is easy to use.

The best features GitGuardian Platform offers include notification directly to the engineer who created the pull request.

The direct notification feature has helped my engineers and my workflow overall by being effective. It is nice to know that no matter what happens, day or night, if someone puts up a change, they will get an alert, and the security team will get an alert.

GitGuardian Platform has positively impacted our organization as it helps us reduce the number of secrets that we would accidentally commit into source code. We have definitely saved time, as we do not have to go clean out Git history because we can just rotate the secret quickly.

I do not have real feedback on how GitGuardian Platform can be improved as I think the team does a good job.

I have been using GitGuardian Platform for four years.

My advice to others looking into using GitGuardian Platform is that it is a very quick win to set up and very easy to configure. I would rate this review a 10.

Our current use cases for GitGuardian Platform involve monitoring external and internal GitHub and GitLab, Bitbucket, and other code repositories that it supports for secrets.

The newest addition that we appreciate about GitGuardian Platform is the ability to create a custom detector, which we built and worked with the team, and that works very effectively.

GitGuardian Platform performs the capability to detect secrets in real time exceptionally, as it activates from the commit and can detect it immediately.

We utilize GitGuardian Platform's automated validity checks in some cases, and they seem to work effectively. We are still experimenting with them.

The multi-vault integration plays a key role in our secrets management strategy because we have multiple different vaults, and that works effectively.

GitGuardian Platform does what it is designed to do, but it still generates many false positives.

We utilize the automated playbooks from GitGuardian Platform, and we are enhancing them. We will probably stop using some of them, but we are building off of them. The one piece they do not include is contacting the person's manager or copying them, which we feel is necessary to prevent insider threat and other issues, but they do not have access to our hierarchy of employees.

We are not using the honeytokens feature of GitGuardian Platform.

Regarding improvements, there are two things we are working on with them. They have added charts, which is a new feature, but it is still not accurate. It has taken 4 to 5 months and it is fairly slow. We are looking for better metrics and audit data, wanting more features such as knowing which users are creating the most secrets or committing the most secrets, what repository, what directory, and who is not checking in secrets, which repo, user, or directory has not had any secrets committed. We want more metrics around both good and bad to see how we are performing.

I have been using GitGuardian Platform for 5 years at the company, and my team has been using it for 3 years.

There has not been any instability with GitGuardian Platform; it performs reliably.

Currently, what GitGuardian Platform is doing works effectively. It is quick and meets our needs. If we added more, I do not think that would really impact performance, so the scalability in that aspect is fine. I know they are trying to branch out and look for secrets in other types of tools, but I am not sure if we are going to use them for that or if that would impact performance or stability either.

I have contacted technical support previously, but we usually work through our customer representative directly, and they create the tickets for us.

We have one employee that primarily works on the deployment and configuration of GitGuardian Platform, and that took approximately a couple of weeks working directly with them. After that, she spends about an hour in there a week, so it requires minimal effort on our side.

GitGuardian Platform requires very little maintenance on our end—just making sure the keys are connected and ensuring people are following through.

I have not used any alternatives to GitGuardian Platform in this specific scope, as I have not found one that fully integrates into as many different code repositories. We have used a couple of tool-specific ones, but GitGuardian Platform is the only one we have used that works across multiple platforms.

We purchased GitGuardian Platform for a compliance checkbox because we needed to monitor secrets in our code repositories. We saw benefits immediately after implementation, but the reason my team took it over after a couple of years is that the original team did not really go beyond a compliance checkbox. We started seeing benefits in year 3 as we built out a workflow to contact the developers who committed code with secrets and get them to review and approve or revoke the process.

In terms of how GitGuardian Platform Public Leakage Detection influences our data security, it helps us with our known developers, but it is fairly limited. It has to go to another developer who has to make it public or they have to put codes in there, so it works in the right scenario, but there are scenarios where it still misses.

We do not really look at the automated security severity scoring in Incident Management. We still are getting false positives and others, so we are concentrating more on that versus any severity rating.

The pricing for GitGuardian Platform is fair, though slightly high.

We are customers of GitGuardian Platform; we do not have any partnerships or official partnerships, nor are we resellers.

I rate GitGuardian Platform 8 out of 10.

My use case for the GitGuardian Platform is application security for our enterprise repository.

The solution has improved our organization. We are still in the rollout, but the users who are utilizing it are very happy, especially about the feature that enables pre-commit hooks in Git that will not raise to the remote repository. This is a very good feature that our developers use very heavily.

The best features of the GitGuardian Platform are that it finds many different secrets, more than other competitors, and the support from the colleagues is also very good.

The GitGuardian Platform helps in monitoring and protecting our code repositories from leakage. It helps significantly because we connected our vulnerability management process to this, and the colleagues from vulnerability management have much easier work since we have the GitGuardian Platform installation due to the dedicated incidents or issues which are opened automatically.

The alerting capabilities and threat intelligence features of the GitGuardian Platform are managed by another team; we only host the platform.

The audit logs and compliance reports from GitGuardian are very helpful because, in the past, we needed to do it manually by scanning the repos. Now with GitGuardian Platform, we have a really good overview of what is open, what is closed, and how critical the issues are.

The areas that have room for improvement involve the missing feature to add custom detectors for the GitGuardian Platform, which would help us check if internal secrets are still valid or not.

I assess the accuracy of the detection from the GitGuardian Platform as very good because we don't have many false positives, which means the quality is very good. The only thing we want to have are some additional detectors which help us to prioritize, especially since enterprise secrets are found, but they cannot verify if they are valid or not.

I have been using the GitGuardian Platform for one and a half years.

The stability of the GitGuardian Platform is excellent. We don't have any problems with the stability of the system at all.

The scalability of the GitGuardian Platform is excellent.

The technical support from the GitGuardian Platform deserves a rating of nine out of ten.

The deployment of the GitGuardian Platform is very easy because it's a Helm chart which is very easy to install for us. The deployment took several days.

I have no information about pricing, but since they won the request for quotation, I believe it's a good price.

We created a technical evaluation and checked against other providers, though I don't remember the names. The GitGuardian Platform has the best technical capabilities, and our procurement handles the pricing part.

The GitGuardian Platform is used worldwide in our environment.

Currently, we have approximately 1,300 licenses for the GitGuardian Platform, but we will increase to 2,000 next year.

The solution requires maintenance from our side only for user management, which is normal for each application.

I cannot quantify how much time or resources the GitGuardian Platform saves us because this is spread across all teams worldwide.

I would recommend the GitGuardian Platform to other users because the integration with GitHub and Azure DevOps is very easy, and you also have the possibility to use it locally on your IDE. This is a very good solution.

I rate the GitGuardian Platform a nine out of ten because room for improvement is always possible, but it's really good.

We initially integrated GitGuardian Platform into our organization in 2023 into our GitHub repository. We implemented it because we did not want our secret credentials to be exposed to the internet or to a third party such as GitHub. It flags when credentials have been exposed so we can remediate and fix them. GitGuardian Platform was what my tech lead suggested we use, and we had to incorporate it into our repositories. We use the Platform version.

What I appreciate the most about GitGuardian Platform is its efficiency when triggering our pipeline and notifying us if secrets have been exposed, such as APIs, variables, our database, or anything being exposed. Currently, we have numerous repositories and pushes that happen in our repo. It would be humanly impossible for us to manually search for these secrets. GitGuardian Platform can do this automatically. All we need to do is wait for an email notification that indicates a secret has been exposed. It points out the repository that has the secret exposed, and we can fix it. This saves us the time of manual review.

The main disadvantage I feel they should improve upon is that apart from flagging credential issues or secrets, they could incorporate something else to make it more dynamic. If their product focuses majorly on secrets leaking, similar to Amazon Macie, they could expand their capabilities. Amazon Macie primarily flags secrets being exposed over the internet.

For example, we use Dependabot for code review. Dependabot helps us follow best practices such as code quality and code analysis, as we cannot manually check 10,000 lines of code to ensure they follow structural standards. If GitGuardian Platform could incorporate code analysis into their system, not just for secrets alone, it would make them more dynamic.

This would allow users to have just one tool instead of multiple third-party tools running in GitHub. It would reduce management overhead as you wouldn't have to manage multiple tools.

I have been using GitGuardian Platform in my career for almost two years now.

For my organization, GitGuardian Platform has been stable. Since installation, we haven't had to optimize it, and I am unsure about new versions. It has been functioning effectively, and its performance is satisfactory. The only limitation is that it performs just one task. While it is efficient at credential flagging, it could offer more functionality.

Regarding scalability, in my organization, we have about 44 repositories running, and GitGuardian Platform has been able to handle these repositories efficiently. I am uncertain about its capability to handle 100 repositories. For our organization, which is just four years old and not a large platform with numerous features, it functions adequately with our 44 repositories.

Some tools can function properly until demand increases or usage reaches a certain extent, at which point they might start deteriorating. For instance, with our GitHub account, we had to pay for more capacity usage. I am unsure if GitGuardian Platform has similar limitations on the number of repositories it can handle. However, for our current 44 repositories, it has been working exceptionally.

I have never contacted any technical support or customer support through phone or ticket system. We have never experienced any issues with it. It effectively helps us with credentials security and has been performing satisfactorily.

Neutral

I have not compared GitGuardian Platform with any alternatives in my organization. For GitHub repositories credentials, we use GitGuardian Platform. For AWS, we use Amazon Macie because we run our infrastructure on Amazon Web Services. We use Macie to protect our credentials from being exposed.

The initial deployment and installation was very easy for us.

For this deployment, my tech lead handled the implementation. We were on a call with him while he deployed it. It required only one person to complete the setup.

It does not require any maintenance on our end as it has been working autonomously. I am unaware of new versions, but what we have been using has not required maintenance.

I am not involved with the pricing of GitGuardian Platform, as the tech lead handled those aspects. Initially, I thought it was an open-source tool. There are private and public versions available. The private version requires payment, but for the public version we use, we did not make any payments.

I have not compared GitGuardian Platform with any alternatives in my organization. For GitHub repositories credentials, we use GitGuardian Platform. For AWS, we use Amazon Macie because we run our infrastructure on Amazon Web Services. We use Macie to protect our credentials from being exposed.

I will rate GitGuardian Platform a seven out of ten. The reason for this rating is that I wish they could have an agent embedded into their system that helps to identify real credentials from mock credentials, as this sometimes causes false alarms.

We are users of the product with no partnerships with GitGuardian Platform. They can contact me regarding any questions about this review. I am open to anything that benefits the community and makes everything better.

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.

Positive

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.