 So my name is Fernando. I'm a technical marketing manager here at GitLab and I focus mainly on the DevSecOps and active security solutions and do the proof of concepts, different demos on these solutions. So today I'll be giving you a demo on our compliance management, compliance controls and how the GitLab security scans work. I was a former software engineer and I live in Austin, Texas. And now let me kick it off to Cindy. Thanks, Fern. So I've been with GitLab for right at three years, one of the first actually to focus on the security space for GitLab. So I've been in the security industry for a bit and full disclosure I was with Fortify for many years. And I live in Bryan, Texas, which Bryan College Station, better known for the Texas Aggies. So let me kick this off. We're going to touch on a couple of things, but securing your software factory, you know, this is a huge issue now, thanks to the attack on SolarWinds. It really made everyone else themselves, am I doing enough to protect my software factory from the same kinds of threats? And the short answer is probably not, but let's talk about some ways that we can help. You know, even the most damaging attacks tend to rely on complacency toward basic security hygiene, think patches and passwords. And they tend to use tried and true exploits that have been around for a long time. And from what I've read in the news, the SolarWinds admin relied on a simple password and didn't change it. Basic advice in terms of hygiene is revisit your security policies, check your password rotations, apply automation wherever possible, and make sure that those policies are applied consistently. So things like regular key rotations using secret detection, look for hard-coded passwords, which is especially prevalent with APIs. You know, for the SolarWinds Orion app, there was code that was injected during the build process. And what that points out is you really need to treat your software factory like you would any other kind of physical factory. You want to prevent random people from adding random things. You wouldn't want, you know, somebody off the street coming in and slapping something onto a car that's going down the factory line. So think about it as you would any process that you want to improve and measure it and iterate on it. And some of this is going to be forced upon everyone, because as a result of the SolarWinds attack and the gas pipeline disruption, President Biden has announced an executive order to improve the nation's cyber security. Now it may just be the US, but this is going to have far reaching impact beyond federal agencies and software vendors that sell to them. It's also going to reach beyond the US borders. These things here listed are the basic elements that are required. Sounds pretty straightforward, but the devil's in the details. Achieving these things isn't going to be easy. So what can you do now? I've provided six steps that I think will help you prepare for what's coming. The first is automate your CICD. If you haven't, you're really behind the curve. You can't standardize or measure what's not executed in a consistent manner. And this is more than just about efficiency. This is about compliance and auditability. Apply common controls and we're going to look at those a little bit more detail here in just a minute. Apply zero trust beyond the traditional network security. Re-examine your access controls, considering not just network and endpoints and typical things, but software and the infrastructure's code as well. Essentially all points of entry along your software factory and its components. And this is going to require some unconventional techniques and new tools to secure things like APIs, containers and orchestrators. One resource that might be helpful as you think through these is the NIST secure software development framework. I would encourage you to Google that and have a look. I think it's helpful to look at automation and common controls as legs of a stool. You need to standardize and automate the process, but also automate the policies. So when are they applied? How are they used? And the desired remediation. So if a policy's triggered some sort of exception to that policy, how do you want it handled? Can you automate the way that that remediation is handled as much as possible? And you need to consider visibility across your entire software factory. Can you see who changed what where when? You know, it's really hard to do if you're using multiple tools and a really complex DevOps tool chain. One key common control is security scanning. If you're only doing one type of scan, you're missing potential potentially critical vulnerabilities that could be detected by other types of scans. Again, determine your policies, you know, which projects or applications am I going to require the scans be done on and then automate their use using CI templates. But let's look at some other common controls of compliance. And it just occurred to me. Hopefully y'all can see my screen for this part. Okay, good, because I wasn't sure exactly what part I'm sharing. So right now this is listed under financial services regulate regulatory considerations, but this is really common controls across anything. It just happens so happens to be that the financial services industry has articulated them the most clearly. But when you think about common controls, it's things like segregation of duties and configuration management and change management and these things. And this particular page, what I've done is shown how get lab helps you achieve those things. So have a look at that. Because I think that that will be helpful for you. Now let me get back to where I was. Okay. So the when you think about the common controls. It has to do with compliance management, but it's really broader, you know, typically, or historically compliance was kind of a checkbox thing. But I think compliance is taking on a whole new meaning and new life of its own, and really forcing people to think about what's important to secure your software factory. There are elements that if you think about your software factory itself, you really want to manage control points along it. So access, who can change the code, who can approve compliance to policies. So March request approvals, those kinds of things. And Fern's going to give you a little bit of a flavor here, but you need to think more broadly than, than perhaps you have in the past about your software factory. Now, another element here is audit ability. You can you see who changed what where when all along the entire software development life cycle. So be sure and consider how you do that because if you can automate things kind of takes them off the table, a bit from an auditing standpoint because if you can prove that you've got a process in place, you really they just have to audit that the process is working, they don't have to inspect every instance of that. So think about that automation, what automation can help you achieve. A couple quick words here on zero trust. So zero trust is an approach it's not a product it's a process or an approach to architecting your IT environment, and it assumes that the hackers are going to get in. It doesn't try to assume that they'll never get in. It assumes that they will. And so you think of it as protection from the inside out. It's a little bit different mindset and historically it's been applied to network infrastructure and the network, but in this new modern infrastructure and more modern software era. You really need to think about it at a little bit different level than just the physical network. Think about it as eight for API's and the secrets that are passed and and how your software and the infrastructure on which it relies is protected. And why is this important. Well, it can prevent you know lateral movements and attackers not going to go after the front door they're going to go in a side window that's less protected so think about it from that standpoint if they get in that way how are you going to keep them from moving around across clusters across apps and and escalating privileges. And in particular API's containers orchestrators cloud services templates terraform all those kinds of things, and also how you protect your software factory itself. So start with inventorying what your dev team is using. A lot of times the security team isn't even aware of a lot of the tools that are being used, much less considering the access around those. So security needs to start with a conversation with dev. And consider using unconventional scan methods, you know conventional scanners like SAS static analysis dynamic analysis, those are going to find known CVE so vulnerabilities with a known signature basically. These other areas may not have known signatures and there may be things that are very unique to your environment. And so I would suggest that you consider fuzz testing and get lab makes it real easy. Fern will show you how. In fact, Fern's also going to show you how to protect the software's infrastructure in production things like container scanning container host security network security. These things can help protect again that network at a little bit different layer now it's not the physical network it's more of the infrastructure network things like east west traffic among clusters. Controlling access to it's you know allow and deny list those kinds of things. So I think a picture is worth a thousand words. I'm going to stop sharing here I'm going to turn it over to Fern and he's going to show you a demo that that'll really help you understand this more graphically. Awesome. Thank you, Cindy. Yeah, so now everything that Cindy's spoken about I'm going to show you that. And how that works within get lab so let me go ahead and do two things change my camera. And share my screen. So, first thing we're going to go over our compliance management so this is a group called tech marketing where I have a whole bunch of other groups and projects. So if I go to the settings. And I go to compliance frameworks. I see that I can add different labels and create different labels for different compliance frameworks. So here I created one for socks for our GKE clusters. And this is for obtaining socks compliance for GKE clusters then I can give a location of a pipeline to run. And what this does is it creates a separation of duties, because I can have this YAML file, this compliance YAML file within a certain directory that every developer that has access to the particular project I give this label. We'll have access to so it can mean that only a select group of people can actually create the pipeline and enforce what needs to be run. By looking at a project that has that label, you can see that what's running is the actual get lab that compliance that is set within another project that has different access controls which is this compliance YAML. So this actual YAML file is running within the repository, even though it's in a separate location in a separate project of different access rules. So that creates the separation of duties. Second thing I want to show to show you how get lab enforces guardrails to prevent, you know, code from being merged by just anyone. So this is merge request approvals. So if we look at the merge request approvals. We have to built in for security. We have the license check that shows that if a denied licenses found, then we won't allow the merge request to be committed to master or to the default branch, unless stuff burger shown here approves. Any member or any group of members can be added. And this would usually be the security team or, you know, some type of legal team for the license check. And the vulnerability check requires approval from someone from a selected group or a selected user from approving a merge request if there's a high critical or unknown severity vulnerability found. Guardrails added to make sure that not just anyone can can merge the merger quest. If there's something detected that needs to be approved by someone from the security team or other team. So that that's something that that that creates security guard rails. So, and how do we create this license policy for the license check. Well, that's done within the license compliance. And you can see here that we can easily create, you know, we can easily add licenses which we want to allow or deny so in this example I am denying the Apache 2.0 license. But I am allowing the MIT license so what what typically what we do is, it would check all the dependencies and all the licenses within the dependencies and then match it against this policy set. So, and I'll show you how that works later on. So going back to our project. You can see that a pipeline was run, and you can see that it says verify here. So, what what these verified commits are, are we use a GPG key on our machine and the GPG key is added within GitLab. And every time I sign a commit and push it you can verify that I am the same committer and have the same email. So you can verify my identity through through the actual commit through when I personally commit. So it allows you to make sure that the people committing to this project are actually who they say they are and they're not committing any malicious code in there. So that's one thing that we've added. So the different security scans which enable our DevSecOps so you can see here that I include a bunch of different templates. And you can see SAS dependency scanning, license scanning, container scanning, DAS, so even coverage fuzzing and web API fuzzing. There are really different types of scans that we include within GitLab, and they can all be applied by just adding a template, and I'll show you what that looks like so. When I go here and I look at the pipeline, you can see all these different scans run so we build the container image. We push up to the container repository then we run SAS, and it auto detects a different languages in your project and we'll run SAS which scans the static source code. And then we have container scanning which uses cloud native solution called Trivi, and it'll scan the container images for known vulnerabilities if you have older versions and those older versions of container images for example Alpine have known vulnerabilities then it'll alert you on that and provide you with fixes within the MR which I'll show next. You can also see dependency scannings on there, which uses gymnasium so it'll scan all the dependencies. In this case it'll scan the requirements dot text file and it'll look at all the different versions being applied. And from there it'll find to let you know any of the known vulnerabilities there. And then we have a database fuzzing which does coverage on your actual function so it'll it'll fuzz your actual functions and send random data to the actual parameters in your functions to try to find, you know, vulnerability or errors within your code. And then run SAS and API fuzzing on the staging environment and you can also use GitLab review apps, which will just spin up a lightweight version of your application and then run SAS and fuzz testing on it. In this case I wanted to have an environment similar to production so I'm running these tests on the staging environment, but it's very configurable and it can be done in a variety of different ways. So going from there, let's see what happens when a developer actually pushes code to a feature branch and then and then creates a merge request. So here we see the merge request approvals actually blocking the MR from being merged because there's a denied license and because there are vulnerabilities that are high and critical. Now what happens here is we can see security scan detected a bunch of different vulnerabilities. And now we can see the vulnerabilities separated by their severity. We can see them separated by their type so there's SAS dependency scanning container scanning detected some new issues. You can see the different issues detected by Das. You can see different issues detected by secret scanning and you even see the coverage based fuzzing vulnerabilities or errors detected in the same exact area so it makes everything in one native interface it's easy to manage it's easy to go around. The results can be downloaded and use later. And you can see here a fuzzing injection added to this path so fuzzing will set up a it'll keep hitting the different API paths and keep trying to get an error so it'll send all this random data, and you can kind of enforce it to have a 500 error. And you can see yeah there's a bunch of data set like this, this craziness here, and it'll cause all kinds of issues within the application and then you can see the request set and keep replicating that to resolve the issue. And you have more information on what exactly was found and why the issue occurred. So just to show you some other ones. For example, there's a highly permissive mask. So someone gave really high permissions to a file in this case it was the database file. So you can see exactly where the line of code that affects a system is. You can see identifiers which gives you more information as why this is bad as why this this creates a vulnerability, and you also have information on how to resolve it. Now if each different scanner there's there's just different information and different ways it gives information for this information exposure and Django you can see that there's links to the actual CVE. And there's different solutions such as upgrading the versioning. And a couple things can be done if you know that this vulnerability is not a vulnerability because we've actually updated and is used for testing. For example, we can actually dismiss this. And this enables collaboration between developers and the security team, because if this gets merged with this dismissed, it'll add it to the vulnerability management dashboard as dismissed. So, moving on, you can also create an issue on this so that way just in case it couldn't be resolved right away. And this needs needs to be something that's removed we can create a confidential issue that only those with access can see. And we can create a confidential merge request as well to continue to work on it so that way the security team and developers can work on on resolution to the security bug without letting anyone from the public know, you know which can have some malicious intent. So, same same thing for the licenses we can see a, we can expand the license tab and see that the Apache 2.0 license that we set is out of compliance. So, and we can see all the other licenses that were detected. So, that would require someone to approve this. So, I'll go ahead and move on to the different tools that the security team has access to so there's the security dashboard, which lets us know the amount of vulnerabilities that were introduced over time so since this project was just created yesterday. You can see that after the scanner's run there was a whole bunch of info level and critical vulnerabilities that were detected. This also applies at the group level so if I were to go into my DevSecOps group and go to the security dashboard, I can see the vulnerabilities introduced over different amounts of time in all my projects and they're even given a grade a letter grade from A through F depending on how many vulnerabilities were detected within there. So, there's also this vulnerability report. So, this lets us actually dive deeper and actually sort through each vulnerability within the default branch and it lets us know sort by its status. So, let's just say detected. Let's just sort by the severity so we can see all our critical high vulnerabilities so let's us perform a triage and know what we should look through first and what we should handle first. So, different types of security scanners notice that it also includes coverage and API closing. And we can see if there's been any activity on the vulnerability if anyone's been communicating on it, and if there's been an issue created so just for to show an example. Let's say I would go into this vulnerability. But there's information about it. And I can go ahead and find out why it's happening I can see what the solution is and let's say this is something that was confirmed like someone from the security team went ahead and said okay this we did see this happening we do need to fix this. So I can go ahead and change the status to confirmed. And I can add a comment for fresh. You'll see it was confirmed just now by me so it keeps track of time of everything that's happened and I can add a comment. Confirmed will triage and move to spring. So we can collaborate here with other members of the security team and just kind of triage and see the status of all the different vulnerabilities. One way that that we can manage everything in collaborate. There's also audit logs and a dependency list so within the dependency list, we can see all the dependencies we have we can see which ones vulnerability was detected in this is applied to the default branch. And then we can see what file it's in and any licenses associated with it. And with that, there's also audit events, which gives us information on anything that's been added so it shows that I've been added, I've added a vulnerability check a license check I've added groups or have to move groups to it. If I were to go ahead and add another member. Let's say I add Cindy here, it would show that I added Cindy as a maintainer or whatever status I gave so it gives us a trail, and it lets us audit the system and see what type of admin functions for performed on the system. And that's what some of the stuff that get left offers in terms of dead psych ops, but there's also active security so threat monitoring and active threat monitoring. So what we can do is we can also create a network policy. So here you can see that I've added a network policy that. This is a firewall for Kubernetes cluster. And what this firewall does is it blocks the West East traffic from occurring so so pods will only be allowed to communicate to certain pods. In this case you can see that the incoming traffic or ingress is set and in order to communicate with a pod that has app equals test label, then a pod must have the access goes through label to be able to send traffic to that pod. So let's just create all these different firewall rules for all our Kubernetes pods and we can enforce that, and we can even create new policies or change current policies and it's this intuitive interface where you can just easily set up the egress and ingress for everything by just adding labels, or you can go into YAML mode if you know exactly how you want to do it and apply the YAML, and this will enforce these different network policies. So for container host security, we use Thalco to manage the container host and it will scan through to see if any malicious activities going on, and then we can create alerts, which will appear on the alert dashboard so same tab and threat monitoring alerts will appear any of the network policies were actually triggered. And then same thing for container host security you can anytime anything malicious done like writing to a particular directory writing, let's say writing to the edgy directory the slash tab directory. We see that as something malicious we can go ahead and alert to Slack or to different tools depending on the rules that we said and this is all customizable and done via different YAML files in different areas. So those are a few of the things I wanted to go over. Hope you enjoyed this little demo and with that I'll send it back to Cindy. Thank you for that was awesome I think we're ready for some questions and answers if, if there are any Megan. Yeah, there's a couple in the Q&A chat and I'll read those right now but just as a reminder everyone feel free to drop your question in the Q&A and if you would like to verbalize it, feel free to raise your hand and we can ensure you can ask your question as well. So the first one I have is, how can I ensure that developers don't disable security scans. Cindy or Fern. I think Fern showed that in the setting up the template and the separation of duties where Fern, feel free to chime in here. Yeah. Yeah, so, so in this case, the projects would have different so we would set up within the group we would set up different labels for compliance. These different compliance labels tell you which pipeline to run. So what you do is you keep all the different YAML files for the different pipelines to run in one directory that only allows the security team or admin users have access to it. And then what you do is you assign these different labels towards the different projects to enforce that those particular YAML files will generate a pipeline against those. So no one will be able to actually change the pipelines running besides the security team or any admin folks which have access. And the really cool thing too is you can run that against framework so that the framework will actually guide which policies are applied and you can customize those frameworks. So if you wanted to do SOC or PCI or something that maybe tweak it a little bit special for some additional things that you want to do, you can customize those. And like, for example, if you have different clusters as well, like you have something in GKE and might have a different compliance model than something in AWS, for example, so you can even set them based off of the infrastructure as well. The operating system, you know, you can fine tune it hard for your life to whatever it is that you want to apply it to. Awesome. The next question is how do most people get started given existing and other security vendors already in use? Well we'd like to meet people where they are. So if you've got a security scanner that you're very entrenched with, oftentimes those scan results can be included into our dashboard and the MR pipeline. So we can use those scan results but use GitLab to get that information into the hands of the developers earlier and into that consistent vulnerability management view. The other thing we can do is oftentimes we replace them. Sometimes people will start down the path of doing that integration and then find that, you know, what our scanners are just as good, maybe better in some cases, and the efficacy is there. And it's much simpler to maintain fewer tools and not have to worry about that integration. So either direction, we can meet you where you are. Okay, great. And as these questions are answered, everyone feel free to raise your hand or comment in the Q&A if there's something you wanted to be touched on further if you had another question. We have two more in the chat, it looks like. So the next one is, can I customize my compliance frameworks? Yeah, yeah, you'll be able to, your compliance frameworks are fully customizable. You can have different pipelines for each. You'll have a label and then pretty much it's like your compliance framework can be whatever it is. And then when you assign a YAML file to run for that compliance framework. So you can tune it however it is that you'd like, you can lessen to it but you can add little colors to it and you can, you can give it a specific name and then the main part is you link it to a YAML file. Which is basically your template. And then the final question I have is, where can I find out more about how GitLab secures the GitLab app itself? Yeah, if you go to aboutgitlab.com slash security, that's the page that is maintained by like our CISOs group. And so it has information in there around how we secure GitLab. There's links to attestation pages and more. So have a look at that if you're wondering about the security of GitLab itself as opposed to how we help you create more secure code. Perfect. And I'll try to grab those links and put them in the chat. We do have a couple more. Oh, Fern just answered it. I don't know if we want to touch on it, but are these features, are these security features only in the ultimate flavor of GitLab? Yes, the majority of them are. We, you'll find the static analysis in even the free version, free and premium have static analysis. But what it doesn't include is the nice user interface from a merge pipeline standpoint where the SAS results are actionable and show up for the developer within that UI that Fern showed. So that's really reserved for ultimate, but you can get SAS results in a JSON format. And because we want everybody to have some basic security scanning capabilities, all of the dashboard, the vulnerability management, the trend analysis, all of that is in ultimate. I hope for that. And we really appreciate your time today. Thank you so much. Thank you everyone. Thank you. Bye.