What is your primary use case for GitGuardian Internal Monitoring ?

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.

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

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.

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.

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.

GitGuardian Internal Monitoring is a tool we use to deal with internal credential leaks. We found that our development teams included sensitive credentials in merge requests with concerning frequency in the early days of our startup. We have 45 GitGuardian users. Most are developers or engineering managers, and a few are security team members. Our development team is much larger than our security team, so GitGuardian's ability to pull developers in and turn them into security analysts is quite helpful. GitGuardian notifies developers of the credential leak they created and lets them take the appropriate steps to remediate it. That's preferable to having our limited security team take care of it for them.

We use GitGuardian to check standard configurations and scan for possible leaked secrets. Developers and software engineers sometimes commit to AWS keys, login credentials, SMTP databases, and other secrets.

We use GitGuardian to detect secrets in our source code. Two security engineers use GitGuardian, and developers access it when they commit issues. We've had four developers who have accidentally committed something. We are currently using it extensively and plan to scale it to every new repository we add.

We use it for detecting secrets in our code repositories.

Since we have a lot of internal teams, the main team running this tool is composed of developers. Because of the security aspects of GitGuardian, they figured that we needed to bridge the gaps and work together. GitGuardian creates a lot of alerts in the code. If someone uses new passwords or secrets, then we can see in which repository as well as who used it and left their password in the code. We monitor these things. However, they haven't given us a permission to work with alerts since it is more for analysis purposes right now, seeing what problems we have in the company, e.g., we are seeing a lot of people just dumping passwords in the code, which is not a good approach. Our main strategy is focusing on moving testing quality and performance earlier on in the development process. Developers are focusing on this quite heavily. We are using the latest version.

The main goal is to be alerted and to react when a secret has been leaked in our code base. We have GitGuardian linked to our code-based storage on GitHub. GitGuardian also has a notification integration with Slack which is what we use internally for communication. We are alerted on Slack, "There's an incident here on GitGuardian for a secret leak on GitHub." From there, we can go into incidents and start managing the incident.

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.

We procured it as a secrets and code detection solution. We have code bases, some of which are 10-years-old. We needed a way to comb through all of the Git histories to see if any developers had committed secrets to our code in the past as well as catch any new secrets that developers may accidentally commit in the future. We are using GitGuardian Internal Monitoring.

We use it for secrets detection.

We monitor our GitHub repositories for security violations and secrets. We have our organization on github.com for infrastructure as code and our use case is to find security violations as soon as possible. When development uses active tokens or passwords on github.com, we need to immediately escalate things to the right person, so they will be removed. We started with public monitoring and switched to internal.

Mainly we use GitGuardian to keep secrets out of our source code. That is something that we wanted to get serious about getting our hands around. This was the main driver because I had tried other tools like TruffleHog. It was cumbersome to manage the unwieldy Git history and to figure out. When you run TruffleHog, you have no way of knowing what's in the current branch versus your Git history. Hence, it's tough to decipher what secrets are still possibly valid.

In general, we use Gitguardian as a safety net. We have our internal tools for validating that there is no sensitive data in there. GitGuardian is a more general and robust solution to double-check our work and make sure that if we are committing something, it only contains development IDs and not anything that is production-centric or customer-centric. The main way in which we're using it at the moment is that it is connected through the GitHub integration. It is deployed through our code review process. When pull requests are created they connect with GitGuardian, which runs the scan before there is a review by one of our senior devs. That means we can see if there are any potential risk items before the code goes into the main branch.