 Good morning. Welcome to today's topic of fueling open source adoption with DevSecOps. My name is Neetu Chen. I'm a lead product manager at USAA. Before we dive into the topic, I wanted to share a little bit about myself. At USAA, I'm building a platform that will transform the way software development is done at USAA and it will basically set us up for 100 years. So as you can imagine, my platform is heavily into DevSecOps principles and open source is a big component of it. So it's a big part of my day job. Before I landed at USAA, I spent almost a decade of my career in engineering. I moved to product management from engineering and I worked at various companies like SD Micro and Intera and HP, but I was doing hardcore CC++ programming most of that time. And as a result, open source was not very... I would not cross paths with open source very often at that time. It's interesting how open source to me was introduced through my volunteering experience. I was volunteering for an organization in India, which was using an mHealth open source project to bring healthcare to remote tribal regions. And that's how I got introduced to open source. And I was just blown away with the potential of open source. And since then, I've been very curious at the intersection of open source and humanitarian causes. I went ahead and organized actually open source day codathon for humanity at the very famous Grace Harper celebration. But this was right now only through my volunteering. When I moved to IBM from HP, that's when actually open source became part of my professional life. Because now open source was everywhere and I even contributed to OpenStack and got free tickets to OpenStack conference. But as you know, the cloud isn't separable from open source. And that's how open source became part of my professional journey. At IBM, I was doing cloud network security product portfolio management. And at USAA, now I'm creating a DevOps platform for transformation. And it's interesting how earlier I was in the cloud provider side. And now I'm more of on the cloud consumer side. But at both ends, open source has dominated, open source has dominated technology. So now that I've talked enough about myself, let's dive into the outcomes of today's presentation. So the two things that I want to highlight in this presentation is like, first of all, how open source can be a double-edged sword. You know, it has a lot of benefits and we are at the open source conference. So we know, you know, the potential and the benefits of the open source, of open source. But at the same time, there's some caveats and there are things they need to worry about. So I want to highlight about that. And at the same time, in the second part of the presentation, I would be talking about how, in spite of being a double-edged sword, you know, it is still very powerful and it has a lot of potential. So if used correctly and carefully, you know, we can unleash the power of open source. And that's the second part of the presentation that I want to drive across. So let's dive in ahead. And I'll start by a little bit of background on how the world has changed in the last one decade. So as you see, I started my career in early 2000s. And as I was telling, I was, you know, doing embedded programming. And even Gartner says that in 2007, you know, most of the code was built in-house and that's the world I came from. Very little of third-party or open source software was being used at that point. While if you move a decade later in 2017, most of the code is produced, you know, is third-party software while there's very little code produced in-house. So it sort of has parallel to our kitchens. I feel that at some point, we used to do a lot of cooking from scratch. And now there's a lot of assembly meals in our kitchens, you know, assembled from pre-cooked maybe canned beans and frozen food and all that. So, you know, so it was an interesting to see that parallel, maybe not around the same lines, but how it is, open source has become so rampant like packaged food in our lives. When it started, there were a lot of doubts about, will it be sustainable? Can people make money out of it? Is it reliable? What about the quality, et cetera, et cetera. But in last one decade, we have seen that open source has received the recognition and gotten its well-deserved seat at the table. We have already seen how Red Hat and GitLab are able to make successful businesses out of open source services and how big giant companies like IBM and Microsoft have recognized the power of open source and have made some very important buyouts. Since 2016, Git has been the most popular version control system in spite of so many proprietary software being out there and so many older and mature products being out there. So, that just proves the power of open source, how it has disrupted the industry and how it has garnered its recognition. But with recognition come, you know, and with recognition has followed a lot of growth. What I want to help you guys see here is how much growth it, like it is rising fast, that is true, but it is rising much more faster in the last few years. So, if you see the Austria report, open source, the Austria report 2020 done by Synopsys says that 99% of the code they audited into 2019 contained open source components and they almost audited like 1200 applications, more than 1200 applications. And as you see, they say like out of all that, you know, so basically 99% of the code has open source. And even in that, you know, 70% of the code base is made by open source. So, you can see how rampant is the usage of open source and how it has grown. And if you see, so, SNIKE is another tool, you know, sort of for the same reasons that we're presenting in the SNIKE says, SNIKE does periodic report two and SNIKE report says that the number of Maven central packages they indexed in 2018 grew up by like 100%. You know, according to SNIKE, they were, they were 300 billion downloads in 2018. So, so open source is growing at a lot more faster speed, it is accelerated, the growth has accelerated a lot more in past two, three years than, than our previous years. So, that is great. Now the question is, you know, it's now the important thing is that it's not growing without thorns. There are some concerns. The picture is not very rosy at all times they are, as open source is growing, so are the vulnerabilities growing. So, is the concern around security growing with open source. If you see these charts and these are pulled up from the same OSRA and SNIKE reports, they say that 75% of the code has been found vulnerable and 50, so out of the out of the code they audited 75% of that code is, you know, has vulnerable components and at least 49% of them have high risk vulnerabilities. So, you know, think about Equifax and, you know, that's, that's the model example, I guess, of, you know, the impact of not fixing open source vulnerabilities of what it can do to your business and your brand. And, and within that, you know, this open source word, there are some ecosystems where, which are more prone, I guess, or, or, or vulnerable, where vulnerabilities are growing much faster than others. So, as you see in this graph by SNIKE, Maven, the Maven and NPM ecosystem has a lot more growth in application vulnerabilities over the last two years. SNIKE report says that, you know, in 2018 the new disclosures of NPM grew by 47% and by, for Maven Center, they grew by 30%. So, as growth is improving, you know, as growth is happening at the same time, vulnerabilities are growing too. And, you know, that's like hackers heaven, you know, they have more vulnerabilities to exploit. I, so, so the story does not end here. The security of open source becomes a lot more difficult to solve because of another factor called dependencies. So, let me start by sharing for those who are not aware, what are dependencies. So, there are two types of dependencies. One is direct dependencies that refer to basically libraries that are referenced type directly by your application, like the ones that you are calling intentionally. Then there are other dependencies, they are called indirect dependencies or transitive dependencies at some times. And these are the libraries that your dependencies are calling. So, basically a dependency of a dependency. So, you did not call these dependencies intentionally, but it's because of a dependency that you called and it depended on something else. That's how it came into your application. So, that's a big blind spot in, in open source world, I feel, or in general, you know, software, the indirect dependencies are, you know, the source of 78% of the vulnerabilities, as Mike says, and DPI report, data breach investigation report says that 70% of the attackers exploit already known vulnerabilities. So, what it means is that the hackers are, it's not like a new vulnerability was discovered and they start, you know, using exploiting those vulnerabilities. Oftentimes, they are, these are already publicly declared vulnerabilities. Sometimes they're even patches out there. And the hackers know that everybody has not updated this software and not, you know, patch their software so they can still exploit their, they can still exploit customer applications. So, this is what I want to say that, you know, stale dependencies can lead to a lot of security risks and legal risk and performance risk. So, it's very important to update your dependencies. And, you know, just to walk you through about the whole situation with Equifax, there was a critical remote execution vulnerability in the popular patches struts, web application framework, which is what Equifax was using. Now, the interesting thing is that struts developers did not bring in that vulnerability. They were not the ones, you know, who are responsible for it. But what happened is, it came through another dependency Jackson data bind that, and the vulnerability existed in that dependency. And now the attackers could run malicious code on affected servers. And that is what lead to Equifax data breach. Now, even after one year later, one report found that the struts vulnerability, which resulted the Equifax debacle was still present in one third of the audited code. So, even though they were you know, patches available, and even though people had seen how severe the result of that exploitation of that vulnerability could be, people were not updating it and, you know, fixing their applications. So, this is the crux of the problem that, you know, that we should be concerned about. And that's why, you know, I say that open source is a double edged sword. It has a lot of power to accelerate your development and, you know, accelerate your applications development. But at the same time, you have to be really aware about the security risks. So, now that I have talked about how open source can be double edged sword, we do recognize that the benefits still outweigh the risks. And that is why we continue to see the growth of open source. Now, the important thing is to be prudent and manage the risks carefully and proactively. So, because we believe that if you use it carefully and correctly, there is a lot of potential to be achieved from open source, because of how powerful it is. So, let's talk about the guidelines, you know, so how exactly with DevSecOps, you know, by mitigating the risks properly, can we make sure that we are, you know, carefully using open source. So, IDC guidelines says that by 2023, you know, use of open source to build enterprise applications would double for 40%. So, irrespective of the risks, people, you know, recognize the benefits and they will go ahead and use open source. But these are the guidelines to make sure that you're using it responsibly. One of the guidelines, I guess the topmost guideline, which most people say is like first set up an open source program office, which can, you know, understand the gravity of open source and the need to manage the risks clearly. So, you know, to do, there's a to-do group talk openly and develop openly group. And there's Google who have put out a lot of material on how you can set up an open source program office where it should be the focus of this office, you know, how they can help drive open source governance in your company. And, you know, this basically overall program office can make sure that open source at all levels in your company is being used responsibly. Now, so the second things that, you know, that they recommend is that make sure you inventory your software. Now, this will fall into the open source program office if you have it, but if not, you know, these are the things that they'll basically recommend and look into that, you know, inventory your software so that you're aware about, you know, what software you're using. If you go, if you looked at the dependency slide when I showed the NPM dependency graph, you can see how complicated it can get. So, it is extremely important to inventory the software to know what direct dependencies, indirect dependencies you have in your applications that you are consuming so that if vulnerability is found in one package, you can map what all applications are affected by it. Then it's important to manage the security risks and legal risks and quality risks. And these are not easy to map, you know, and the updates, etc. So, you will need a lot of automation to be done to be able to manage these effectively. You saw the numbers of NPM packages and the vulnerabilities and each vulnerability can be, you know, high, medium, low, severity. So, there are a lot of moving components to be put together, which is not easy, you know, to be done without automation. The other thing they say is, you know, just be part, be a good citizen, be part of the open source, keep, you know, get plugged in, contribute back and, you know, if their vulnerabilities help them fix so that we all can make a better contribution. If you do really feel that if you use the right tools and make sure that they are integrated early enough to nip the problem in the bud, you can, you know, the open source power use it. So, this is where the DevOps comes in, you know, in integration of the tools and early enough. So, let's talk a little bit about that. So, what you see here is a DevOps tool chain and I'll talk to you a little bit about it. But first, let's talk about software development. So, every software, this is how it starts, you know, it starts with empathizing with the customer or, you know, realizing a problem, defining a problem, providing a hypothesis that if we do X, you know, this problem, you know, could be alleviated. Now, that idea gets into the software development cycle of build, learn and measure as a product manager. I'm a fan of the cycle, you know, because we never have the right answers. All we can do is get into this cycle of build, measure and learn, create hypotheses and see if things are working or not and go from there. Now, how can we accelerate innovation? We can accelerate this innovation by making these cycles smaller and smaller so that we can learn faster and faster. And how would that be possible? Now, that would be possible by a DevOps tool chain. So, what exactly is a DevOps tool chain? DevOps tool chain is basically a set of tools that work together in a smooth, conducive fashion so that you can go from your plan, create, verify, release to production and operate and monitor your changes into the infinite flow. The main purpose of the DevOps tool chain is for you for it to enable quick production, you know, idea to production, you're able to go fast. But at the same time, it also wants to make sure that you're going to production with healthy software, good quality, secure software, compliant software. You do not want to compromise at the health of the software. So, this is where DevSecOps comes into the picture and can really help getting us there. You know, there are so many things that we need to take care regarding open source. For example, the license risk management. If, let's say, indirect dependency has a license and the direct dependency has another license and the application has another license and they're not compatible with each other. Somebody needs to manage all the dependencies and make sure that the licenses are compatible and it's okay for its intended use. You know, similarity for vulnerability and identification management, you know, you need something. There are so many vulnerabilities being found. You need something to be proactively looking at it. And there are many other aspects of, you know, policy management. And, you know, what you want to do is you want to make sure that all these are integrated in your SDLC life cycle. Then, you know, you would also be providing like audit reporting and risk reporting to make sure especially like I'm, you know, if you're in financial sector, you have to make sure that you're able to meet the compliance and audit requirements and, you know, risk management reporting. And these should be easy to pull off. You shouldn't have to waste a lot of time or manual effort into this. So these are some of these things, some of the challenges that can be addressed through automation, basically. Through automation by, you know, bringing the visibility right at the source, right where things are happening at the right place in the DevOps cycle. So let's talk about that on how, let's talk about some of the specifics on how to actually, you know, use DevOps with the tools in the actual DevOps cycle, what tools and how we can make sure that, you know, open source is correctly maintained, you know, we're handling the double-edged sword of open source correctly and efficiently to unleash its power. So let's talk about the cycle. And we started the plan stage where, you know, you see there are many development workstation tools, for example. And I'll just give you examples that might help you, you know, understand better. For example, there could be a Chrome plugin so that when a developer is browsing through the Maven repos and NPM repos, as we showed, you know, a lot of the vulnerabilities are there or any of the, you know, open source repos, the Chrome plugin tells you if there is a known vulnerability found in this package or not, you know, if it can go back and if it's hooked up to a scanning tool, you know, it can find out if maybe your company already does not allow you to get that software because we know that there's a known vulnerability or maybe a license complication for whatever reason, your company doesn't want you to use it. It's better to start at the source and let the developers know that this is not the best software, you know, to use. Maybe, you know, a newer version is a better choice. So that is one example how you can shift the security aspect, you know, to the developer right now when he's even starting to think about using that software. This is where open source program office can help, you know, create policies and manage open source tools to help you with this process. So for example, if you do want to bring something in, they can help you see if it's already in the company, if you've already got it, if it is approved, if it's not, if it's secured to bring it in, you know, and if it's not, you know, if you're not clear, if it should be approved or not, it can go through evaluation process, who are the right people, maybe you need legal stakeholders and maybe you need security stakeholders to weigh in on that software to understand if it's okay to use. So you can automate a lot of those aspects of open source. Then, you know, in the build and create, there are many tools that you can use, source code management tools, you can do source code scanning, artifact management tools. Actually, you know, JFrog has Artifactory and X-Ray, which can plug in together. And in your CI CD pipeline, you know, they, using Artifactory and X-Ray, you can see, oh, is there a vulnerable software out there? If so, then, you know, do not allow it to be, to get downloaded. You can set a proxy repose through Artifactory, so that, you know, there's already a pre-wetted clean repository for your developers to use. They don't even have to go on the internet and, you know, waste their time to finding out which software is vulnerable and which is not, because now you have a proxy repo where you've already done the pre-wetting and scanning, your tools have done it, you know. At the same time, you know, in build automation tools, like, there are tools that can stop your vulnerable code from going to production, for example. Let's say you were using struts, which is still not patched, your build automation tools can see that, that there's a known vulnerability in struts, which, and your application is using that version of struts, so it will stop you from going to production. Dependency management tools can help you see how your dependencies are out of date, how, if there's a new vulnerability find out, found on a dependency that used to not exist earlier, now they can tell you that, you know, this is the dependency and these are all the applications that are impacted, so this vulnerability needs to be patched, you know. So, dependency management tools can help you track your dependencies and maybe even update your dependencies, put a program to periodically update your dependencies based on the new information fact found. Testing tools, of course, you can see in Verify Stage, there are a bunch of testing tools that you can put in place to make sure that the applications you're developing are secure, are secure, you know, and in general, the quality is better. You could do, you know, SAS application, SAS tools, you can, you can do DAS tools, they can be, you know, as you go and release production, and then they are container images that are vulnerable that you need to make sure are, you know, you are secure, so you could put tools like Twistlock for do container scanning, you can do, you can use x-ray to do dependency scanning, you know, and through the use of these kind of software, you can find out the vulnerabilities early enough before they go to production. Now, the other important part of vulnerability is finding is not enough, remediation is important as well. So, you need to make sure that, you know, vulnerability management tools are monitoring the new vulnerabilities, blocking, providing a red flag from production, at the same time also tracking remediation, because ultimately you want to improve the quality of software at your company. So, these are some of the examples of how I feel that we can, you know, use DevSecOps in shifting left security, basically bring the concerns of security and bring the information and visibility of vulnerabilities, etc., early enough in the cycle so that it's not an afterthought, you know, it's not a later patch game that we are playing. And, you know, we can really make use of open source without the hesitation of, you know, security and license issues and other things that we can run into. With that, I would like to see if there are any questions. Let me see if, yeah. So, I hope I was able to put across how DevSecOps can be really useful in securing your open source code. There are many other things that you can do, you know. I was talking right now mostly from the consumers point of, you know, open source, like consuming open source. There are other things that you need to worry about when you're contributing to open source. You also want to make sure that you yourself do not want, do not put any vulnerable code out there in open source when you're contributing to open source. If you do have an open source project that you or your company, you know, are putting out there, then you also need to make sure that you have a vulnerability declaration program so that if you find it vulnerability, you declare it so that other people who are using it can see where, you know, what vulnerabilities they need to worry about by just using your software. So, as I mentioned, you know, there are a lot of aspects of consuming open source responsibly and contributing to open source responsibly and the whole open source ecosystem. I am pretty sure that we will make a lot of progress in that, in that ends when we all work together. But I hope this presentation creates some awareness about what could be the issues and how we could solve them. Thank you for listening. I am ready for questions now if you guys have any questions. Hello everybody. Thanks a lot for joining today's session. If you guys have any questions now, I'll be happy to take them. Thanks a lot, Akshah, for the feedback that you enjoyed the presentation. I do not see any other question in the Q&A section. If you guys come up with any other questions, feel free to slack me and I'd be happy to answer those questions there as well.