 Hi, I'm Awupakara, and in this session, I will be sharing with you how you can secure your continuous everything strategy. The software development life cycle is rapidly evolving, with new stages added quite often. But security is just catching up. First introductions. My name is Awupakara Siddiq Angu, and I am a developer evangelism program manager at GitLab and also a CNCF ambassador. I'm an engineer based in the Netherlands. If you are learning Dutch, please let's me study about this. At least I will be able to say more than hold more hands. Software development has evolved due to the increasing requirements and complexity. That has been thrown at software development these days. Those need to increase productivity and get into market faster has led to the line between development and operations blurring into the background. DevOps allows companies to build applications, test, deploy or release and monitor them with the metrics or data from production environments informing decisions for bug fixes and future proposals. All these happen within the same cycle. Thus, the work never stops. But we learn from the mistakes we've made and fix them immediately. But one stage is often missing, forgotten or neglected till the end. That's security. And that's where DevSecOps comes in. Now, with DevSecOps, security is shifting to the left and made a priority at every stage. This allows bugs, vulnerabilities and other issues to be discovered much earlier. Not just security, governance is also shifting to the left because decision makers need to be part of the process at every stage. Adding to the context and informing wherever the development is moving off the product pipeline instead of showing up just at the end of the life cycle. But with recent happenings in the world there has been a surge in the need for a lot of services to happen online, thus putting a strain on existing DevOps strategies. Everything needs to move fast. That's where Concurrent DevOps comes in. Now, take for example the comparison between regular Microsoft Word that we use offline and Google Docs. With Word, only one person can edit a document at a time and it needs to be handed off via email or sent through some messaging app to other people to work on most often concurrently. This often leads to conflict. But with Docs, lots of people can be editing the same document at the same time with Russian history and real-time feedback. This is what Concurrent DevOps achieves. Multiple people involved in software development at every stage can be working concurrently without getting blocked by others. Except of course, when there is a dependency that needs to be resolved. This way, more speed is achieved in going to market. Coupled with automation because everything has to be automated if we want to move fast and we have lots of people working at the same time. Now, the demand for software development lifecycle now requires automation. Something is wrong with my slide. Let me move to the next slide. Awesome. Something is wrong with my slide. Let me continue. Now, the demand of the software development lifecycle now requires automation. After developers have built parts of the system concurrently, those parts need to be integrated, tested, deployed, and monitored. The old style will involve manually getting all these steps done. But making all the processes continuous means everything is automated using CI CD2s. There are lots of them out there, including open source ones like Tecton and Jenkins X. With GitLab also making a very awesome solution. Now, developers only need to focus on what they do best, which is creating good software. Continuous doesn't necessarily mean just continuous integration or continuous deployment or delivery. It means the entire lifecycle, aside from the development, needs to become continuous, which leads to efficiency, speed, and increased productivity. Now, but with speed consecutive challenges with several team members pushing codes at the same time and introducing changes to the system, it's increasingly easier to introduce vulnerabilities. Among the top vulnerabilities listed in the 2021 top 25 most dangerous software weaknesses from the CWE list that most secretive use for analysis, privileged escalation ranks high among all of them. And these vulnerabilities often does not come from the code the developer has written, but from the dependency or base container image of the operating system which they are using. We use a lot of tooling and a lot of dependencies. So if any of them has bugs, the whole code needs to have a bug. Now, listed here, common security challenges that we are visually battled with, especially nowadays, we have things like continuous vulnerabilities. And because we are an industry that stands on the shoulders of giants, we use dependencies very heavily and not vetting them before you use them in your software can be detrimental. Even when you are working with safe dependencies, you cannot be sure that it won't be yanked off the interface of the earth abruptly with such situations like that. Another issue is license compliance. The dependency you love so much might not fit your license requirement, which often leads to legal issues if left unchecked. There are several discussions that we've seen online lately about changes in licenses, which often doesn't go well. Bugs, privileged escalation, license compliance and secret exposure are major challenges. Honing in on a few of those challenges, I will start with privileged escalation. This is the most exploited vulnerability as it usually happens due to a vulnerability in a software or the tooling being used or the underlying operating system images running your software. Most times, staying up to date is a remedy, but the rate at which bugs of vulnerabilities are discovered these days is way more faster than the update strategy in place in some organizations. Most organizations stay versions behind, which can be an issue, especially with bugs out there. Supply chain vulnerabilities are also a major source of privileged escalation. We've seen a lot in the news. We are only as secure as the tooling we use. Now, with same privileged escalation, next to container vulnerabilities is a major concern as container technology has gone mainstream, powering most of the infrastructure running today. But bad design is a major concern. Building images of bad-based images or exposing the wrong ports or mistakes that can introduce problems into our system does exposing our production surfaces. Now, secret exposure is another major concern lately. A recent research presented at the network or network and distributed system security symposium showed that despite how it's a well-known fact to not include secrets in repos or expose them in CI, thousands of projects on GitHub that will analyze half-secrets exposed in different forms, different types of secrets, mostly API keys or secret keys of AWS and so on. Some of these projects also assume you can simply rewrite history to fix an explosion mistake. With the right tools, bad actors can dig secrets in Git history. To learn more about the findings and see how secret is a major concern, please visit the link referenced on this slide to learn more. Now, there are lots of security checks that can be done at various stages of the development life cycle. We have sars, we have dust, we have fuzzi tests, especially secret detection and so on. And most of them can be automated. In particular, security tools now have the ability to automatically even remediate discovered vulnerabilities like rotating, expose AWS keys or creating a commit to correct or suggest container images, also just changes to container images and other fixes. But chief among the security features is vulnerability management, like a dashboard. You and your security team need to have a dashboard to see the vulnerabilities discovered, which were automatically fixed, which of them are automatically fixed and which of them were fixed by the developers and those that required attention of the security team. This way, it can help inform changes that need to be made to the system and reinforcements that need to be put in place in order to avoid such vulnerabilities. On this slide here, you can see the traditional approach to security. It's often an afterthought. The whole development life cycle goes on before an assessment is done and it gets created for the development team to fix. But with DevSecOps, but when your DevSecOps strategy becomes concurrent, everyone is part of the process and everyone is involved in making sure that as soon as security vulnerabilities are discovered, they are fixed with a dashboard presented to your security team in order to be able to see what has been happening, what are the vulnerabilities that have been discovered and how they were fixed and gives them an overview of what are the main challenges happening on the system and ways to fix it. Now, shifting left is not just enough, but it requires a changing culture plus comprehensive, continual security testing. Like I said earlier, continuous is not just for integration and deployment or delivery. It involves all part of the development life cycle, including continual security testing. That means at every stage, security checks that you need to do needs to be continuous and for every commit that is done, for every push that is done, sorry, commit that is done, they need to be checked, they need to be tested. Images needs to be checked before they are built and those images needs to be checked. Your manifest files need to be checked before they are deployed to your cluster or your Terraform plans need to be checked and verified before they are deployed. Now, once you achieve margin security, shifting security as a culture within your dev cycle life cycle, shifting left becomes naturally easy. Thank you very much for joining me and for you to learn more about GitLab and some of the ways you can use GitLab to visit about.gitlab.com. Thank you.