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 solution to detect any secret exposure.

The overall breadth of the solution is good. It's been able to detect most of the secrets that we have.

The accuracy of the solution is generally good, but we have had a number of false positives. For example, sometimes we would commit a test secret, and it would not follow the action of a secret. This is because the secret contained a prefix that is commonly used in passwords, such as "password". We have been able to take action to suppress these false positives moving forward.

The solution helps to quickly prioritize remediation. When we go back to the historical scan, it can tell us not only what vulnerabilities were exposed, but also the general risk level of each vulnerability. This allows us to prioritize remediation efforts and focus on the more critical vulnerabilities first.

The solution helped to decrease the overall false positive rate. We have been able to decrease the number of false positives by about seven percent. When we receive alerts now, they are usually general alerts. We do not receive alerts that are specific to a door without the pull being put in place when we investigate.

The solution increased our secret detection rate by around 80 percent.

We detected a security issue, and we were able to fix it in the system within half a day. This was possible because we reduced the number of follow-up steps required. The solution saved our security team about 25 percent of their time. This means that we probably removed about a week's worth of incident management work. This is a significant improvement in security, and it saved our team a lot of time.

The solution also helped reduce our mean time to remediation.

At the start, historical scanning was very useful because it was the first time we had done it. It allowed us to see how many secrets we had exposed. If we had only focused on current secrets, we would have missed all the secrets that had been committed in the past. So, initially, the historical scan was really useful.

Presently, we find the pre-commit hooks more useful. These hooks allow us to set up a local development environment where we can scan for secrets before we commit them to the repository. This saved us a lot of time.

It took us a while to get new patterns introduced into the pattern reporting process. If there is a way to automate this process so that we can include our own patterns in our repositories, that would be very useful.

The authentication process could be improved. A single sign-on system would be very helpful.

I have been using GitGuardian Internal Monitoring for one and a half years.

The solution is stable.

The solution is scalable, so we can create instances for each scan that we run. This means that we will never have any issues with load or performance. We have 100 end users the utilize the solution.

The technical support has been very helpful. The system is also pretty intuitive, so we haven't had to contact them very often.

Positive

We have seen a 10 percent return on investment. Resource-wise, creating a secret once it has been detected is a significant undertaking. Early detection has saved a lot of time, and I think there would be various penalties. Theoretically, if we continued to explore secrets, we could also save and compromise.

I compared the solution to a couple of other solutions, and I think it is very competitively priced.

I give GitGuardian Internal Monitoring a seven out of ten. The solution is really good, but the false positives that we had to work with lower the solution's overall score.

When we first started using the solution, we had to address some areas quickly. We had pushed through some public-facing features because we wanted to start working in the open. However, this prompted us to realize that we weren't quite ready to do that. So we had to make all of our clusters private again, or as private as possible. The thought of working in the open had to be reviewed at the start.

The solution does not require maintenance. It is used extensively and is part of our security check pipeline. It is included as part of the pipeline in any repository that is created. It is also included in the repository itself. Each project is included as a pre-commit process. Additionally, it is included in our deployment pipeline because it is well integrated into our productivity tools. 

Secret detection is a very important part of a security program for application development. It gives us the confidence to commit our work to a shared environment, especially if we want to make it public. Secret detection helps to ensure that confidential information is not exposed.

For those using an open-source tool, I would suggest pointing out what sort of support they might need. If they're comfortable using it on their own, then that's fine. But if they need support, it would be helpful to have a support package available.

People should do a proof of concept first because the way it will be configured for them might be different. I don't know if we can figure it out for sales for another organization. So, having a proof of concept to fully understand how it will work best for them is useful.