 Next up, we have Deepak Sharma and Yusuf Zaini talking about developing secure and compliant application via IDE. I'll be going ahead and playing the recorded video. So I've included the link of the talk in the chat. You guys can go ahead and watch it there as well, but I'm going to share the screen here. All right, so I'm going to go ahead and play the video. If you have questions, keep asking them in the chat box. Hope you're doing great. Today, we will take you to the journey of how you can develop secure and compliant applications via IDE. I'm Deepak Sharma, software engineer at Red Hat. Hello everybody. My name is Yusuf Zaini and I'm principal software engineer with Red Hat. And today we'll be taking you in a mission and our mission is to give a sense of security to the application developers. So we will be discussing mainly on four points. And each of the four points are the ones which a user usually faces a problem during his development lifecycle. And we will be telling you as to what exactly or how these can be rectified or can be covered. So before getting into the details of those problems, let's try to understand what is a dependency or a package or a library or a module. In different ecosystems, we use the different terminologies to talk about the same thing actually. And what it actually is like when an application developer wants to reuse certain component or certain features which are already developed and which are available in the market as a package or a library or a module, then that application developer adds that module or a package into his project and then he can reuse those functionalities which are already there. So that actually is what is a dependency or a package or a library or a module in different ecosystems. Next slide. So now let's get into the problems which I was talking about. So let's talk about the first problem. So this problem we call it problems of a plenty. So in the graph on the right hand side, you can see different ecosystems denoted across different timelines. And if you just see the NPM graph, there you see that it is rising exponentially in the last two or three years. What it means is that the number of packages available in the market for these ecosystems are humongous. So how does a developer know which package to choose from the ones which are available in the market? This is one of the problems. Next slide. The second problem is problem of security. Again, we are representing it via graph. And if you ignore what is in the left hand side and rather concentrate on what is on the right hand side, you see there will be a lot of tall buildings over there. And those tall buildings are actually denoting the number of vulnerabilities that were reported in that particular year. So if you see the last two, three years, you will see that there are more than 45,000 vulnerabilities that has been reported. So as a developer, when you have selected a particular package to be used in your development environment or in your project, how do you know whether that package is vulnerable or whether it is not vulnerable? This is the second problem. Next slide. The third problem is a problem of compliance. Now, suppose that the user have selected the best available package. He has selected a version which is not vulnerable at all. Now, as I said that in an application, you will be having lot of such packages which you will be using. How does those package comply with each other? Because each of them will have its own licensing compliances. And then we have different versions of license like whether it is permissive, weekly protective, strongly protective, network protective, and then there are different licenses under it. So whether those packages that you have added in your system are compliant with each other or there is any conflicts. Also, like if you have so many packages added in your project, what is the overall license of your project? So this is a third problem which we want to discuss about. Next slide. Now, the fourth problem which you would like to say is the problem of maintenance. So again, discussing on the packages and dependencies, how does a particular developer get to know that the package that he has used, package or dependency, how popular it is? Like how many other developers are using that particular package? Whether there is constant updates coming to that particular package or dependency? Whether the issues which are being reported are actively looked upon? Whether they are resolved? How many people like this? How many people don't like that? How does a developer know about all these things? This is the fourth problem. So now let's just summarize all those four problems in a nutshell. The first one is how do developers choose the right dependency? How do developers build an application without introducing any security vulnerability? How do developers identify dependencies with the right licensing terms to be used and bundled as part of the application? And the fourth, how do developers select the right upstream dependency which is well maintained? So what is the answer to these four questions? We have an answer and that is in the dependency analytics. This is one short solution for all these four problems. How does it work? Let's get into the next slide. So it has three different, like if you want to talk about architecture, there are three different aspects to it. The one part is the offline part, which is the data gathering and normalization of data. The second part is using that data for artificial intelligence, ML training, retraining. And the third is the presentation and integration. Like this is the third part is where the users come into picture. The other two parts is something that we need to keep on doing in order to make sure that whatever we represent or we show to the user is correct and accurate. Next slide. So let's get into a little bit of details about the data gathering and normalization part. So there are two types of data that we majorly gather. One is the vulnerability information and the second is the package or version information. So the vulnerability information, there are two places from where we get this information. One is like we curate our own vulnerabilities. The second is we have a partnership with SNCC right now from where we get this vulnerability information. We process those vulnerabilities and then we update our graph database with all the vulnerability information. The second thing that we have is an active upstream monitoring where this upstream monitoring. We make sure that all the latest versions and all the packages which are released for the ecosystem like Maven, NPM and Python. We have it in our system. We keep our system updated with all the packages and versions available. So how we do it? We have an upstream monitor which keeps on getting these updates feeds and then we have a worker processing. And that worker processing actually uses the AWS Qs internally and it has its own flows and tasks. It does all those processing. And then finally it's, it rests in the graph database. So the package details, the version details and the vulnerability details, everything gets combined into one centralized space. That is our graph database. Next slide. Now coming to the EINML part. So now as I explained earlier that we have all the information present in our graph database. So what do we do with that information? One is like obviously giving the notifications to the user about the data or the things that we have about the vulnerability information on all those things. The second part is give something extra to the user. And that is where this EINML training or retraining comes into picture. So we process whatever information we have and we have our own EINML training. We have our own, we have come up with different models. We tried retraining and then we decided on a particular model which suits best into our criteria and we use that to give the suggestions to the user whenever we like, whenever we have a particular stack, we give the suggestions about the different dependencies using our EINML. And we also take the feedbacks from the user which we use it for retraining. And we also keep an active track on what the users are using and use all this information again to retrain our models and give the best possible analytical analysis to the user. We'll get into the details of this when we see the live demo. Yeah, next slide. And the third and final part is the presentation and integration. So now we have all the data in place. How do we present or show it to the user? So we have two different flows. One is the LSP calls where the component analysis and one is the entire stack report. So both these flows fall into our API server and the API server internally uses our backbone services which actually talk to our graph database where I said the data is already present. And then we have these recommendation engines which I discussed in the previous slide about the EINML part. And along with that we have our own license compliance services running. So it interacts with all these different services and then gets all the information together and then the collective information in the form of a stack report is given back to the user. Next slide. So let's talk about some numbers over here. So we have more than 6 million nodes in our graph that is the packages and versions information on a monthly basis. We have more than 150,000 active ingestion happening. And when this is a, this is not a hard and fast statistics, but this is an average that we have found that whatever user stack that we analyze, we have seen that on an average use particular users, user users around 20 dependencies. And for our component analysis, which is the LSP calls when we are scanning the manifest file, our response time is somewhere around one second. Most of the time it is lesser than one second. We will show you the details how it works. But anyway, next slide. Now let's talk about the scalability part. So all these architecture and services that I talked about everything is broken down into simple microservices, all of them running independently. All of them are actually running on open shift. And for all the internal processing like cues for RDS for graph for S3 storage for all these things we use AWS services. And that we do not need to maintain any of these things and it is always 100% available to us. Next slide. Now let's talk briefly about the deployment and scaling. So we pack all these information into container images and, as I said, like everything is deployed an open shift in the form of containers. The 100% availability that I was talking about on the AWS side similarly we try to maintain that on our services as well. So the Kubernetes load balancing and auto scaling kicks in that helps us a lot where whichever services are being heavily used we can scale up when it is not used we can scale down and make sure that it is always available for the users to use. Then we have a process where we do seamless testing. So any changes which are done to any of these services. We have our regression tests we have our end to end tests running for each of the changes so that we make sure that everything is tested and it's up to date before it is sent to the production and to the user. And last but not the least which I think most of you will be interested in is like everything is open source. So now let's have some live action and for this I will hand it over to my friend Deepak over to you Deepak. Thank you Yusuf that's awesome. Yusuf take you to the theoretical journey so far. So in the next part of our presentation I will take you over practical implementation how we do it to make this to bring the solution more closer to you. So in this journey we integrated with your one of the favorite ideas that is VS code. We we wrapped our solution in one of the extensions in the VS code and published it in the marketplace. So how to use this extension I will take you quickly to the demo implementation. So as you can see in the VS code external downloading this particular extension and then opening the manifest file will bring you to our solution. So in the dependency section itself you can see bootstrap live map and load ash are underlined as red. And hovering over that will give you a sneak peek of why this underlying is being done. So as you can see bootstrap version 4.1.1 has three known security vulnerabilities which has a medium severity. Our solution recommend us to upgrade this version to 4.5.1 and we ensure you that upgrading to this version will make your stack get rid of this particular CVE. So similar to other two dependencies. So that's not all. If you want a comprehensive more detailed analysis of your stacks we present you a more full stack analysis. So right clicking in the manifest file itself you will see a dependency analytics report in the in the bottom option. So clicking over that will bring you some type of window like this. So this is our analysis of your full manifest file. So the first step itself speaks what it does security issues. We analyze your full stack and analyze your each dependencies and whether these dependencies contain any vulnerabilities any CVE information is what we calculate here. So as you can see this low dash has some highest CVE score which is shown in a red which it means the severity low dash has this version has is very much severe to take to ignore actually. So clicking in the drop down menu you can see the current version you are using of the low dash and our recommendation solution. So we recommend you to upgrade this version to 4.17.20. Not only that we also attached the GitHub stacks along with the our presented solution. So that's not all we also analyze the transitive dependencies of your direct dependencies. So there might be chance that the dependencies that live map in this example for the which depends on other transitive has some vulnerabilities. So our solution analyzes that thing also. And so in this particular case you can see the live map has two transitive locus and low dash which has some severe vulnerabilities which you should we recommend to take action on. That's one part of our solution. The second part is where we analyze the dependency detail. So here we check mark three three radio boxes whether this is the radio boxes are security usage and license. So which check marks fail on a particular test is what we marked here. So in this particular case you can see severity of the three of the dependencies are marked as a warning sign for you. Okay, and then dropping over to the hover we give you a more detail about that why we mark this as a warning. So as you can see you are using this current version and this bootstrap has which version latest in the market is what we show in this latest version section. So it is we leave it up to you to upgrade your current version to this latest version or the version which we recommend you in the first tab that is non severe version whatever you suit suits your needs the best we believe it up to you. So in the third section itself, we analyze your licenses of your dependencies that are present in your manifest file. And based on that analysis we recommend you what type of license your this project should have been. So in this particular case you can see we suggest MIT license which is as you know in an open source license. Yeah. So that clearly means that all the dependencies are you are using doesn't has any conflicts and are very much open source, not like the previous case of react Facebook whatever you might know. So, and last but not the least we have a recommendation models, which give companion package recommendations based on your stack. What it means is we analyze your stacks and the packages that are most closely matched with your existing package we recommend such packages to you. So, you can always give us your feedback whether you like our suggestion or not, accordingly, but that's not all. We also integrated with JetBrains marketplace we have extension in JetBrains on the similar ground that is a dependency analytics, where we do component analysis and your full stack analysis may be coming soon in the near future. In the next, our presence that you can expect in the near future is clear integration we integrated with clear to scan the application level of vulnerabilities that are actually present in your Docker image. We then flag that vulnerabilities and you can motivated to take actions on on that. So, last but not the least we have a goal and offering, which is coming soon so maybe you should have already told you we currently support three ecosystems, Maven, Pi Pi, and NPM. So goal and support is what the feature under development it is. So, yeah, more, more exciting features may be coming soon in the near future, but yeah, but last but not the least, we need you how you can help us. You can help us in joining us in the mission to make the cyber world a more safer place by leveraging our solutions. How you can help us by you can pledge you can pledge here by use the due diligence while selecting the dependency for your stack. You can help us by raising bugs in our repose by by having a PRs in the bug fixes by requesting the feature which you like the most in and want us to integrate with our solution with our offerings. And last but not the least spreading the word. So, in the end I would like to hand over to Joseph to take you further. Yes, before we close on this discussion, I would just like to say that all of you present here, just rewind your life back a few years where you would have come across such problems where you wouldn't, you would not be sure of which package to select from all the Google options that the options that Google would have suggested you. You would not be sure about which versions you to choose how they how they are compatible with each other, whether they're vulnerable or not. All these things we get to know. Usually, once we are done with the development and once it goes for the scanning, and we get back the report that the project is good to go ahead. Or whether there are some problems and there are rectification actions that needs to be taken. So, the idea of this whole solution that we have right now is to prevent all that and do all those analysis and everything upfront during the development time itself. As Deepak also devoured, so we do all these analysis reporting everything as at the same time when you are developing your project, or you are doing the active development. We don't need to wait for some external report to come towards the end of your development cycle to inform you about some problems that you might have ingested in the initial phases. So that is all that we wanted to tell and that we wanted to share with that closing notes. I would say thank you for giving us this opportunity to talk about. And I'm sure you will appreciate our efforts that we have put in for this for this whole extension. And yes, please do help us in spreading this word and let everybody start using this so that they do not use any vulnerable package or any outdated packages. Thank you all once again. Thank you. Thank you Deepak in use of I really like the talk and your analytics platform. So we can wait for a few seconds if anyone has questions, otherwise we can wrap it up. All right, so it seems like it. Thank you, everyone for watching this presentation.