The easiest route - we'll conduct a 15 minute phone interview and write up the review for you.
Use our online form to submit your review. It's quick and you can post anonymously.
We initially integrated GitGuardian Public Monitoring 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 Public Monitoring was what my tech lead suggested we use, and we had to incorporate it into our repositories. We use the public monitoring version.
What I appreciate the most about GitGuardian Public Monitoring 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 Public Monitoring 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 Public Monitoring 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 Public Monitoring in my career for almost two years now.
The initial deployment and installation was very easy for us. I cannot remember exactly how long it took to fully deploy it, but the process was straightforward. When we installed it two years ago, we conducted security testing to verify its functionality. It worked effectively.
One downside about GitGuardian Public Monitoring is that it sometimes flags mock credentials, interpreting them as real secrets. While this is good for simulation purposes, it should be able to distinguish between real and mock credentials. When we test ran it, it worked immediately. After approximately a minute or two, we received email notifications about exposed credentials. The integration process was very easy.
For my organization, GitGuardian Public Monitoring 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 Public Monitoring 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 Public Monitoring 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.
Negative
I have not compared GitGuardian Public Monitoring with any alternatives in my organization. For GitHub repositories credentials, we use GitGuardian Public Monitoring. 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 Public Monitoring, 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 Public Monitoring with any alternatives in my organization. For GitHub repositories credentials, we use GitGuardian Public Monitoring. 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 Public Monitoring 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 Public Monitoring. They can contact me regarding any questions about this review. I am open to anything that benefits the community and makes everything better.
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.
Positive
Two of us were involved in the deployment process.
It took a week to deploy the GitGuardian Platform, just to standardize the process.
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.
