 Hello everyone. This is Jayendra Prasai. I'm a software engineer at Red Hat India and in this session I will be showing you how a developer or an organization can implement DevSecOps capability into their projects using a single platform that is CRDA platform or also known as code ready dependency analytics platform. So here first of all we'll see the overview of DevSecOps then what are the problems faced by developers when they need to decide their dependency stack, what is the solution we are proposing and how CRDA fits in here or how CRDA is able to address all these problems. So first of all what is DevSecOps? It stands for development, security and operations and this is a concept which says that security has to be checked at every phase of software development lifecycle. It means when software is being developed, when it has been tested, when it has been deployed and when it has been delivered to the end user at every step security has to be checked. Why so? So that we can avoid any kind of data loss, any service outage, any unauthorized access or any security violation can be avoided here and one of the way to ensure that having a reliable stack, it means that the dependency stack we have should be vulnerability free. So how do we get a reliable stack? Let's see that in the next slides. So now we come to the problems that when developer need to decide the dependency stack, so what are the main problems they face? First problem here is that how do a developer know that this is the right dependency? There are already thousands of packages available in the market and every day there are new packages or new versions are being released. So out of all of them, which one is the right dependency here? Second problem comes with the licensing terms that you have your stack. In that stack, every dependency has its own associated license. Now are those licenses are compatible with each other? Are there any restricted license? Are there any outlier license? How do a developer know that? And the third and the most important thing here is that the dependencies added by the developer should not have any security vulnerability. It means if you are adding a new dependency or you are upgrading to any new version, so you should not introduce any vulnerability to the your stack. And this is the problem which mainly goes unnoticed because many time developer doesn't think about that and entire development is done and maybe later some point of time somebody noticed it that this stack has vulnerability and now the developer is forced to actually fix that. Now developer has to either use different version of that package or maybe change the package itself. And because of this, there is a chance that you also need to change the code base because maybe the functions are changed because you change the version or change the package itself. So the you have to actually rewrite your code, then it has to be tested deployed in that cycle goes again. And it is a very time consuming thing. So how do a developer know that the dependency they are using is actually a vulnerability free. And the last problem here is that there are many packages available for the same thing. For example, we considered JSON parsing. So there are many packages available for the JSON parsing. Now out of all those, which one is well maintained, which one is properly upgraded or there are many number of contributors for that one, how do a developer know that? So we have a solution which can actually address all these problems. That solution is code ready dependency analytics powered by Redhead. So this is a platform which can actually address all four problems we have seen in the last slide. So what is CRTA? CRTA is actually a platform which can provide you vulnerability and compliance analysis for your application. It will help you to like find a vulnerabilities and fix them. And it is not just a vulnerabilities. It is also the licensing details. It is also the popularity of that package. It is also some addons like is there any recommendation there's all those things can be provided in a form of a single report. And by seeing that report, user can actually decide their reliable stake or they can reach up, they can make sure that dependency stake is vulnerability free. So how does CRTA work here? So it is even the first slide in the DevSecOps. What we have seen that the security has to be checked at every phase of software development lifecycle. So for example, we come up with the product development when a developer is starting build of that project or actually a project building is started now. At the time when you are using some ID, then user can actually make sure that packages are not having any vulnerability at the time of development itself. When you are adding a dependency or when you are deciding your dependency stack at the time itself, you can actually analyze those vulnerabilities or you can analyze that entire stack and make sure it is a reliable stack. So we have our extensions available with some of the very popular external IDs in the market, which is a VS code and IntelliJ. You can actually install our extension there and you can use the capabilities of CRTA into those IDs. Or if you are a CLI expert, you can use our CLI tool and this CLI can use by other platforms as well. For example, you have some environment where you can write some scripts and you want to test the vulnerability of your stack there. You can use this CLI tool. You can call few methods from here of the CLI and then you can actually analyze those dependency in that environment also. If it is a some environment which is not available here, there is some third environment here. So you can actually use this also. Now when it comes to the pipeline, we have completed our development. Now we are ready to deploy it. At the time in the pipeline, some of the very popular pipelines are the Github workflows are there, Jenkins is there, Tecton is there. So we have our GitHub action, Jenkins plugin there, Tecton task is there, which can actually give you the analysis, the exact same analysis what you see in the IDs. So when you are actually creating your pipeline, you can implement this CRD actions or task or a plugin there. And then based on the analysis report, you can decide that whether to pass this build or fail this build to you whether to deploy this build into the cluster or rollback. So this kind of decision can be taken while building and deploying the application. Now we come to the third phase, which is the containerization. Now your development is ready, your build is done. Now it's time to deliver or it is time to containerize your application. So after that also you can scan for the securities. We have Claire plugin there. So Claire can actually scan the image, it can find out the dependencies used inside that image. And then it can analyze those using CRDA. And then you can see that this image is actually having some vulnerabilities. And if you push those images into quay, so there also CRDA will kick in, it will analyze that image and it will tell you that this image is having some vulnerabilities. If there are any present, you will get the flag. So by this, you can actually analyze your stack at every step of software development lifecycle. When you are building it, when you are deploying it, when you are analyzing it and it has been shipped everywhere, you can actually scan for the dependency. Now let's see how CRDA works here. So let's start with the development side. We have IDs there, we have plugins, you installed our extension there. Now you can scan there. So whenever you actually create a manifest file or whenever you edit any manifest file, whenever you open any manifest file at the time CRDA will kick in, it will check for the dependencies. And you will get an alert. If there is any dependency which is having vulnerability, there is some security issue, you will get an alert. Let's see how it looks like. So here, there is an, here is an example of Maven manifest file, which is pom.xml. And this is how you show a dependency there. So this version of the dependency is vulnerable. You will get an alert. There is a red line you can see. When you go there, it will show you few details of that vulnerability. And it will also recommend you a version. If you switch to that version, this vulnerability will be resolved. So like this, every vulnerability of your manifest will be scanned. And if any of them are having any, this issue, you will see those alerts when you are creating your manifest file itself. So you can actually fix those when you are building your application or when you are actually creating your application, you are starting to develop the application at the time itself, you will see. So there is, at the very beginning of this cycle, you got these details. Now you can fix them right now itself that so that this problem doesn't go further to the next level. Now, as we have seen for the vulnerabilities, but we discuss about other details also other problems also related to license, the problems related to popularity of that package. And you want to see that as well. So you can use a feature called stack analysis of CRDA. In this one, we will analyze not just the direct dependencies, also the transitive or some people call it as indirect dependencies of that stack. And we will show you the analysis of that entire stack. And then by seeing that you can actually decide that whether you want to use this dependency, whether you want to change the stack, you want to alter that stack, everything you can decide. So how does that entire report looks like? It has multiple tabs. We'll start with the first one, which is security issue card. So here it shows all vulnerability related data. And this data is taken from SNCC. Now here the question would arise that why SNCC? That is because SNCC is one of the very reliable and very advanced vulnerability database available in the market. And if you use CRDA, you don't just get access to the public vulnerabilities, but also the vulnerabilities which are private to SNCC. Now what is this thing? So it means that if there is any vulnerability which is found by SNCC, it is not right now publicly available. SNCC actually got that and reported that this package or this version is having a vulnerability and it is detected by SNCC only. So right now, till the time it is not publicly available, it is private to SNCC. Eventually, in future some point of time, that will also get public, but till the time it is available only with the SNCC. So if you use CRDA, we'll not just get access to the public vulnerabilities, but also the private vulnerabilities. So in this card, the first thing you will see is the total number of vulnerabilities and total number of dependencies which are vulnerable. There might be a chance that a package is having multiple vulnerabilities. So you will see both of them here. Now as we have discussed about the public and private vulnerability, there are two tabs. If you want to see the public one, you go to the left. If you want to see the vulnerabilities which are private to SNCC, you go to the right and then you will get a recommendation for the non-vulnerable version. So what is it? It shows you that this is the current version you have which is vulnerable and we are recommending you another version. If you switch to this one, this vulnerability will be fixed or this version is not having any vulnerability. So you should consider upgrading your version to this version. Then we will also show you some other details like severity score, CVSS score exploits vulnerability ID and if you want to read more about this vulnerability, you can actually click here. It will take you to a page where entire detail of that vulnerability is present. You can read it. You can understand that what is wrong with this one. Then the second card here is dependency detail card. So in here you will see all the direct and transitive vulnerability details. It will show you that how many direct dependencies are there and how many transitive or indirect dependencies are present in the stack. And then you will see the latest version as well that this is the version you have and this is the latest version available in the market. So you might consider switching to the latest version. And then there is also GitHub statistics which will give you some detail about the popularity of that package. So it will show you that how active this repository is, how many contributors are there, how many folks are there. So based on that you can actually decide that whether this package is well maintained or not, whether you should consider switching to some other package. All those details you will see here. Now the third card here is the license details card. So what it has? It has a suggested license. What does it mean that you have a dependency in that one? Each dependency has its own license. Now according to our analysis and based on the combination of licenses available in that stack, what should be the license of your application? So we are suggesting that based on our analysis, this should be the license of your application. So you should consider giving that as a license. And here we have one more thing, which is license conflict. So what it does that it shows that there are this many dependencies are there and maybe two or three or multiple licenses are not actually compatible with each other. They are conflicting. So you should consider resolving that conflict. There should not should not be any license conflict. The licenses should be compatible with each other. So you might consider changing the packages and fix that conflict. And there is also one thing called unknown license. So what it is means that either a license is very new or there is some weird name keywords. Many times it happens that the developer give their own some license, weird license name. So for some reason that license detail is not present into our system. So we show that is unknown license. But it is not that it will always be unknown for us. Once we notice that we have some unknown license, we would actually analyze that license. We will study about that. And then we will add that license into our system. So whenever next time you run, you will see details of that license as well. Now the last card here is add-ons card. So it is actually AI based recommendation card or AI based AI based company and the cat recommendation card. So what does it shows you that according to our AI model, we recommend you that this package has to be added into your stack. And then we also show the confidence score here that how confident our model is about this package. So if you see that it is highly recommended, so you might consider adding that into your stack. And then also we have one feedback option. So we are showing you all this analysis, we are showing you all this recommendation. And if you like that it is properly given, you can give us a vote. And for some reason, if you don't like it, you can give us download. And then based on the feedback, we would actually like to see that what is going on and we will make sure that it is fixed now and then you get a better response from CIDA. So we have seen that how this thing comes as a development cycle or as a development step. In IDs, you will see this report. But obviously when you are running that into a pipeline or in some image, then it is not possible that you, that developer intervention is not possible there. It's not possible that you see that report by your own eyes and then decide because in the pipeline it might run in the midnight or anytime. So there we also show an output in a different format. We'll see that in the next slide. So this is an example of GitHub action. It means when you run it as a pipeline or as a GitHub workflow, how you will use CRDA. So there is a task available for CRDA. There is a GitHub action available for CRDA. You would include that into your workflow. It will run. And the output will show as a form of JSON. So this JSON is also consolidated summary of that analysis. And then you can decide based on this JSON. For example, if you say that total number of vulnerabilities are more than 10, then you fail this build. Or if you add some other dependent or some other criteria, that if those are low vulnerabilities or low priority vulnerabilities, okay, fine ignore that. If it is high vulnerability, then you might consider failing it. So based on your criteria, you can write some condition. And then you can decide whether to pass this build or fail this bit, whether to deploy this or rollback. And you will also get the report link. So the report what we have seen in the previous slides, you can actually go to that link and you will see proper retail report there as well. It's not like it's just a consolidated assembly. You will also get the complete report. And you can analyze it and then based on that, you can actually decide about the quality of the build. And always we are running short of time that we cannot consider seeing the other extensions also. But the links of all those extensions or a plugin is available here. You can actually go to those places and you can download or install them. And then you can give it a try. So this is how you can achieve the DevSecOps capabilities into your projects, just by using a single platform that is code ready dependency analytics by Red Hat. So this is it from my side. If there are any questions, please let me know. Thank you.