My main use case for GitGuardian Platform is monitoring the repositories for exposed secrets and credentials and reviewing security alerts. I also use it to remediate any findings that come up. The majority of the time we are thinking about potential secret exposure across repositories and prioritizing the findings which need attention. GitGuardian Platform gives a good additional layer of security alongside our existing practices. A specific example of a time when GitGuardian Platform helped me catch and fix an exposed secret is when developers hardcode API credentials while developing. There is always a chance that a developer makes a mistake and hardens an API credential in a repository. We are able to identify and remove the credentials, rotating them before they could be misused. This is a quick specific example we have encountered, and it is usual for anyone.
My main use case for GitGuardian Platform is secret detection. Every time we open a pull request, it scans the pull request and ensures that we did not accidentally put a database password in a pull request. That process has worked very well for my team as it has caught several things, it is very helpful, and it is easy to use.
I use GitGuardian Platform to ensure that there are no secrets committed, such as hardcoded values, database credentials, API keys, or any secrets that could be exposed to external users of our application. To maintain security and data accuracy, confidential data should not be shared with other platforms. GitGuardian Platform checks our local code first, then it passes through our CI/CD pipeline as well. When we push code to GitHub, it scans and sends a report via Gmail, so we have to fix those security vulnerabilities.
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.
We use it to detect if our engineers are leaking secrets on public GitHub repositories. If any Payfit employee is leaking secrets in their own repositories or, in the Payfit repositories, they will be flagged by either the GitGuardian internal solution or the public one.
GitGuardian is the credential layer security platform for securing the secrets that let code, machines, and AI agents access systems and act as trusted identities. API keys, tokens, passwords, and other secrets carry real access. When they leak, attackers do not need to break in, they can log in. The scale of the problem keeps growing: 28.6 million new secrets were exposed on public GitHub in 2025, a 34% year-over-year increase and the largest jump on record.
GitGuardian finds the secrets...
My main use case for GitGuardian Platform is monitoring the repositories for exposed secrets and credentials and reviewing security alerts. I also use it to remediate any findings that come up. The majority of the time we are thinking about potential secret exposure across repositories and prioritizing the findings which need attention. GitGuardian Platform gives a good additional layer of security alongside our existing practices. A specific example of a time when GitGuardian Platform helped me catch and fix an exposed secret is when developers hardcode API credentials while developing. There is always a chance that a developer makes a mistake and hardens an API credential in a repository. We are able to identify and remove the credentials, rotating them before they could be misused. This is a quick specific example we have encountered, and it is usual for anyone.
My main use case for GitGuardian Platform is secret detection. Every time we open a pull request, it scans the pull request and ensures that we did not accidentally put a database password in a pull request. That process has worked very well for my team as it has caught several things, it is very helpful, and it is easy to use.
I use GitGuardian Platform to ensure that there are no secrets committed, such as hardcoded values, database credentials, API keys, or any secrets that could be exposed to external users of our application. To maintain security and data accuracy, confidential data should not be shared with other platforms. GitGuardian Platform checks our local code first, then it passes through our CI/CD pipeline as well. When we push code to GitHub, it scans and sends a report via Gmail, so we have to fix those security vulnerabilities.
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.
We use GitGuardian Public Monitoring for code that is exposed in public.
We use it to detect if our engineers are leaking secrets on public GitHub repositories. If any Payfit employee is leaking secrets in their own repositories or, in the Payfit repositories, they will be flagged by either the GitGuardian internal solution or the public one.