GitGuardian: The credential layer security platform (US companies)

My main use case for GitGuardian Platform is for secret detection in the code base, whether in the actual files or in the history of the GitHub code, helping me determine if there are, or were at any point, hard-coded secrets like API keys, passwords, or certificate key stores, and whether they are valid or false positives that require immediate remediation or remediation later on.

There was a specific time when GitGuardian Platform helped me catch something important, as it detected a couple of secrets that were still used in a project that had been migrated. We discovered in the history that while the current files contained no hard-coded secrets—everything had transitioned to using Secrets Manager—GitGuardian Platform identified two valid secrets in the GitHub history that needed to be deleted, although they were not critical or dangerous. To be on the safe side, we changed those secrets after ensuring they were properly removed from the history.

I have nothing else to add about my main use case or how I use GitGuardian Platform day-to-day. It is nice how it automatically scans whenever there is a commit in the GitHub repository, and even when a commit is deleted, the ID of the commit remains visible but grayed out, as it doesn't exist anymore. I would mention the validity check for public API keys is very useful while monitoring the security score. One limitation I've found is that as the tool progresses and updates, it may detect older secrets that have already been resolved, so it would be helpful to get notified when that occurs. Another significant limitation we've encountered is when the same secret is present in multiple repositories managed by different teams; we cannot close the incident unless both teams communicate and agree, because closing is applicable to all repositories, which is challenging when teams don't know each other.

GitGuardian Platform has positively impacted my organization by making the team extra careful about committing hard-coded passwords, even if they are just for testing purposes and deemed invalid. Additionally, my team has started integrating GitGuardian Platform on their local VS Code to scan before pushing code. It has also encouraged the habit of rotating old secrets that were at one point flagged in the tool.

I haven't noticed a reduction in security incidents, as we don't have many because we prioritize security in our development cycle. However, I can say that GitGuardian Platform helped us clean up our GitHub repositories of any type of secrets, even the useless ones, ensuring that if someone were to gain access, they wouldn't know what our API key or password looks like. It has especially helped us eliminate valid secrets from our repository histories, and we currently have zero valid secrets left.

The best features GitGuardian Platform offers include secret detection regardless of the commit history, which means it can detect both current and older files. Its ability to check the validity of API keys is crucial, and it allows tracing of actions regarding secrets—whether they are marked as false positives, invalid, or if remediation is necessary. Additionally, it facilitates the use of tools such as Slack or Teams for notifications.

I find myself relying the most on the instant scan of passwords offered by GitGuardian Platform, as it accurately checks for real secrets and does not mistake common words such as 'password' as a secret. This is advantageous compared to other tools that increase the rate of false positives significantly, which often occurs with keys that are merely for testing or are invalid.

Regarding improvements for GitGuardian Platform, the secret detection feature needs upgrading as it opens only one common issue for the same secret detected in multiple repositories. This poses a challenge, especially if two teams in different repositories, who don't know each other, are working with the same hard-coded secret. Team A cannot close the ticket independently because they are unaware of how Team B is using that secret. It would be much more effective to have a parent ticket for the secret that contains child tickets for each repository, allowing each team to manage their status for that secret as they see fit.

The reason I chose a nine or nine and a half is due to the pain points I've mentioned, particularly the challenges when validating secrets. Additionally, I prefer being notified whenever a new secret is detected in the GitHub history.

I have been using GitGuardian Platform for almost two years.

GitGuardian Platform is very stable, with no downtime or issues in my experience.

The scalability of GitGuardian Platform has met my organization's needs as we have grown or changed, and I did not notice any difference.

Previously, we used the password detection feature in Checkmarx, but we switched because we found it unreliable. Checkmarx often flagged many false positives, sometimes misidentifying the word 'password' as a real password or mistaking names of secrets in Secrets Manager or Key Vault for secret values. Their lack of capability to detect hard-coded passwords in the GitHub history was another issue compared to what GitGuardian Platform offers.

I have seen a return on investment, particularly in securing the applications and ensuring there are no hard-coded secrets within the code base, which is a significant security positive.

I haven't had the chance to thoroughly explore GitGuardian Platform's AI capabilities, so I'm not sure how I can answer that. Regarding my experience with the accuracy and reliability of GitGuardian Platform's AI capabilities, prior to their implementation, I found them to be helpful, especially in deciding the severity of a password when evaluating its risk from someone outside the application. My advice for others considering GitGuardian Platform is to move forward with it, as it's a great tool. I would rate GitGuardian Platform overall at nine, or nine and a half.

My main use case forGitGuardian Platform is secrets monitoring across public repositories and internal codebases. I use it to detect anything that matches keywords or signatures — particularly system secrets, tokens, and credentials that may have been accidentally exposed. When GitGuardian flags a potential exposure, I reach out to the responsible parties to ensure the secret is rotated and the risk is mitigated.

Security operations is the main use case for GitGuardian Platform, and we are using it in security operations as one of our large use cases.

GitGuardian Platform has had a significant positive impact on our organization. It has helped us uncover a number of exposed secrets, including critical tokens and credentials that were accidentally pushed to repositories. Without it, these exposures could have gone undetected and led to serious security incidents. Overall, it has meaningfully strengthened our secrets management posture.

The best features GitGuardian Platform offers include secret incidents, activity, push events, and commits.

The specific features that stand out to me as the best on GitGuardian Platform are the seamless integration capabilities and the incident detection capability that detects passwords and any high-entropy secrets, as well as the feature that allows us to segregate, flag, assign, and manage incidents. The incident tracking, seamless integration, and search functionality are all part of what makes it great.

GitGuardian Platform is already a mature and well-rounded product. The features, user interface, and integration capabilities all meet our needs effectively. At this point, I do not have any specific improvement requests — it does what it promises and does it well.

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

Yes, GitGuardian is stable. In four and a half years of usage we have not experienced significant downtime or reliability issues.

GitGuardian scales well for our security operations needs. It handles monitoring across our repositories without performance issues.

customer service and technical support have been satisfactory for our needs.

No, I did not previously use a different solution for secrets monitoring. GitGuardian was our first dedicated platform for this use case.

The initial setup was straightforward. Integration with our existing systems was seamless with minimal configuration effort.

No

Yes. The platform flagged secrets and tokens that were accidentally pushed publicly

I am not involved in pricing discussions

We did not evaluate other solutions extensively before choosing GitGuardian. It met our requirements for secrets monitoring and security operations out of the box.

I would rate GitGuardian Platform a seven out of ten because I appreciate it; it is not the best tool, but it is above other tools.

Regarding GitGuardian Platform's AI capabilities, I think it is secure, and it could benefit from using AI systems for security purposes.

I find the accuracy and reliability of GitGuardian Platform's AI output to be on point. I would tell anyone researching GitGuardian Platform on PeerSpot that my overall rating for this product is seven out of ten.

We are leveraging GitGuardian Platform first to augment governance over security control mechanisms in relationship from the developer through the CI/CD process out to resources such as vaults and so on, so that we can get active control over how security is, what is security, and how we can improve it.

For instance, we envision using GitGuardian Platform with developers using IDEs or APIs, AI tools, operating through the automated pipelines of CI/CD, up to a vault out there in the cloud environment that contains the security rules that we have in play. We want to watch that process, whether it be a container, an artifact, or a pipeline, and see how, first, what is it? And then secondly, how can we improve it? So that we can use security key template models versus access account models.

We are also wanting to gravitate from the strategy of using traditional style security templates that require account access, ID/user password models, and use GitGuardian Platform to develop a strategy to use API keys and signature encryption keys instead. To do that, we need a tool that gives clear transparency for that requirement.

GitGuardian Platform has positively impacted our organization during the evaluation phase as this is a new realm. These are new tools, and they do not really have a standard. So the key thing by working with this is to get a better sense overall of the guardianship and governance, setting the standard for what that inevitable gold standard needs to be when working with these kinds of tools.

A gold standard for my organization using GitGuardian Platform would look like using the guardian process to establish the regular nature of a code update process from the developer who initiates the code change through the guidelines that they have to follow, which will not allow them to do anything else except for the steps that are required to be tested with quality assurance and walk through a regimented series of processes that have human intervention involved in that process to make sure that they clear the proper security requirements.

I think GitGuardian Platform could add value and help regulate unnecessary man hours in a phased approach. Using the governance platform to help cover what we would have normally done with man hours would be a value add. The more important thing is it shows transparency of compliance, which is a very important detail.

GitGuardian Platform has good integration with Git. It works well with pull requests and Git actions. It does not have too much difficulty with Docker images, different CI/CD environments, Ansible, Puppet, and so on. The current integration to Confluence, Jira, and Slack for working with different environments is valuable for bringing the common form of tools into this particular style tool and having ease of work with those environments.

All integrations including Git, Jira, Slack, and CI/CD environments add value for our team, but they have to happen in a specific process because the actions generate analytics. Those analytics drive up through Jira and Confluence and so on to generate analytic reporting. It is all important, and there is not just one tool.

GitGuardian Platform meets the CDE security requirements guidelines specified for secops and infosec. I would describe the overall user experience and interface design of GitGuardian Platform as usable and functional.

I think it would be advantageous to see GitGuardian Platform's CI/CD protection get better developed because of the new adaptations that are coming with CI/CD. More flexibility regarding installations versus code updates versus bug fixes versus incidents in which we will generate RCA reports, and that they also concur with this same tool, would be beneficial. All of that needs to be clearly and transparently shown in this tool.

GitGuardian Platform can be improved with better analytics and better analytics integration, specifically with Confluence for generating leadership levels of reports so that leadership can translate all of this information into something that is viable for the profit loss margins that they have to address each month.

I chose seven out of ten because better and more seamless dashboard analytics design and better analytics integration would help it get to a higher score for me.

Regarding GitGuardian Platform's AI capabilities, its accuracy and reliability of output is getting there, but along with all the new introductions of AI services versus chat forms, there is still a lot to be desired about the functionality and the integration. It is something that is ongoing because this year is the year that these features and functions are coming in. I expect it to improve over time, and that will improve the reliability and output as well.

The biggest challenge my team has faced so far with GitGuardian Platform is integration, specifically integrating it to everything.

GitGuardian Platform is currently in the evaluation phase.

GitGuardian Platform is stable.

We have not gotten to the point where we can initiate scalability with GitGuardian Platform. Right now, we are establishing the framework of the services and their roles and then look to scale it across multiple clouds.

GitGuardian Platform's documentation has been helpful during my evaluation.

GitGuardian Platform's customer support has been good so far.

I rate GitGuardian Platform's customer support an eight on a scale of one to ten.

We did not previously use a different solution. We used open source and manual processes. Now we are looking for a consolidation platform to do the same work.

GitGuardian Platform is deployed in a mixture, usually between a hybrid cloud and on-premise. For my hybrid cloud deployment, we use an on-premise localized cloud deployment.

Integrating GitGuardian Platform with my existing tools and workflows during my evaluation has been fifty-fifty, because some of their APIs are custom made.

The reason the learning curve for GitGuardian Platform is so high is because I am introducing a whole new platform to what we already know, and that process is nothing we are familiar with. So there is a learning curve.

I would expect GitGuardian Platform to not require hiring additional resources, but to more effectively use the resources we have on hand now regarding return on investment.

Regarding my experience with pricing, setup cost, and licensing, we have not identified what the licensing model will look like depending on how much of the compliance components we will use versus cost. We are still working that out with the reps.

The main factors that influenced my decision to evaluate GitGuardian Platform over other solutions include the need for a centralized single pane of glass of governance and compliance, which has been very fractured over the past three years. But now companies are starting to understand what these look like.

Before choosing GitGuardian Platform, I am in evaluation of three different vendors. I cannot disclose those at this time due to NDA agreements, but GitGuardian Platform is and was actively being compared to two other vendors at this time.

The most critical advice I would give to others looking into using GitGuardian Platform is to understand that it is brand new technology and a brand new standard, with nothing truly written in stone. The learning curve will be significant as an adaptation is put in place. The key thing is to fully know all of your key tools that you use in your CI/CD processes, as well as planning for future tools, so that you can properly map the right compliance tool that supports those tools you have picked and become part of your platform.

I am not in it that much yet to get a full scope of its yearly add-ons or features and improvements regarding how satisfied I am with the pace of innovation and new features being released by GitGuardian Platform. But for now, they are adequate.

I rate GitGuardian Platform a seven out of ten.