What advice do you have for others considering GitGuardian Internal Monitoring ?

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.

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.

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.

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.

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.

I rate GitGuardian Internal Monitoring a ten out of ten. GitGuardian is my favorite security tool. It is a joy to use and so effective. I highly recommend trying GitGuardian. It's easy to set up and provides extremely accurate results. If I could only pick one tool for application security, this would be it. The biggest lesson I've learned using GitGuardian is just how many credentials make it into source control. It is much more frequent than I would've ever believed. I'm not immune as a developer. I've accidentally committed credentials and tried to remove them with limited success. GitGuardian is a platform that pushes the envelope on detection and response. It has become one of the cornerstones of any application security program.

I rate GitGuardian a ten out of ten. It's a user-friendly product that's ready to go. You don't need anything besides the initial onboarding training to use this tool. If you are concerned about your security and want something ready to go, GitGuardian is an excellent option for a fair price. I recommend it. GitGuardian is a better choice than an open source solution if you are serious about preventing leaks on GitHub and your developers lack security awareness. Secret detection is one of the essential aspects of application development. Leaked secrets are the main reasons for getting hacked. Often, secrets are leaked by an employee searching and finding secrets they should not, or someone makes a private post public because they don't know the secrets were there. Many bad situations happen because developers don't know what they are doing or don't care. The company mindset needs to change, but we still have a long way to go.

I rate GitGuardian Internal Monitoring a ten out of ten. Secrets are the keys to the castle. Once somebody has the password to a system, they can access it. I suggest trying GitGuarding on a public repository to see how easy it is to set up. GitGuardian has opened my eyes to how often these mistakes happen and how sensitive data can end up in your source control.

In response to a security colleague who said that secrets detection is not a priority, I would ask what service they are using and what the pros and cons are of that service. And I would also tell them to compare their service with GitGuardian. Secrets detection is very important to security. The biggest lesson we have used from using GitGuardian is that we should have started using it earlier.

There are product owners, senior developers, and day-to-day developers using this solution. There are 40 members connected to it, including 35 developers who are using it. My colleagues and I spend at least two hours a day going to the dashboard and looking into things. If a security colleague at another company said, "Secrets detection is not a priority," then he is a very bad guy. It is a huge problem now with all the secrets in the code. It is important to monitor them, as it is a growing problem. I just heard a podcast this morning about security, where they talked about Symantec who did a research study about this particular issue. It seems like a lot of apps have this problem. It is really important to monitor these things and know about them in the code. Otherwise, you risk exposing things, then malicious actors can use them. The security guy needs to go back to school, do some training, and really be open-minded about it since it is a growing problem. It will continue to grow as a problem since a lot of developers forget that IT security aspect. They just copy and paste stuff, then leave it in the code and forget about it. That is how attacks happen; somebody slipped, making a mistake or misconfiguration. Secrets detection to a security program is very important for application development because developers are just ignoring it. They just commit the code, then the secrets are there. I feel GitGuardian is a good tool because it shows this to your face. As we continue monitoring, we plan to do a presentation of our findings to management. Overall, I would give it a seven out of 10. There are a lot of good things about GitGuardian, but there were some hiccups with the development. I feel there are some small things that are not working for our developer team. The solution is great, but it would be bad to say, "10," without acknowledging some of the problems. So, seven is good and fair.

The tool itself mainly helps us with detection. The whole remediation is done outside of the tool. Once GitGuardian has detected a secret leak, we are alerted and an incident is created in the tool itself. After that, the revocation or rotation of the secret will be done outside of the tool. We use GitGuardian to track the incident and the comments on it, but we don't really manage the secrets directly in it. We had some issues with the Dev in the loop feature, so we don't use it that much. Dev in the loop is used to share an incident with the developer who committed the secret. But to manage our database in our GitHub organization, we let our developers use their personal emails. Because an email is sent to that address about a secret leak, we are not very fond of it. It works well and is helpful because we don't have to manually send a message to the developer for an incident. We can let the developer manage the whole thing on their own, which is good. We just have this email issue, but other than that, the feature in itself works well. If a security colleague at another company were to say to me that secrets detection is not a priority, I would disagree. The risk is pretty big when you think about what a secrets leak could do. You don't need to start with a solution like this when your company has, say, five people. But at a certain point, you definitely have to have a secrets detection tool.

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: * on the developer's machine * in the code repository * packaged as an application * 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.

My advice would be to talk with them about your needs. There are different use cases between security personnel working with GitGuardian versus developer personnel working with GitGuardian. Secrets being used to access resources is probably one of the most common ways to be involved in a high profile breach these days. If you are not detecting secrets in code, then every developer's machine is a security breach waiting to happen. A developer in your org is going to leave their laptop at a coffee shop one of these days. If they have the code base checked out, and there are valid secrets in that code base, then it is only a matter of time before they get used to accessing resources that they are unauthorized to access. This is one of the higher priority things right now because developers are way more likely to commit secrets than I would have ever expected. We haven't adopted any of the GitGuardian's shield functionalities. We just haven't taken the time to roll that out to all our developers. They have the functionality there, and it works great, but we haven't been able to prioritize the rollout on our end. Security engineering is using the solution pretty extensively. We are not making use of a lot of the shift-left features. We would like to roll them out over the course of the coming year. I have been super happy with it. I would rate this solution as nine out of 10. I am just leaving room for building out more features for looping in developers.

If someone at another company were to say to me that secrets detection is not a priority, I would say that's not a very smart approach. Secrets detection is a very essential part of security. It's one of the basics that you need to cover all the time. Otherwise, you're going to expose your endpoints online and you're going to suffer endless attacks. You definitely need to have secrets detection tools. We use a combination of tools, but GitGuardian is my preferred tool. When it comes to application development, secrets detection is essential to a security program. You need to have it. Otherwise, you'll fail. In this technology, nothing is perfect yet and it's going to take time. But so far, GitGuardian is the best I've seen. Overall, it's a very good product.

If a colleague in security at another company were to tell me that secrets detection isn't a priority, I would tell him I highly recommend this product. We have achieved very good results. Secrets detection is one of the top-five priorities in a security program for any development. It defends the company's interests and secrets. There's an old saying, "You cannot trust your developers." You always need to check their work. The only issue that I can see is that sometimes an organization deploys a tool but does not utilize it as much as it could. That is the impression I have gotten from speaking with my colleagues at different companies. Overall, I like this tool. We have used it for a few years and I'm very impressed. I'm happy with it as a tool and with the vendor as a company.

I rate GitGuardian 10 out of 10. It does everything that I need it to do, and I'm excited about the new features that are coming along at this point. It has really helped us change our culture, and it's impressive to see that. People are now more mindful of what gets committed to source code. I would recommend GitGuardian.

I would advise others to give it a try. It is easy enough to integrate with your process, and you'll see the value right away, with a couple of quick test scenarios. Once you see it in action, it sells itself. If a colleague at another company said to me that secrets detection is not a priority, I would ask what is more of a priority, and then I would point to a quick Google search with a myriad of issues and data breaches that have happened from leaked secrets. That is pretty easy to find. If leaks are happening, and there is a reasonable plan, or even a free plan for a small number of users, to deal with them, I don't know how much more bang for your buck you can get. I would tell him to consider the small amount that GitGuardian costs and the value and ease of integration that it provides. Secrets detection is extremely important to a security program for application development, especially on a team of people with various experience levels. Having something automated always improves things. Having that detection on top of any of your manual processes adds an extra layer of safety. Given the ease of integration, it is extremely important and extremely valuable to have that extra layer of protection to warn you if you do forget something. So far, GitGuardian hasn't detected any true secrets in our code. They were only internal credentials, but it has certainly brought a much-needed discussion about those test credentials. Fortunately, we've been successful at not committing production secrets since we started using this solution. The biggest lesson that I've learned from using this solution might not be so much from secret detections, per se. It is about the ease of integration and what going the extra mile actually does. It creates a positive experience, and it also helps in creating a lot of faith in the solution, overall. With the onboarding experience being handled very well, it gave me a lot of confidence that this was the right solution. That's a lesson for our own software. It is super important to have that ease of getting started. That can go a lot farther than you might think for the effort it requires in the overall project. I'm sure a lot more resources are spent on the analysis and the tool itself, but don't skimp on the onboarding. I would rate GitGuardian a nine out of 10. The two areas for improvement are probably the only things that are keeping me from giving it a 10. The major one of those is probably going to be addressed pretty soon. Once we can do some of those custom identifiers or custom rules, it would be a 10.