 In the past, we've talked about the need for comprehensive application security scanning that empowers developers to find and fix vulnerabilities within their natural workflow. We've extolled the benefits of shifting left to remediate security flaws early in the lifecycle before the code ever leaves the developer's hands. And organizations have started down this journey. In fact, we get new customers every day who integrated their incumbent scanners with their DevOps tools only to find difficulty in scaling and managing the complexity to say nothing of the added costs when scanning is applied as broadly as it really should be. They turned to us to solve one of the CISO's biggest challenges, one that Jeff Pollard mentioned in his presentation, that of complexity. As the DevOps platform, GitLab's approach that embeds security into the STLC has brought proven value to even the most traditional app sec enthusiasts. In the next two sessions, we'll hear from two different GitLab customers about how they got everyone on board with security scanning through simplification and standardization with security embedded in their CI. So first up is Doug Rickert from Hear Technologies. They've quickly scaled their app sec program to hundreds of projects finding that the familiar user experience of CI CD and the simplicity led to rapid adoption. Doug also covers the softer side of DevOps, the people aspects of change. Now I want to point out to GitLab offers multiple ways to set up CI templates to apply scanners and policies. You can use auto DevOps or our new configurator that walks you through your choices or you can simply use YAML. Doug's found that the familiarity of YAML for developers was sort of the path of least resistance for them. So check out his story and be sure to ask questions. Hey, everyone. I hope you're all having a wonderful GitLab commit this year. And welcome to my talk. I'm going to take you through the talk I like to call teaching old CI CD new security tricks at Hear Technology. We are going to focus on how to get a successful adoption of new tools into development teams continuous integration and continuous delivery or CI CD processes. Specifically, we'll look at GitLab tools. But these concepts can be applied for convincing any software development team to change their ways. Many days throughout all my career, I felt like I am somewhat hopelessly trying to teach our chocolate lab re-doodle Leila to write good software. But honestly, I feel like we've made big strides even having to keep up with workplace trends like standing desks. And so who even is Hear Technology? Well, here's a company that's been around in different forms since the 1980s. We started off building maps involved into a full suite of location services offered on our Hear platform. Throughout the years, we've amassed a large following on developers and are handling a huge throughput of data from a massive sensor network. There's a good chance the navigation features of your car are powered by our location services. A package delivered to your door likely was coordinated through our services or more critical applications like first responders reviewing maps of US firefighters and trying to plan out how they will contain these fires. We recently just partnered with AWS on their launch of Amazon location services to bring location services to the AWS ecosystem. And quite a few other applications that I'm sure our sales team will work with me to highlight on my next presentation. As with any company, Hear accrued quite the variety in development systems across 35 years. Following industry trends and different source code management systems, developer tooling, technical stacks, various other tool set families has brought along migration and legacy support challenges. A new developer had 10 or more systems to learn before they can ensure product code they're working on was in the right code management system, passing the required unit or security tests, creating the right artifacts and working in an integration environment. How many of you had kept finding yet another team still using a system you thought was long dead? How many of you try to get that team to migrate? Only to be told the original team is gone and it's a house of cards that cannot be touched less they come toppling down. We'll keep fighting the good fight but this is unfortunately a reality at almost all companies. To challenge our ways of working and streamline our development work we've looked to GitLab to standardize this developer experience and our secure organization has quickly jumped on board with this idea as well. We're encouraging teams to ditch old security tooling and adopt GitLab security tooling as we are finding the common user experience and CICD language leads to a much better understanding and thus adoption of the security tools. And so just after one year of using GitLab security tools we've been able to get over 600 here GitLab projects using at least one GitLab security scanning tool. Our highest adoption has been static application security testing or SAST and dependency scanning and these were two tools that teams already had a strong awareness of from some of our older security tools. Secret Detection has been another great tool to add to our scanning arsenal as it's a tool that doesn't need any configuration for any technical stack and quickly drives awareness to bad security coding behavior. With its easy adoption I expect this time next year that it will actually be our number one most adopted tool and we're investing in that by customizing the rule sets trying to enhance the offering in a way that's unique to here development practices focusing on the systems that here developers use and the way that their passwords may be formatted in their code so that way we can enhance the checks and have an even better secrets management and secrets detection tool. And all of this we did without a very large product security team. I assume that you all are most at this presentation because you're using GitLab and are convinced you could be using it even better and imagine that everyone at this presentation could be using GitLab better as it has a vast amount of different tools and near infinite customization for those tools but it's not enough to make sure we use security tools on just our projects. We have to make sure the others see the potential for the suite of tools and meet or exceed us at our security standards. We have to be force multipliers in our companies to keep us ahead of our competitors and those probing our systems for security weaknesses. And even when it feels like your co-worker may have actually succeeded in training their dog to respond with Outlook's response prediction artificial intelligence, you cannot give up on them. You have to get all of your coworkers working in this secure mindset wanting their product to be more secure and understanding how to go about accomplishing that. And so, as you get your company to adopt these security standards focus on the sell and not the mandate. Developers are generally eager to have a secure product but with so many security mandates we often fail to help them understand what we are asking of them and why we are asking it of them. Security organizations and evangelists expect development teams to log into all of these unfamiliar systems and figure out exactly how to get the system to work for these teams processes and technical stacks. But remember, when a new developer has anywhere of 10 or more systems that they need to learn and log into just to be able to do basic feature work they can't afford to spend as much time as we would like them to learning the new system. We can't be diving in and figuring out how to perfectly customize the system to their technical stack to their code to get the maximum benefit of these security tools. And these are the challenges we are seeing with here developers and this is why we are seeing here developers embrace GitLab security tools. Our developers are already working in GitLab. GitLab security tools fit in with the industry CICD best practices they are developing. Tools are configured using the same YAML syntax that they write their other automation in. And best of all, they are used to the user experience already. Have any of you had to try and figure out how to set up security scanning to differentiate between release candidates and early feature development proof of concept code and found the security scanner just doesn't work for such a basic situation? I have quite a few times. And gone are those days as GitLab security tools will run in pipeline specific to whatever branching standard the team already adopted. We no longer have to work with the development team to figure out how to take the security tool that they are working with and make it fit perfectly to whatever release standard, whatever versioning standard they are following. And the results for all of these different variations can easily be viewed in the merge request without having to explain how to read this standard and find the correct results of the version being reviewed. One of the often overlooked features in CIC is the infinite amount of automation potential with webhooks. Send your report straight to your compliance team for awareness or brag to your CISO about another flawless release. Or automatically brew a pot of coffee because the critical security release of your least favorite third-party library just came out ruining your easy afternoon. And while selling this adoption you also want to be the path of least resistance for the development team. New projects you need to get in from the start as soon as the project is created preferably. The sooner you get in, the less complexity a developer will encounter while adopting the security tool. Then, as features are added and CSED pipelines get more complex, it is much easier for a developer to realize that it is their complexity to have broke the tool and not that they have been asked to adopt a broken tool. At here, we have a service that automates a lot of the steps teams must follow and the initial creation of a new application. That tool will actually create their GitLab space for them allowing them to choose templated projects for common technical stacks that already have these GitLab security integrations in them. And if you're dealing with legacy projects, think through an onboarding experience expecting an already complicated project. Don't expect that these teams can look at a 10-line GitLab CI YAML file and figure out immediately how they can put that into their hundreds or thousands of CI YAML. If the project is a high-impact system, don't be afraid to submit a merge request to the team yourself. Although, I really encourage you to use this bearing link. As we need developers to own their application security just as we expect them to now own their applications operations. DevSecOps. We've also been exploring and have plans to implement an automated merge request system that security can use alongside our GitLab deployments. This will let us do things like put security integrations directly in a project CI-CV code, adjust integration settings across all projects, and even suggest version updates all within a framework that the software development team can quickly test and approve. And as you push this adoption, make sure the processes you put in place enable a self-service experience. Just like software systems need to be able to scale to their users, so too must our security processes scale to our users. I am confident in saying that all of your security organizations or embedded security expertise is not scaling linearly with the size of your companies. And so neither can your security processes expect that linear growth. In big O notation, we need to be login with our processes and reach a cap in engineering support. If you find that your processes are not capping out, then better documentation needs to be written and better expectations set with the development teams. GitLab is a company that embraces open source after all. A developer can go as deep as they need to to understand the behavior of a security integration and there's a wealth of documentation available to them. Now, naturally, if your team is helping with these adoptions, your team will get better at debugging these tools, learning to read the integrations and helping teams with these problems. And it's okay to help them with these problems. It's okay to not expect them to go into the code that GitLab has available and figure out exactly what line of code is breaking in the integration. However, make sure that your engineering support again is capping out because when you provide that amount of hand holding, you might also be increasing the amount of support that developers expect. And make sure the development teams can learn from each other's questions. If you only ever answer questions in chat channels or virtual meetings, you don't give a developer with the same question a chance to get the answer on their own without asking you. Every time you get asked the same question a second time, a third time, that needs to be going into an FAQ or documentation needs to be clarified to answer that question. If you don't, you are just signing yourself up for more interruptions throughout your day because those questions will keep coming back to you or to your team. And once your adoption starts to pick up momentum, get the data into a proper data analysis engine. Use powerful query languages to look through the different finding fields and filter or group your data in any ways you can imagine. In this example, I showed a query we can use to find any critical severity findings that have to do with SQL. Then we can group these commit authors or even project groups and we'll have a list of users who are struggling with securing their applications that rely on SQL. We have commit author, commit date, file name, and with file name that means file extensions, discovery date. There's an infinite amount of views you can look into the GitLab data of your security organization. And with it all comes the same vulnerability as API. So much is already standardized for you. It really doesn't take much to start asking simple questions and coming up with incredible filters to answer these simple questions. So to start, the first thing I encourage you to do is use the data to reward the adoption of these tools by automatically clearing any security assurance or audit steps for teams you can. Developers feel audit pain, especially with so many audit frameworks that they may have to deal with requests from. And we have the power to ease the tedious audit steps with our automation skills. And don't just start with that reward the adoption by getting rid of audit pain but also highlight to leaders which teams are exceeding at adopting these security integrations and fixing their vulnerabilities. Leaders are always happy to see that their developers are taking security seriously because they know that a security incident is one of the most dangerous things that their products can face. Figure out who is doing the most GitLab security reviews and get them into quality security training. These people typically fall into two categories. Remember, I'm talking about who's doing the most GitLab security reviews on vulnerabilities. These two categories are the self-prescribed security expert on the team who may singlehandedly be keeping the product from an incident or the person decides they want to pick a fight with security by bulk dismissing all of their vulnerabilities. But you know what? Both of these people deserve good, engaging and fun security training. Gone are the days when annual security coding training security coding training has to be 30-minute videos. We at Hear Technologies have been in early talks about a sub-range called Range Force that can make a trainee not only learn security coding but experience having to fend against an attacker abusing the vulnerability. I really like this style. I think it helps developers realize that a seemingly small issue can cause a disastrous chain of events that we in the security community already understand and often take that knowledge for granted. They also offer training modules in different programming languages. And this is important because no one wants to listen to a Go developer start ranting about how the problem with the application is that the developer used Java in the first place. Or instead of focusing on specific developers focus on specific vulnerability families you find are prevalent in the organization. All of this is easily broken down in GitLab's vulnerability information. And you can even drill down to specific organizations if that's how you're using your GitLab grouping structure. We find that there is quite a few CRLF carriage return line feed attack vulnerabilities being reported in several projects. And even the security organization didn't really know much about these attacks. It wasn't the common attack that we had always been learning about things that were classes. It's not the ones that people were running all the most common blog articles about it's not the ones that you were seeing as the initial infection vector of the next big ransomware attack. But we not only learned them ourselves we put together a brown bag talk to teach the vulnerability to our development teams so that way they could gain that new knowledge and be able to solve these CRLF injection problems that we are seeing in our scanning results. And finally see if the data reflects a lack of understanding of what systems a team should be using to secure their application. GitLab probably has an integration the teams can be leveraging to systematically close that gap. So for instance if you're seeing a secrets management problem really consider if your company has a secrets management system to support their development. We found at our company that we could greatly improve this area as we started looking at concerns in our SAST and secret detection scanner results. We've been rolling out GitLab's fault integration over the past six months to provide a seamless password experience for our projects. As we were finding developers we're often complaining that they did their weird secrets management solutions because they didn't understand what we were asking of them when we were providing our initially generic secrets management guidance. Remember if you create the path of least resistance to be the secure one adoption will happen on its own. Focus on the cell and not the mandate because when you're focusing on the mandate teams don't understand they might do their own weird secrets management solution they might do their own weird solution in another way and miss the mark on what security value you're trying to bring to their product. So thank you all for joining my talk and I hope that at least a few of these techniques resonate with you. Please feel free to reach out via the conference or on LinkedIn and we can talk about even more details or you can just swap stories about our favorite security bulk dismissers we have the pleasure of dealing with. Even if you're not using GitLab or you're trying to push the adoption of another application security tool or another tool that just generally tries to improve the quality of software developers products I hope that there's some techniques in here that will make sense to you and help you along the way because most of the challenges that we are facing when we try to adopt new tools when we try to get software developers to see the value in the systems we are encouraging to use it's not a technical problem it's not that we need yet more lines of code it's not that we need yet more RAM, more disk space, more computing power all of these things software developers are perfectly capable of figuring out on themselves and they're working with every day but adoption comes down to understanding and the realization that developers can't be looking at 10 different tools and learning all these different user experiences try to streamline that experience and meet developers where they are developing so thank you all and please enjoy the rest of the conference