GitGuardian Platform Reviews

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.

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.

We brought in GitGuardian Internal Monitoring to review all of our code within GitHub so that we can identify and fix any exposed secrets.

I have been very impressed with the breadth of its detection capabilities. I did a proof of concept with a couple of other common tools for the same kind of thing, and I found GitGuardian to be the best. It finds everything that I would expect it to find. It found more than I thought we would find, so I am very happy with the detection.

I am very happy with the number of specific detectors and keys that it can find for Google, AWS, Twitter, Facebook, etc. It has a lot of specific detectors for different categories, but it also has quite a lot of automatic validity checking, so it can tell whether your Twitter keys or AWS keys are active and or have been revoked. If they are revoked, it is not a problem. Validity checking is fantastic.

GitGuardian Platform's accuracy is incredibly high. There are a couple of categories of generic secrets that I can find. When you turn those on, you end up with quite a few false positives. With the specific detection categories, the false positive rate is incredibly low, but when you turn on the generic categories, it goes up a bit. I am very happy with the number of things that it does find, instead of focusing on true positives versus false positives.

It has not helped to decrease false positives because we did not have a tool in the first place, so we did not have any false positives. We have not decreased our rate at all.

GitGuardian Platform has absolutely helped to quickly prioritize remediation. The severity or criticality that the tool automatically assigns has been very helpful. The built-in validity checking has also been helpful. Whenever you have keys that are marked as valid within the tool, you know that they are high priority and need to be resolved sooner than the ones that are not marked as valid.

We have significantly reduced our potential risk exposure of secrets. In the past nine months, by using GitGuardian, we have been able to identify and resolve a large number of secrets within our code, which reduces the risk if our code were to become public. It has greatly reduced our security risk. It has reduced the potential risk of exposure of secrets by about 75%. We have not only been able to resolve existing issues; we are also more likely to prevent these issues from occurring with improved security culture and the features within the tool.

GitGuardian Platform efficiently supports our shift-left strategy. It provides a command line interface, which can link with the shift left with your standard development processes. Whenever developers are writing code and trying to commit and push that up to GitHub, the command line interface can be integrated into that to prevent secrets from getting into GitHub. It can help go almost as far left as possible.

GitGuardian Platform has greatly improved awareness, and it has reduced the number of secrets that end up in our code. There has been a two-layer impact where it has helped people think about this as an issue and it has also helped them stop doing it even if they are not thinking about it.

GitGuardian Platform has improved our ability to collaborate. We work closely with the development teams to identify the issues, investigate the issues, and troubleshoot and resolve those issues. Due to the way the tool works, it has helped us gather people into teams and work with them so that we can help resolve the findings.

We have one or two of the playbooks automatically enabled. So far, I find them very helpful. The main one so far is that the secrets will automatically resolve when they are revoked, which is incredibly useful. For example, whenever someone goes into the AWS platform to revoke AWS keys, they do not have to go into GitGuardian. It automatically detects that they have been revoked and closes the issue. It is a lot less work than having to go into two different tools and more. There are a couple of playbooks we have for the CLI, so whenever we ignore issues via CLI because something might be a false positive or something might only be a testing key, it will auto-resolve within the UI. The playbooks make it easier to avoid using the UI, but you do not have to. It is one of the catch-22 situations. There is UI, but they are enabling you to not even have to check it in the first place. Playbooks have reduced 50% to 60% of manual work. If developers accidentally commit active keys, they do not have to go in. They do what they need to do to resolve the keys. They do not need to think about it again.

GitGuardian Platform has increased our security team's productivity by about 50%. When we previously had noticed keys, it would have been manual. It would only have been occasionally when I was looking through the code and found the keys. I would have had to reach out to developers and discuss that. It has definitely greatly increased our productivity because we can now automate sending out tickets and assigning them to the right teams. A couple of clicks can send out the information for someone to look into rather than having to message them and try to discuss it with their team. It is a lot more automated.

It is hard to measure the increase in secrets detection rate because previously, we did not have any solution, so we were not detecting anything. After implementing GitGuardian, we can now see what we have got.

Similarly, it is hard to measure the reduction in the mean time to remediation as we did not have something before. It was more manual before. There is probably a 70% reduction because, previously, if I found an issue, I would reach out to our team and spend a while discussing it with them, whereas now, we can just send out a Jira ticket. They can log in and have a look. There is a lot less discussion back and forth.

There is quite a lot to like. Its user interface is fantastic, and being able to sort the incidents by whether they are valid or for a certain repository or a certain user has been very beneficial in helping investigate what has been found. 

The CLI provided by the tool is fantastic for preventing the secrets from getting into GitHub in the first place. The more you use the CLI, the less you use the user interface.

Automated Jira tickets would be fantastic. At the moment, I believe we have to go in and click to create a Jira ticket. It would be nice to automate.

I believe there is a feature on the road map for better handling of issues that have over one occurrence. It is difficult to investigate when there are a large number of secrets. It is hard to know where they are and what to do. These two things would be nice.

I have been using GitGuardian Internal Monitoring for about nine months.

It is a stable solution. I have not noticed any issues with performance, downtime, or anything like that. I would rate it a ten out of ten for stability.

It is scalable. All it requires is someone with GitHub admin permissions. We can integrate as many repos and sources as we want. I would rate it a ten out of ten for scalability.

We have 316 users using this solution. We plan to increase its usage. There are a couple of features in GitGuardian. There is a feature where CLI integrates with your development process for pre-commits. We plan on testing and rolling out that feature so that every developer has pre-committed automatically enabled on their machine. The idea is that it will basically prevent any secrets from getting into GitHub. Another, a lot more minor, feature is GitHub pull requests. Every time there is a pull request, the GitGuardian bot will comment on it if there are secrets. There is an option to block the pull request when secrets are found. We plan to implement that as well.

Their technical support so far has been fantastic. Anytime I raise a ticket, it is resolved and answered very quickly. I am very impressed. Their support is incredibly knowledgeable. Whenever I have questions about detection or remediation, they are very detailed in their answers, and they clearly know a lot about the tool.

Our experience has been fantastic with the purchase, the onboarding, and the customer success team. Everything has been straightforward. Everyone so far has been nice, friendly, and helpful. When there were any hurdles, they helped me resolve them straight away. I would rate their support a ten out of ten.

Positive

We did not use any similar solution before. It was a manual process. We did not monitor anything. We just occasionally noticed things to be resolved. It was a manual process.

To implement it, the only thing required from our side was having someone with admin permissions to enable the installation. It was minimal from our side.

It does not require any maintenance from our side.

It required just one person with GitHub admin privileges. I clicked a few buttons, and then he went in and approved it, and that was it.

It has definitely saved us a lot of time. To be able to view everything important and narrow our focus to resolve issues has sped up our development process and decreased our security risk.

I am only aware of the base price. I do not know what happened with our purchasing team in discussions with GitGuardian. I was not privy to the overall contract, but in terms of the base MSRP price, I found it reasonable.

We reviewed three or four main secret detection products available. We reviewed GitHub Advanced Security and BluBracket.

We chose GitGuardian for a number of reasons. Its user interface is absolutely fantastic. Being able to filter instances has been the main thing. It helps us to focus and narrow down our remediation efforts.

There is also the ability to create teams and assign developers and teams to only see what they are responsible for. There are a number of other products, but they are missing that feature of narrowing visibility. We wanted a tool that the security team could set up and the developers could log in to use. A lot of the other tools on the market are only for the security team. It would have been more manual on our side to reach out to teams to get them to resolve things. This way, we can add users to teams, assign them the repositories that they maintain, and they can work away by themselves.

To a security colleague at another company who is using an open-source secrets detection solution, I would be happy to recommend GitGuardian. I have been setting up and using the tool. I can happily, personally, and professionally recommend this tool to others.

In my opinion, secret detection is incredibly important to a security program for application development. It is critical to our company's obligation and security process. Without it, you do not know what secrets could be leaked, so once you implement it, you know where you stand and you know what you need to do. You can resolve as well as prevent these things.

I would definitely recommend doing a proof of concept to make sure it fits your use case. I would be more than happy to recommend it. There would not be any caveats. Go ahead and test it out. If it fits exactly what you need, go for it.

Overall, I would rate GitGuardian Platform a ten out of ten. I am very happy with what we are able to do with it and how it works.

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.

Positive

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.

Our developers use the GitGuardian platform to securely access and manage secrets within their repositories. This allows them to identify and address any potential security risks.

GitGuardian's detection capabilities are good.

The accuracy of detections and the false positive rate are good.

It has improved the abilities of our developers and security team.

The playbooks help to identify and prioritize security incidents.

GitGuardian helped us increase our secret detection rate.

GitGuardian helped to increase our security team's productivity. It allows us to find the secrets and their repository faster. As the security team is focusing on one app to audit it, we also look at the GitGuardian findings for that app, and that is easier than looking for the secrets manually.

The most valuable feature is the general incident reporting system. It provides informative data with good filtering and reporting options.

We'd like to request a new GitGuardian feature that automates user onboarding and access control for code repositories. Ideally, when a user contributes to a repository, they would be automatically added to GitGuardian and granted access to view that specific repository. This would eliminate the need for manual user creation and permission assignment within the platform.

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

The GitGuardian Platform is stable.

The GitGuardian Platform can deploy at scale.

The pricing for GitGuardian is fair.

I would rate the GitGuardian Platform eight out of ten.

Getting started with GitGuardian required some preliminary setup on our part. This involved configuring both our on-premise GitHub Enterprise server and the GitGuardian application itself, granting the application access to the enterprise server.

GitGuardian requires around two hours per week of maintenance. We have our scripts that add users to the tool as needed. So we have a script that looks at our GitHub server talks to that API, and uses the information from that to add users to GitGuardian. And we have to maintain those because sometimes just like with any code, we have to make sure that process is still working.

GitGuardian's onboarding process and customer success teams were helpful.

I recommend GitGuardian as an easy-to-use tool that tackles a major security risk often overlooked by companies. This platform can significantly improve your software development lifecycle.

While detecting hidden functionality within a security program for application development isn't the highest priority, it does hold some value. If resources allow, it's worth considering incorporating methods to identify such secrets.

Organizations considering the GitGuardian Platform should establish clear action points for employees who will be using the tool. This ensures everyone understands how to leverage GitGuardian effectively within their workflow.

We utilize GitGuardian to scan for secrets within our codebase. Our implementation includes pre-receive and pre-commit hooks, dashboard scans, and CI/CD integration within GitLab.

Secret detection is pivotal for development security, ensuring no secrets exist in packages, libraries, dependencies, or code. Even with a locked-down application, explicit permissions could grant easy access to the environment and connected resources. GitGuardian serves as an essential tool for every development team.

GitGuardian aids in prioritizing remediation efforts by promptly notifying us of reported issues. This informs our approach; we prioritize valid reports over invalid ones or those that failed checks. Automation plays a significant role, swiftly addressing invalid reports and saving valuable time.

The solution aligns with our shift-left strategy, empowering developers with security responsibilities through pre-receive hooks that act as security controls. Developers can quickly identify secrets, enhancing security awareness at the development level.

GitGuardian significantly reduces manual work through automation, streamlining incident resolution processes and allowing proactive measures like permissions revocation. While not fully automated, leveraging automated solutions has notably increased productivity, enabling us to focus more on governance and essential tasks.

Our secret detection capabilities have improved dramatically with GitGuardian. Initially facing over 10,000 incidents, we reduced them to 2,700, marking a 60 to 70 percent increase in detection efficiency.

Validation features save considerable time by eliminating the need for manual verification, allowing us to focus on remediation. While accuracy varies based on use cases, we've encountered only a handful of false positives, with the false positive rate correlating strongly with the number of secrets present.

GitGuardian offers a range of features that align perfectly with our requirements. With internal policies in place to prevent secret exposure, especially concerning our code hosted on GitLab, GitGuardian's pre-receive hook stands out as a crucial feature. By activating this hook on the remotes, it effectively blocks commits from being pushed to the repository, ensuring that secrets never reach GitLab and remain protected from exposure.

The tool provides comprehensive coverage, including classic technologies such as SMTP credentials, along with Slack tokens and AWS secrets in our specific use case. Its ability to manage various types of secrets, including database connections, APIs, and RSA keys, streamlines our workflow by consolidating detection efforts. This consolidation saves us considerable time, eliminating the need for back-and-forth verification with the team. Once a valid issue is identified, we can promptly escalate it to the team for remediation

The GitGuardian hook and dashboard scanners are essential components that should seamlessly integrate to provide comprehensive security coverage. However, we've encountered instances where discrepancies arise, with the dashboard scan detecting issues not reflected on the hook. This inconsistency requires fine-tuning to ensure efficient detection and resolution, as we aim to avoid unnecessary time wastage.

Moreover, the historical scan feature could benefit from improvement. Occasionally, it fails to efficiently track changes in updated histories, leading to delays in data history updates. This can be frustrating, especially when the reported secret remains unchanged or changed in history. Addressing this issue is crucial to alleviate the burden on the team and streamline our workflow. We hope to see enhancements in this aspect from GitGuardian.

I have used GitGaurdian for two years.

Earlier, we had some challenges and problems with the dashboard crashing, but there have been many improvements since then. We haven't seen any crashes lately. 

The scalability depends on the deployment model. Our engineers understand how to deploy the solution directly. We have two environments: production and dev. We haven't seen any major hassles, and it doesn't impact the development workflow.

I rate GitGuardian support nine out of ten. GitGuardian support has been great. They respond fast. If something requires investigation, they also resolve the issue quickly. Recently, we had to upgrade because of a bug. They were happy to help us.

Positive

I used Trufflehog at a previous company. It's hard to compare the two. Both have their strengths and weaknesses. I've used a couple of the other solutions, and GitGuardian stands out.

It was straightforward. We had deployed it on EKS with nodes for dashboard and other aspects of the app.

It was a joint effort. Their support engineers were very skillful and did provide all required help.

Every company has a budget to spend on security tools, so it depends on what you want to spend on security at each stage in their maturity walk. You can have a vulnerability in your code with a firewall in front, but you don't want an application exposing secrets. An attacker knows how to crawl your application and extract information. It depends on how much you want to prioritize the cleanness of your code from a secrets perspective. 

We looked at a few other products but primarily chose GitGuardian because of the price. It also has some advantages regarding dashboard maturity and the number of available integrations. We also like the auto-validation and the way the pre-commit hook works. It was also a lot easier to implement GitGuardian. 

I recommend open source for other things but not secrets detection. There's an inherent vulnerability to an open source solution that could leave your secrets exposed. 

I rate GitGuardian Internal Monitoring nine out of ten. Before deployment, it's crucial to thoroughly understand your environment. For users of public cloud services, ensuring compatibility with GitGuardian's features is essential to maximize benefits. While the SaaS solution offers simplicity, our air-gapped internal deployment had minor restrictions on available features. Despite this, we opted to continue with GitGuardian as it satisfied our core needs.

Understanding your environment and version control system is paramount. Determine your implementation approach, considering options like starting with dashboard scans rather than hooks, which I don't recommend initially. Beginning with dashboard scans on your version control system, such as GitHub, and conducting historical scans is advisable. As teams become more acquainted with the tool, gradual implementation of more advanced features like hooks can be considered.

We use GitGuardian to detect secrets that have inadvertently been committed to our source code. GitGuardian monitors every Git push and commits we make, and it analyzes the files, looking for things like access tokens, passwords, session ID cookies, etc. If that happens, GitGuardian raises a ticket in our internal ticketing system, and we remedy it. 

When we first deployed GitGuardian, we went back through all of the commits that we did over the course of the last five or six years that the company existed. It immediately found more than a hundred. We detected all sorts of secrets in those repositories. It had a pretty substantial impact from the first day. That was during our trial run, but now it's incorporated into our deployment pipelines. The impact is still there, and it's still tremendous. It's probably not as instantaneous or the same avalanche of detections that we saw on day one. That was impressive, but we don't get that anymore. It has been a constant trickle of tickets.

GitGuardian helps us prioritize remediation. You need to incorporate it into your existing processes, but GitGuardian provides you with the flexibility and the tools. For example, in our environment, we implement ticket creation through webhooks. We have some logic rules stating that our production repositories are a higher priority than our dev or sandbox repositories. Our developers commit all sorts of weird things to those. GitGuardian gives you the tools to do that, but it may not necessarily do that right out of the box when you first deploy it.

To have collaboration between our security and dev teams, you need to have a detection. Previously, we did not have a functional equivalent to GitGuardian in our environment, and it introduced that process, so we could begin having that conversation. The security team is more focused on remediating to ensure that API token or password is invalidated as soon as possible after it was committed. Developers are more focused on why the secret was committed and environment variables to store that particular secret. The collaboration exists in our company largely thanks to GitGuardian.

A webhook creates a ticket in our internal ticketing system, and the ticket goes to the security guys. They look through it. They make sure the secret is invalidated and start that conversation with the developer to say that they committed this, so please don't do that again. That's the end of the story. We don't use 100 percent of GitGuardian's functionality. We are a fairly small company, so we probably don't need all of that. This simple approach works pretty well for a company of our size.

GitGuardian has improved our security team's productivity if we measure it in security incidents per week, hour, etc. Now, we have a separate stream of secret detection tickets going into our system. It's much better to have those during the deployment phase instead of discovering them after a breach or down the road. 

It's hard to quantify the time saved. Finding a secret that was accidentally committed to a repo is like searching for a needle in a haystack.  And you don't even know if the needle is in that haystack. Now you have something like  X-ray vision that lets you see through that haystack and find right where the needle is. It unlocked a new angle on our application security process that did not exist. When a secret was accidentally committed to a repo, it could have been noticed by a security guy or another developer, or maybe not. 

The most valuable feature of GitGuardian is its core secret detection mechanism. It covers a broad range of technologies. The detection accuracy is extremely good. It correctly detects in about 99 percent of cases. Every false positive we've had wasn't an actual false positive. It was a case where a developer copied a sample code from somewhere, including a dummy password or session ID.  GitGuardian may trigger this, but I think that's a good thing because we know it's there, and it is alert.

GitGuardian had a really nice feature that allowed you to compare all the public GitHub repositories against your code base and see if your code leaked. They discontinued it for some reason about eight months ago, it was in preview and kinda exploratory phase, but for whatever reason, they chose not to move forward with it. 

That is unfortunate because it immediately detected a leak of our company code that one of our contractors committed. They leaked our intellectual property into one of their public reports. 

I have used GitGuardian for 14 or 15 months. 

I have never experienced a single instance of downtime, but I don't sit there 24/7. It's just a useful thing that is sitting in the corner humming and doing its thing. I have never noticed any outages.

We are a small company, and it performs beautifully for a company of our size, but I think it will also perform well for a company 20 times our size. If we're talking at the scale of a company the size of Google, then I don't know.

I rate GitGuardian support eight out of ten. 

Positive

We didn't have a secret detection solution because it's a fairly new area. However, we also use Snyk to supplement GitGuardian. It does things that GitGuardian doesn't do, like dependency detection and static code analysis. GitGuardian is also doing things that Snyk isn't, so the two complement each other nicely.

GitGuardian is a SaaS solution, and the integration process is pretty straightforward. It's similar to other things you integrate with our repository and version control systems. It doesn't require any maintenance. It adds new repositories automatically.

The purchasing process is convoluted compared to Snyk, the other tool we use. It's like night and day because you only need to punch in your credit card, and you're set. With GitGuardian, getting a quote took two or three weeks. We paid for it in December but have not settled that payment yet.

It's also worth mentioning that GitGuardian is unique because they have a free tier that we've been using for the first twelve months. It provides full functionality for smaller teams. We're a smaller company and have never changed in size, but we got to the point where we felt the service brought us value, and we wanted to pay for it. We also wanted an SLA for technical support and whatnot, so we switched to a paid plan. Without that, they had a super-generous, free tier, and I was immensely impressed with it.

When we acquired GitGuardian, I compared it to GitHub Advanced Security, an additional premium subscription from GitHub that you can purchase on top of your existing one. It claims to do similar things to what GitGuardian does, but GitGuardian is far superior in terms of the types of secrets it can detect. 

I'm not sure if GitHub has caught up since then. I picked GitGuardian over GitHub Security because it had better functionality. Also, not all of our repositories are in GitHub. We also used Azure DevOps. GitHub Advanced Security sort of locks you down within that GitHub sandbox. With GitGuardian, we could scan both GitHub and Azure DevOps repositories and have identical functionality across the two. If we implement a policy in GitGuardian, we would know that it equally applies to secrets committed to both systems.

You also have the option of open-source solutions, but one of our core principles is to lean heavily toward solutions that are not self-hosted, whether it's in the cloud or on-premises. To have an open-source solution, you need to run it somewhere and maintain it. GitGuardian is a software as a service. You sign up and forget about it until your next detection. If a company wants to minimize administrative overhead, GitGuardian is a pretty much no-brainer.

I rate GitGuardian eight out of 10. Secret detection is critical to application security. You might assume that your developers have a security mindset. Many don't. Sometimes, it isn't even a mistake. They might not realize exactly what they are doing and the amount of damage that could occur because of what they commit to a repo. 

When you implement GitGuardian, there will be an influx of detections if you're developing any software that connects to anything with a database, third-party REST API, etc. I recommend looking through the initial list of detections and identifying the most susceptible projects or repositories. Also, look at the developers who produce the most detections. Those are the people who lack a security mindset. Identify the high-risk category of developers.

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. 

Positive

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.

Our main use case is operational security. We have a big IT platform. A lot of it is built in-house. We are not a focused IT company. We are a retailer. We have a lot of developers with a lot of different levels and projects. For example, with fashion brands, it is just, "Oh, we want to do this new app," and then they put it on our GitHub. Suddenly, we see all kinds of API keys and secrets in there. This solution is very useful for us because GitGuardian lets us know about them, then we can take care of it.

It is on the cloud. We gave GitGuardian access to our organization and codebase. It just scans it on an ongoing basis.

Since using GitGuardian Internal Monitoring, we have found potentially enterprise-destroying secrets in our GitHub. For example, if our Git got compromised or we had a rogue employee, they could get a lot of business-critical data, disrupt the business, or put us at very high risk. More or less, we are now somewhat protected against that. Now, we are at a stage where we are just keeping an eye on it. As soon as a developer pushes something or does something, we get informed and act on it. The exposure time is very small. Before GitGuardian, we had secrets for years that we did not know about.

As soon as a new secret is detected, we get an email. We look at it, then contact the developers. It is a very fast process. For example, if it is my code and I pushed it, that is the fastest scenario. It is my problem. GitGuardian finds it, then I can fix it myself. I don't have to call another team, talk to them, etc. It could be within a minute that it is remediated.

The most valuable feature is automatic secrets detection, which is quite intelligent. It gives us very few false positives, which is definitely worth it at the end of the day as no secrets or confidential keys are getting into our GitHub undetected.

The majority of false positives are things like test credentials or dummy data that we put in for testing, etc. Therefore, it is not really feasible for GitGuardian to understand which is dummy data and which is real data. They do well in terms of false positives. They work quite hard on them. Sometimes they understand that it is dummy data. 

For certain types of secrets, they can check if it is being used. They will go to Microsoft and check if the key is valid in Microsoft, then tell you, "Hey, this secret is actually live somehow." This is another feature that they are working on that I like.

The breadth of the solution's detection capabilities are really good. We haven't walked upon a piece of code where we question, "Oh, why isn't GitGuardian picking this up?" That's for sure. If there are some secrets in our Git that we don't know about and GitGuardian hasn't found it, I don't think it is likely that we will.

For remediation, GitGuardian is quite good at pointing out all the incidents and helping us handle them. However, remediation is mostly in our hands. We have to go in and resettle. If they could detect secrets before they end up in our GitHub, that is the only improvement that would be a meaningful improvement from what they have. 

Right now, we are like the SRE team for the company. We need to monitor all the secrets, because when we give somebody access, they either see nothing or everything in GitGuardian. We would like to be able to tune it so developers can see the secrets that GitGuardian detected in their own repositories and teams. Then, they could manage it themselves. We wouldn't have to be in the middle anymore. We could just supervise and make sure that they do fix it. For example, if they might not care about their secrets getting spilled into Git, then we need to get our stick and chase them around the office.

I have been using it for a year.

We have not had any issues at all with stability.

We do not do maintenance, per se. We do need to react to all the incidents that the solution finds. We have to triage them if we find false positive or test credentials. It is reacting to GitGuardian's information. We don't have to do anything else.

Four or five people from my team are monitoring the solution.

I haven't seen any problem with its scaling. We pay per repository, or something like that, but otherwise it is very agile and fast. 

We didn't have to use the technical support for anything. The solution has worked great and we haven't had any issues. We have just had questions, specifically regarding RBAC and self-service type of stuff, but that is more roadmap development.

We actually have a lot of tools for developers to handle and manage their secrets in regards to whatever applications or code they develop, but not all of the teams and developers know how to use those properly. This causes secrets ending up in our codebase. Before we had GitGuardian, we did not understand that certain teams had this blind spot. We thought, "Oh, they know what they are doing. They just forgot, made a mistake, or committed some code by accident." However, we found out some of them had some learning to do.

The initial setup is very quick and simple to do. It takes a few minutes and about 10 clicks to do it.

As an engineer, I am not paying for it. We just implement and use it. After using it in the trial, we went into a long-term contract with GitGuardian. That is definitely the business deciding that it is worth it. It is paying for itself.

We realized the benefits from it immediately. We started with a 30-day demo and said, "Just clean up our repository. We will be happy with that." However, it was so useful. It was immediately obvious that it would save our bacon in many situations. We decided to keep it.

GitGuardian Internal Monitoring has helped increase our secrets detection rate by several orders of magnitude. This is a hard metric to get. For example, if we knew what our secrets were and where they were, we wouldn't need GitGuardian or these types of solutions. There could be a million more secrets that GitGuardian doesn't detect, but it is basically impossible to find them by searching for them.

There are the obvious benefits, but they are very hard to count in the security business. Until you get hacked or compromised, your costs are zero, but then you are destroyed. So,  the relationship between cost and time savings is a hard thing to measure. GitGuardian is pulling a lot of the hard work when it comes to this, as it was one of our biggest holes in our security, and GitGuardian plugs it up completely.

We had issues that were ongoing for a long time before we had GitGuardian. I remember that it once took us a month to understand that we did something very bad. GitGuardian would have caught that in a minute. A month in, it was a lot harder to remediate because the solution was pushed out to other teams. It was used by a bunch of people, then we had to take it down and reset everything, etc. It was a much bigger downtime than it could have been.

It could be cheaper. When GitHub secrets monitoring solution goes to general access and general availability, GitGuardian might be in a little bit of trouble from the competition, and maybe then they might lower their prices. The GitGuardian solution is great. I'm just concerned that they're not GitHub.

We played around with others. GitHub has a big advantage because they are GitHub. Their focus is on zero false positives, but we would rather have a few false positives and get everything.

We tried TruffleHog once. I don't remember why, but it didn't work quite right for us. We did see a lot more secrets being detected by GitGuardian than TruffleHog.

We ran GitGuardian and TruffleHog in parallel. We noticed that GitGuardian was finding a bunch of random secrets that TruffleHog did not. I think that GitGuardian is using machine learning, or something like that, to understand Azure, AWS, Google API keys, or standard secrets very commonly pushed into GitHub. They figure out even random API keys or secrets that developers made up by themselves and put them in their code. Other solutions do not detect these unless we put a specific rule for that, but how can we put a rule for something that a developer just thought up in their head.

GitGuardian's surveillance perimeter is better for removing blind spots than any of the other products that we tested.

With the Git solutions, we spent a lot of time doing research. Because we have a big contract with GitHub, we were leaning heavily towards them. GitHub relies on some very hard-coded rules that they build themselves about, "What do secrets look like? What does a password look like? What does a key look like?" If you want to catch new types of secrets, you need to make the rules yourself or wait until GitHub adds new rules. While GitGuardian is very flexible, it will show you, "Hey, we think this might be something that you should look at." Then, we just say, "No, it's not," or, "Oh my God. That is definitely something that we should look at." That is the main advantage of GitGuardian.

This is where they are at a disadvantage. One of our biggest issues is that GitGuardian doesn't just search the code as it is right now. It searches the whole history of your code change in every repository. So, if we ever push a secret, even if you deleted it, it is still in the history because that is how Git works. We can reset those keys, secrets, and even delete them from the history itself. We can rewrite the history so they were never there to begin with if you search for them now. What we cannot do is delete them from pull requests and such. Those pull requests are controlled by GitHub and only GitHub can do it. We actually have to call GitHub support to erase the secrets from our requests. So, it's not really GitGuardian's problem; it's GitHub's.

We don't use it for monitoring our developer's public activities. We just focus on our own secrets. We are slowly building up our operational security and our security in general to Git. Right now, we are waiting for improvement in the RBAC support for GitGuardian.

I would say, "Good luck," to someone who says secrets detection isn't a priority. Their priorities are probably wrong. One of the easiest ways for intrusion, as well as losing a lot of money in your company, is getting your secrets leaked somehow.

Secrets detection to a security program for application development is one of the most important things. There are a few stages that application development goes through, it is:

1. on the developer's machine
2. in the code repository
3. packaged as an application
4. then it is running somewhere.

All these steps have to be secured and taken care of. The application itself needs to be secure from a hacker coming in and trying to use brute force or exploit some software. All of these steps need to be airtight since your security is only as strong as your weakest link. This is so you can make very modern, secure applications. However, if your secrets are in your GitHub and anybody can see them, then those people who have access to one application or code repository, then can see your secrets. They can then take that and do a lot of stuff with it.

I would go with nine out of 10. It would be almost a 10 if it had RBAC.

We are using GitGuardian Internal Monitoring on our GitHub Enterprise repositories to make sure that our developers are not introducing any secrets into the code. Those secrets could be things like database passwords, connection strings, or AWS credentials. We use it when they commit code to our GitHub internal repositories.

We want to make sure that none of our secrets get committed and GitGuardian is doing a great job identifying them. It has the ability to scan our repositories and identify older commits that have secrets, meaning in code that was committed even four or five years ago, and that has gone unnoticed until we implemented GitGuardian.

Most of our dev teams have a GitGuardian CLI installed on their local machines. Even before a commit gets to GitHub, the CLI identifies secrets within the code and doesn't allow the commit to go ahead. That drastically reduced the number of secrets being committed.

We use Azure DevOps for our CICD and GitGuardian helps support a shift-left strategy. There is all the pipeline-related code that is checked into the repositories and secrets tend to creep into that code, such as RAML files and environment secrets. GitGuardian helps us identify those secrets when they are committed. Not all our dev teams are using GitGuardian's CLI—we are trying to get them to adopt it 100 percent, but we're not there yet—and there are occasions where someone is testing out a pipeline and, by mistake, they don't declare the secrets properly in the code that is being checked into Azure. We get notified and, immediately, the teams work to remove those secrets.

Historically, in our organization, people have been committing AWS secrets, such as access IDs and secret code into our GitHub repositories, because they were testing out something. It could be that they were doing a PoC, and not implementing a full-blown secrets manager where they store and pull the secrets from. After implementing GitGuardian, we were notified of these secrets immediately. And even though they were doing PoCs, we were able to get them revoked immediately, which means removing the secrets from AWS as well as the code and issuing new secrets.

We were also able to help the teams to use AWS Secrets Manager or the Vault to store their secrets. GitGuardian actually provides sample code snippets, which are pretty decent, for pulling secrets from AWS Secrets Manager or Vault.

In addition, the solution has increased our secrets detection rate by almost 100 percent. Pretty much any secret that gets committed is identified and the team is notified. We have almost 100 percent coverage and that is pretty robust.

When it comes to our security team's productivity, because our processes are being monitored by GitGuardian, we don't have to run any scripts or scans or out-of-the-box solutions. We don't worry about secrets being leaked or introduced into our repositories. We rely on the product to keep us aware of our secrets management in our repositories and that enables our security team to focus on other security-related tasks. They don't have to spend a lot of time worrying about how to detect issues and, instead, depend on GitGuardian. They have confidence in the ability of the product to identify the types of secrets that our people are committing. They are definitely being flagged.

Now, we may be spending a couple of hours and a week addressing incidents that come up or addressing the old ones that are still being tracked for remediation. We had around 500 secrets management incidents when we fully implemented GitGuardian. We are now down to 20 or 30, which are old but still need remediation. Those old secrets have been revoked, but they are still sitting in our GitHub history. We need to reach out to GitHub support to get those taken out, replace those repositories, and run garbage collection on them.

And because identification of the secrets being introduced is almost instant, the pull request doesn't go through, and Slack alerts are immediately sent out. As a result, the mean time to remediation is within a day, if not even sooner. These secrets are mainly dummy secrets that people are using for testing code. But we don't want even those to be introduced. The idea is to have teams use secrets management services like AWS Secrets Manager or Vault from the get-go. We are close to 90 percent utilization of AWS Secrets Manager or Vault to store secrets because of GitGuardian Internal Monitoring.

We mainly depend on its ability to identify secrets and we also use the entire workflow of secrets management. That means we're able not only to identify secrets, but we can reach out to the owners of those repositories by opening up an incident ticket within GitGuardian. It actually creates an incident ticket for us. We can now go end-to-end after a secret has been identified, to track down who owns the repository and who is responsible for cleaning it up. We can also monitor what actions they are taking, such as revoking the secrets and ultimately closing out an incident, making sure that commit no longer has any secrets.

We tested out the secret identification using thousands of samples and some of them were purely false positives. GitGuardian was able to identify 85 to 90 percent of the false positives. We are fairly confident when we see a secret reported. Of course, we always verify them before we chase down teams to fix them.

We have defined our teams and their members so the teams are typically associated with the repositories on GitHub. Whenever a secret is identified, those team members are immediately notified by GitGuardian via an email and a Slack message, thanks to integration with Slack. In addition, the application security team also gets the information in the Slack message and we can keep track of the remediation efforts.

I would like to see more fine-grained access controls when tickets are assigned for incidents. I would like the ability to provide more controls to the team leads or the product managers so that they can drive what we, the AppSec team, are doing. They should have the ability to close out tickets and we would review them. 

Right now, we cannot give them that control because if they close out a ticket, we won't have the visibility into them unless we build something with the APIs that GitGuardian provides. 

The UI has matured quite a bit since we started using it, and they have introduced new features, such as the teams feature. That was introduced three or four months ago. We put in the requests for such features. There are a few more requests that we think would make the product even better, and one of them is that fine-grained access control so that we have additional roles we can assign to other teams. That would help things to be more of a self-service model.

I have been using GitGuardian Internal Monitoring for almost two years.

Very rarely does GitGuardian go down or the monitoring fail or we have issues with the APIs. It's available 95 percent of the time. There have been a few times when we were notified that the service would be down because of maintenance. Like with any product, there are maintenance windows, which are not a problem. But I don't recall more than one or two instances of the internal monitoring not being available when we expected it to be.

We have a lot of repositories and we have not had a problem with GitGuardian monitoring all of them and doing what it is supposed to do. Deploying it at scale is pretty much seamless. You don't have to do anything special once you have onboarded it. GitGuardian has the ability to scan all the repositories in your GitHub Enterprise account, if that is what you choose to do. 

There are no performance issues. We have around 800 or 900 active repositories and 400 that are archived. We have quite a big code base to cover but there are no additional tasks needed to scale it as your number of repositories increases.

We have contacted their support about a few enhancements. In addition, we came across a couple of UI bugs where the stylesheet didn't render properly and the information we were looking for was overlapped by some other UI elements. But they were very quick fixes. 

We also had some rate-limiting issues with the APIs and they were fixed early on in our engagement.

They are very responsive and have a fairly quick turnaround time. We have developed quite a good rapport, not only with the customer support team but with their support engineers as well. 

Initially, we had calls once a month and now we have calls about once a quarter. They get on a call with us to find out if we have any pain points or new feature requests.

Positive

To start using GitGuardian there is some groundwork that needs to be done. You start off with a few repositories and do a trial to get an understanding of how the UI works. You have to give permissions to GitGuardian to access your internal depositories and then organize the repositories around team structure. Those are the housekeeping tasks that need to be done to onboard with GitGuardian.

Initially, to get the program up and running, we relied on GigGuardian's playbooks quite a bit, and we do refer to them whenever the need arises. When you're starting off with GitGuardian and secrets management, GitGuardian lays out the basics of why it is a bad idea to have your secrets committed to internal or external repositories and the dangers associated with that practice. They outline baby steps to start taking control of secrets being committed. 

They also give you good guidelines on how to use ggshield, which is their CLI product, as well as the web UI, and how to organize your teams and repositories around GitGuardian. 

For AppSec teams, playbooks give you the ability to control what the repository owners are capable of through permissions. For example, you don't want all team members to have permission to repress incidents that are identified. We'd rather have them as collaborators or viewers. They can view the incident and fix it, while the AppSec team can actually suppress the incident and use the functionalities of the management console within GitGuardian. All these features are part of its playbooks. They're a good resource.

The playbooks helped us to understand how the product works and what we needed. They helped my team to implement GitGuardian in the most effective manner, such as how to use the product better to manage workflows.

In terms of maintenance of GitGuardian, there is none required on our side.

We looked at a few other solutions before we started to work with GitGuardian and what we found was that it provides the best solution for secrets management. We have a few other products that we use within our systems, products that also provide secrets management, but they don't come anywhere close to GitGuardian's ability to detect secrets, track them, and ultimately, get rid of them. GitGuardian is the leader in this space. Many times, what we identify in GitGuardian is not identified by those products.

I would tell a security colleague, using an open-source secrets detection solution at another company, to take a good look at GitGuardian. It definitely helps not only manage secrets but also the entire workflow around secrets management, from detection to remediation. It helps put best practices in place. It would save them quite a bit of time, rather than using an open-source solution. Open source is okay for some features, but you don't have all the tools you need for full-blown secrets management in the organization. That's what you get when you use GitGuardian.

Secrets detection is as important, if not more important, to a security program as having a firewall and a vulnerability management program. Your secrets are the easiest way for bad actors to access your environment, without doing any work at all. You need to lock down what type of information is being committed to both your open-source and internal repositories to ensure that no secrets are being committed. And if you have any secrets that were committed in the past, you need to identify them and make sure they are removed and, if possible, reach out to the organization, like GitHub, and work with their support teams to clean up the history as much as possible. Secrets committed in your repositories are keys to your organization's infrastructure.

We have been retraining our teams to not commit even false or dummy secrets into the repository. It's fine for them to do a test but we don't want to have to deal with false positives. Getting distracted by even 10 percent of false positives is not fun. Rebasing the commits is a pain. That retraining, to not use even dummy secrets, has worked for us to reduce the number of secrets being committed.

In addition, we had a number of brown bag sessions with our dev teams over the course of several months, where we would demo what secrets we found on GitHub repositories and how GitGuardian is helping us identify them. The idea was to make them more aware that this tool is monitoring all the repositories and every commit is being scanned. But the goal was to ensure that secrets don't even get to the point of being committed. And when someone mistakenly commits a secret, they immediately inform us. Dev teams are now trained not to do it, but if something happens by mistake, they are immediately on top of it to revoke it themselves and inform us. We have everything recorded on GitGuardian, but proactive action is being taken.