Hello and welcome to another video.Today we're going to take a look at GitGuardian's internal monitoring solution and how this can prevent leaking sensitive information like api keys database credentials or security certificates into your git repositories. Now leaked secrets, as we call them, are a massive security threat for developers and regardless of whether or not you have a private or public repository, having secrets inside these pose a large security threat. This is because these systems are not designed to handle sensitive information and there's no way of knowing where these end up or where they sprawl to. So today we're going to take a tour through the GitGuardians internal repository monitoring solution. I'm going to show you all the features, and how to quickly set it up and this is going to be the first in a series of videos that will look at different GitGuardian products such as how to install a pre-commit hook with GG-shield or how we can use pipelines or actions on different platforms like GitHub GitLab or BitBucket to prevent secrets from entering into your repository. So let's get started.So GitGuardian is free for individual developers, open source organizations or small teams, small teams of under 25 developers. To sign up for free all you need to do is head over to the GitGuardian website at the top right-hand corner click sign up for free.Because I use GitHub I'm just going to use my GitHub credentials to log in with GitGuardian and create an account. And here I get the option to install on all of my repositories, or only a select few repositories. Now, of course, I want GitGuardian to monitor all of my repositories, but if you're working on different projects and you have different permissions or you don't want to give access to certain repositories then you can select individual repositories here but as I said I'm installing it on all repositories so then I'm going to click install. Just quickly give my credentials And there you have it, we're immediately in the dashboard now. I'm on my perimeter and it's already done a scan a historical scan of all my repositories. To launch a historical scan manually all you need to do is click over on the three dots and click launch historical scan. Now what you'll see here is various different projects that I have and what you'll notice is that, well, I haven't been maintaining good practices because I have a lot of secrets in these repositories, some of which are public. I can view just the incidents within these repositories by clicking here but I want to be able to look at all of my incidents on one page, so I'm going to head over to the incidents tabs and here is going to provide me with a list of all the secrets that have been triggered. Now on the incidents tab, we can see some key information right off the bat, we can see that it's added a tag here if it's a public repository, these are critical because these are exposed to the public and are an active threat. So obviously i want to take care of these first, it also lets me know where they found it, all of mine are from an historical scan because i've just signed up. It also lets me know what the secret is, a slack token, an AWS key, so let's click on one of these and see what comes up. Here it has the secret itself, now obviously an AWS key is fairly critical, especially one that's publicly exposed, so I'm going to assign this to critical. This just means if I'm working with teams and other people are that are using this dashboard as well then they're going to be able to see the type of incident that this was this helps you prioritize particularly if you're working in a security team. I also can assign these, now I'm the only person in this dashboard right now but as I said if I'm working into a team I can assign different incidents to different team members now at the top of the incident I see important information when the commit was made and who is it by. if this is done by a member of your team let's say what you can do is you can share this incident with them so this creates a link. You can email this link to your team member and this is the information that they'll get they'll get all the information about the type of incident that happened that's available on the dashboard but there'll also be a questionnaire down the bottom is this an actual secret or is it perhaps a testing credential so this time yes it's an actual secret does this give access to a service, yes it does has a secret been revoked no it's still active and i can also add any notes oops I must provide my email, and then I can submit that for review. Back in the dashboard, you can see this information here my additional remarks and my answers to the questionnaire. Why this is crucial is if you're dealing with large teams and you have lots of incidents you want to get as much information as possible because you need to remediate these quickly. So this is really quite a cool feature but again, if you're just an individual developer working on your own projects this sharing feature isn't going to be so critical for you, but one thing that you are going to want to keep track of is whether or not you have remediated these secrets, so down here we can click resolve we can say that this is 'sensitive but we chose not to revoke it' or that it is 'sensitive and i did revoke it' i can also ignore it if for say this is a test credential and a false positive. Now that means that you can keep on track of it, and, if you have lots of incidents then you have a record of when you resolve them and what ones are still outstanding that's really important to make sure that you stay on top of your incident management. Now I'm going to head over to the second page because I want to look at a different incident now here on March 29th you'll see that it's another outstanding incident but this has another tag to it, and that tag is saying test file, now it's still raising this as an incident but what it's also giving you the information is that based on weak signals perhaps there's keywords within the file or the file name itself which indicates that this isn't actually going to be a real credential and it's within a test file. Obviously, you still need to look at this remediator and take appropriate action, but it's good to be able to see that information from your list of incidents particularly if you have a lot to resolve. Next i want to take a quick look at the analytics tab, now this is going to give you key information and even though we just installed GitGuardian it's still going to pull in analytics as if it's been running the entire time which is really quite a cool feature when you want to get information right from day one. I've got here information from the last year but you can set your own date range now immediately it lets me know what are the top five secrets that it's detected you can see that i've got Slack user tokens SlackBot tokens AWS keys so it's fairly critical information, you also see where the incidents have happened over the time over the last calendar year let me know in what repositories these incidents have happened in so where do i need to focus my attention. And obviously as you can see we have a lot of incidents in one particular repository over the last year and then as you scroll down you can see some performance of how you're doing in your remediation either as a team or as an individual so we just resolved one secret today so we get a thumbs up and our first but as we keep going we should be able to track some interesting information about how we're performing as a team as a developer as a group as a project to see if we're improving over time. Then just down a little bit we have some information about our real-time scanning so we've just done historical scans, but the cool thing about GitGuardian is in real time it's going to monitor every commit that you make so if you ever leak a secret in the future, it will detect it and alert you immediately and using this information it's also going to give you some key insights such as how many commits it's scanned how many secrets are occurring per every 1,000 commits. This will fill over time and be important when you're looking back and tracking your progress. Down the bottom we have the last section dedicated to shifting left, if you don't know Shift Left is a term used in security to move security to the start of the software development life cycle from the end to the beginning or to the left get guardian has some great tools to help you catch secrets before they enter your git repository and these will actually be displayed on your dashboard how many secrets did you prevent from getting into your git repositories. But we'll save this for a video of another day, next i'm going to head over to the integrations tab i'm integrated into GitHub but if you're using BitBucket GitHub Enterprise or GitLab you can still use this product and integrate it natively we can also integrate into your Ci/CD pipelines which we'll cover in another videos. But as we go down you'll see that we have native integrations for alerting platforms so if you're using an alerting system such as Slack, Pagerduty, Discord then you can receive GitGuardian alerts when a secret is leaked into these systems so this means that you'll be notified of alert in the fastest possible way based on your workflow. These are incredibly easy to set up and we also have custom webhooks if the platform that you're using isn't mentioned here now. Lastly I want to take a quick tour at the settings page because we can actually adjust some really powerful features of how we want our detection engines to work. The first tab is secret detectors now GitGuardian has nearly 300 detectors at the time of this video and you can see these all down below, in fact, we have 299 detectors as of right now. Part of me wishes I waited a couple of days to make this video so at least I could say we have 300. What you'll see here is that you can turn on and off each detector, so if one detector, perhaps a generic detector that isn't associated to a specific provider, is providing a lot of false positives, then you can turn that off. You also see a column here that says frequency this is the frequency per million commits that GitGuardian finds this particular secret or this particular detector is triggered. Now this is from public monitoring across all of GitHub so it's not specifically related just to you but lets you know what are the key areas that you're going to need to look out for. If we scroll down here you'll see file path exclusions now this is actually a really helpful feature because let's say that you have some test environments that have some test credentials in them and you don't want to get an alert each time these are updated so what you can do is you can exclude that file path from within your repository. So let's say it's your application folder and inside that you have a test folder, we can exclude all of that test folder from being scanned and preventing you from getting false alerts, so that can be really cool feature to help reduce the number of alerts that you're getting.Not get overwhelmed by alert fatigue next we're going to take a look at policies now in addition to detecting secrets we can also detect other things that indicate a security breach. So for instance sensitive file names now the sensitive file names are files that typically contain secrets within them for instance a '.env' file this should really not be inside your git repository regardless and is a very high candidate for finding secrets in it. Same with a file called .gitcredentials and so on. Now if you want to ignore this let's say that you really feel the need to have an environment variable file in your project and you can simply unclick this and you won't receive an alert if a emv file is put in there. Same for file extensions, for instance if you want to be alerted when a .pem file, which is a cryptography file relating to security certificates, we will alert you when one of such files is inside your repository, because it's a high likelihood that it's going to contain a secret. But again you can turn these off and on as you wish, and the last option down here is the .gitignore. It's best practice to always regardless include a dot get ignore file within your get repository this will mean that it will prevent a .env or .pem files such as we just talked about from actually being included in your git repository even if they're stored in your local get cache.What this feature does is it does not a dot get ignore file present it will alert you and raise an incident, so this just means that you can be alerted, if for whatever reason your repository doesn't have a .gitignore file and of course like on all elements of GitGuardian, we have an activity log so you know which team members have done what so if you're working in a team and you want to keep track of remediation and changes and policies this will always be displayed in the GitGuardian dashboard. If you're working in a team you may wish to add other members of your security team or just your project leads into the guardian dashboard so that they can interact and see what's going on you can send anyone an invite we'll send them an email and they can join up to be in your same workspace and then you'll be able to assign tasks to each other from here. As i mentioned at the start GitGuardian is free for teams with less than 25 developers now if you are working in a team you may notice that by default you can't add shared repositories into the GitGuardian dashboard that's because we automatically assign everyone the developer and open source plan and this excludes shared repositories, but don't worry you can still get the full business plan for free you just need to start a 30 day free trial and then email us at or the name of your company or project and explain that you are a small team and we'll upgrade you for free to the latest business plan. I hope you'll stay tuned for some of the other videos that we're going to run through such as using gg shield or using the GitGuardian API and where we can integrate this into different areas of our software development life cycle to prevent secrets from sprawling and of course if you get stuck you can always head to the GitGuardian documentation page where you'll find answers to most of your questions and if the answer is not there then feel free to reach out to me directly at Mackenzie,jackson@gitguardian.com i'm here to help :)