 Hello, my name is Boris Tsipot and I'm the Senior Security Engineer at Synopsys. Today I will tell you something about how to recognize and fix the risks that come in during your software development and how to recognize those during the testing phase. We will talk about problems in today's software development and how to reduce the operational security and license compliance risks that come into your software during your development lifecycle. So we will be talking about the software development or better to say secure software development and testing. First of all, we will start with the challenge. So what is today's software development and testing look like? And to go into this, we will start in where it was in the beginning. So in the past, software development was mostly done on proprietary source code. The complexity of the software was still low and this is mostly due to the point that there were not too much third parties involved. You did not have or had limited connection to internal networks or internet and you had few platforms to support. And to this, you still had pretty long development cycles, right? Well the world changed and today the modern software recipe looks actually like you put some proprietary code that you write yourself. But to avoid developing hot water, you use open source components to add the functionalities that are already there, you're just using them to express your functionalities better. You add API usage to the whole mix to get more connectivity, better configuration, software behavior to apply it to more platforms to make it more integratable. And all this mixed today, make sure that the software development actually is using today proprietary and third party source code, the software is becoming really complex and as we look now to our software development cycles, they get quite short, right? We are talking about two weeks or one week cycles. We have connection to the internet that is today almost mandatory. Nobody can think about an application almost that is not connected to the internet and we have many platforms to support. If we go only to the mobile site, we have already many contestants there, but now there are still PCs and server connections back ends. Then we have IoT devices with their free RTOs and such things. So many, many platforms that we can support. So if we look at the problem a little bit more closer. So we have the underlying systems on which we then build up our software, right? We add our proprietary code as we said, but how can we be sure that this proprietary code doesn't have our mistakes in it, right? That we did not program in some vulnerabilities that can then be exploited. When we start adding frameworks, we start adding open source components as said to extend our functionality or not develop hot water again if it's already there. Although then we have to see how we manage open source from the perspective of operational risks, license compliance risks and yes, open source is also software. So from that perspective, it has also possible vulnerabilities that come with it. Then we add the VAB UI application behavior. So how can we be sure that all those exploitable vulnerabilities that are now in our source code will not be deployed with the software, right? How can we find them? How can we disallow the abuse of those? And of course, how can we be sure that the APIs we intended for better integratability and better service don't get exploited for malicious use? And then we need to see how to now automate all of this because doing this by hand is not possible. So today's software development is about more code, more complexity, more speed and of course unfortunately more risk. Therefore we have to look also at the risk exposure through time, right? How does this all develop? So if we think about a vulnerability when it was introduced, it could be already quite a while, right? From the point when it was introduced to the point when it was found, there can be days, months or even years before this comes to a database of vulnerabilities where you could find it, right? Because this happened when this vulnerability is known, it will get released and this means that then also all the exploits start being published, key hackers start hacking away trying to see if they are good enough and of course also professional hackers start hacking away. Now think about this point. When do you find this vulnerability? How do you find it? Do you spend a lot of men hours just looking for this vulnerability? How do you know that you have this vulnerable component or this vulnerability in your source code? How do you find it? So the race is on, right? Between the time when the vulnerability has been found to the time when you fix the vulnerability, you are open for attacks and this is the highest security risk for you. So we have to do a lot of things, right? We are all aware of this and we have our whole software development life cycle to do this, right? So we have points where we define security requirements and risk analysis. We create secure configuration packaging for deployment, operational protection, malicious code detection even, right? The ongoing assessments with monitoring. But the important things are mostly code, build and test parts. And why are those mostly the problematic sites? Because we tend in the code to only code in the build, we only build and in the testing phase. We try to pick up everything that is wrong with our source code. And that's mostly the bottleneck. Here the most problems start because we are pushing the findings to the last stage and then it becomes a bottleneck. So we are trying to patch bullet holes, right? We see that there is a problem in the testing phase because we have to now repair all the found vulnerabilities and then we try to patch only some bullet holes so that water doesn't leak. And we then try to think about this legend of one tool to rule them all, right? We have this fantasy in our heads that we will put source code in and out will come the perfect software that we can give to our customers that we can use internally or even externally in our companies. Well the problem is that the reality is a little bit different. There is no tool to rule them all. There is no tool that can help you in every aspect of your work. So you have to do source code analysis to analyze the source code and find the vulnerabilities. As we said on your proprietary code, you have to do software composition analysis to find open source component and with its connected risks like licenses, vulnerabilities and operational risks and then it's best to do also a test on your running applications to see if there are any possible findings of misconfiguration, authentication issues or exposed security vulnerabilities that we did not find in the static code, right? So as we see already here, we divided the process into three toolings and now you will say okay this is too much, now we have to use three tools and we already don't have enough time. Well first of all we need to see what we want to achieve and for this we look closer at the code build test environment. We start already at the code phase and we scan the code and triage results throughout the whole development cycle. We remove false positive from the whole finding so that we don't get noise out of everything that we scan and then we can automate the SAS tool to give us the things that we need to be faster. To do this three steps already will improve our quality of the software and the software development process really big. Then we can merge subsequent scan results and customize the rule sets so that we can reuse everything the next time we go into the next version development. And if we do this, we are already there to uncover potential violation of coding standards, right? We can see if there are any things that we are violating that we are not doing right. And this already really fast so we hear a lot about shift, left, principle, right? However, I would like to mention here one other point that shifting left is good. However, you have to think also about shifting to everywhere because now if you go only left and this is your only verification or checkpoint for your source code, then again, you are not following the code through its development process. However, the static analysis that we now did is a set good for proprietary code. We would not like to look for open source vulnerabilities in your code with this tooling. Many will now say, why not? Open source is also source code, right? Open source also has vulnerabilities which can be found by static code analysis or SUST tooling. And I can say yes. But also, let me ask you this, what do all of those vulnerabilities have in common? So we know Heartbleed, Freak, Ghost, they were all found by researchers. The problem is that a researcher will go in and try to find vulnerabilities in a certain open source component in a certain software that is there. And for this, it will have to look for a lot of things, why? SUST tools are mostly affected for proprietary code, the code that you know, the code that you own, whereas open source vulnerabilities are usually complex. They are deeply seeded somewhere. They have many dependencies that are either direct or even trans-transitive. And with those comes even more complexity. So by doing this analysis, of course, it's possible, however, unneeded because you're spending too much time on this with using SUST tools. To make it better, think about open source components, realize that vulnerabilities are introduced to them, and then you're introducing those also to your software. And think about the three dimensions of the risks with open source and apply the right tool that will give you the legal risk assessment, security risk assessment, and quality risk assessment of each tool that you use in your software development. So at Synopsys, we have a research team that focuses on finding risks in known open source components. This is our mission. And we want to help our customers to identify open source components, identify the risk associated with those, and help them to mitigate those risks fast during the development cycle. As we see is that there are almost no code bases anymore that don't contain any open source. So open source is everywhere, be it a copy paste of a functionality up to using the whole open source component with a few hundred megabytes, right? And as we see, the average percentage of this code, the open source code base in the normal code base is up to 70% average, which means that some code bases go even up to 90 or more. So the proprietary part is really small. Also what we see is that license compliance with those components remains really critical. There are some markets there that already could take care of license compliance risks, but not everybody. We also see that many of the components used in software are there with vulnerabilities, which means that if you have one vulnerability in your source code that a hacker found, this hacker could then try to find other software that also have this vulnerability. And usually there is a high percentage of reshared open source components, which means also reshared vulnerabilities. So we see that the compliance part is not up to the task with the usage part, right? We see that there is more and more code bases consuming open source, but we see also that not all are going making sure that the security in those code bases is up to the task. So what do you need to do to get everything solved? Well, the first rule is you can't patch what you don't know is there. Therefore you need to identify open source components in your code. Then you need to think about how to reuse those components or where to take the components you want to use. Think about repositories that are coming from the community and not some forums or any other places. And then think about this. There is no vendor called open source. You can use open source, but in this case you are a part of the community and therefore you need to take care of following the open source. You need to take care of the point that you need to know when there is a patch available and you also need to apply those patches to be secure with the provided open source code. So we were now talking a lot about problems, but what is the solution? So first of all, don't limit yourself to one solution. As we said, we have different tools for different tasks. We have the static code analysis. We have the dynamic code analysis, interactive code analysis, software composition analysis and runtime analysis that are all at our disposal. But tools are not all. Think also about training the teams and individuals about secure development, about designing security in your software. And think about using services, managed or professional, to get your teams up to speed, to get your development up to speed and to get your testing up to speed with what you want to achieve. So if we now fill in the missing parts before, as said, moving just to the left will not solve your problems. Moving everywhere is something that can help you. So think about already starting testing while you're coding. You can do this with integration into your IDE, integration into your built environments and integration into your repositories. And then you have covered all places where your code can be and can deploy even more gates, security gates or quality gates as you go along. Take on the challenge. Start planning. Be aware of what's happening and gather the information of the used open source components and other tools and software that you're using. Identify out of those all the untrustworthy parts and replace them with something that you can trust. Define procedures that will help you to handle problems. One thing is to realize you have a vulnerability or a vulnerable component. Other thing is to deal with this problem. So define those procedures and then things will be easier to be solved. Call it as you want. So here I get mostly laughs, right? But really call it as you like. Sack devops, devops, devopsack. I know each one has its own meaning. However, don't be fooled. Please just think about that security is paramount to your devops culture. And therefore integrate the procedures of security into every step of your development process. And don't hang up on semantics. Just think about this, integrate those procedures and go on with this. And then in the end, you will benefit from open source usage. You will get strength, you will get speed, you will have competitiveness in your market. Because open source will power your innovation. The other thing is you need to know that everything starts with your developers. You need to give the developers the tools to inventory all the software that they are binding into software development. That they can define a patch strategy and they can understand what implications come to them, either legal or security. And engage with the communities. As said, if you're using open source, you are a part of an open source community. And therefore, don't just use the source code, but also contribute to it. Make it better, make it your goal that the open source that you're using is at the highest quality possible for you and for everybody else. So thank you. This was all from me and have a nice day.