Hello to everyone. Best greetings from Poland. We'd like to gain your focus on the security of parts of your software who had not even chanced to acknowledge their existence. So let's go. The reason we suggested to you to steal your time with listen to what we have to say is simple. There is a big hole in security in every software made and installed due to opensource components. 96% of companies are using Opensource. Are they using structured approaches to open source vulnerabilities? I hardly believe they will tell you about it. My assessment is they will not. We have a concept and are developing a tool to cope with this problem. We treat the problem in the Devsecops framework to put the solution in the right place while not adding a fifth wheel to the wagon agenda covers our assumptions, solutions, concept and tool current status. There are two of us who will be presenting it. Alexander Baronovsky who is experienced product lead producing open source software, Eurolinux, EuroDB, Euroap and so on. And me, I'm a little bit older and focused on selling these products, packaging it and selling. So I suppose it is a good company to say you about it. We have now very complex environments, both infrastructure and systems on the one side and development and maintenance on the other. That is due to technological progress and dynamics on the other hand. The market needs better effects. So KPI are so very strong, focused on effectiveness, how to do it with it. There is a very well tested approach of DevOps to chain better interaction between developers and administrators. Having in mind that there are more digital security vulnerabilities, we must add some security part to it. So is devsecops. Devsecops idea doesn't cover component issues. Our approach is KYCC, so it is know your code and coder. As we said before, we are still in the DevOps work with some security aspect added. So let's see at it. We have here classical devsecops infinite look with SEC audit. So it's never ending story. So we have static application security testing, dynamic application security testing, interactive application security testing and so on and so on. Many aspects, many activities, many tools and on the very end monitoring to have some feedback from production line probably we said you about complexity of the problem. Each of your software you are building or ought to be built have some components of opensource and how to check it. We must check if the coder is geopolitically securing, if the code is reviewed very timely, if the project is active at all, if the vulnerability testing is paid. There is many aspects of risk assessment, which we are not aware because it is components which isn't sold to us. It is components which is part of only called by software we are buying. So it is very important if there is any structured approach to it. No, there is no. Is there any empirical test research based models? Yes, there are. We will say something about it. But why? First of all, we must know from what our software is composed, what third party components are in our software. So it is called Sbom on. It is from infrastructure bill of materials, concept software bill of materials. So we must know what we have inside it is first and most important thing. Next, how to mitigate risks involved with these components. If we know components, we can check if they are risky or not. So next, we must call this risk because no third party component is risk free. We're just choosing the less risky one. And next, we must just put it in our software deployment pipeline to have it right in place. If we don't, of course, first of all, we don't know if the project will be developed in the future. We don't know if we'll address any vulnerabilities and we can face the problem at the very end. We can use it, this component anymore. So we must change it. And it could be very expensive. We must change architecture, we must change whatever, all, maybe license even it is very expensive. And in the meantime, you can lose our customers if we offer our software to somebody or our service based on the software. So it's very expensive. And now our approach, software composition analyzes risk management, our code name for our solution and what we are doing, we are just Sb oming, I may say. So first, we are finding what is inside and it is not the first line, for example, library or driver or something else, but even more if the driver library calls other library part of software from outside. We are checking it as well. And how we are checking. Okay, so when we are talking about how we might name it scar, Scarmo, as our code name Mark said, we are not looking into the single component. Of course, each of the components has its own score, but we are also looking at the score of the global score of a system that we are using. And it's quite similar in thing about it to CVE. In theory, you have a single CV in your system, for example, I don't know, York for J was very famous last year. But when you think about it, you're not saying we need to patch the CVE, we need to patch the systems. So, by the way, this is why the environmental metric in CV were introduced. So there is the XCV, but there is the context, and it's the very same with the serm. So going back to it, basically, at the moment it's like four vectors. But I personally think about more about dimension, because when you think about the vectors, like the line, of course this line can be like in three dimension, by the way, from algebra, but I think more like a dimension because we have multiple vectors in that dimension. And the base vector sales dimensions are the following at the moment at least. Software code contributor profile, the product dynamic, code quality and vulnerability dynamic. We call it CVA plus. But I have no idea if CVA is not trademarked, only the code name. Okay, let's start with contributor profile. And this is one of my favorite, because it's shown that we are living quite peculiar world. One contributor programmer can commit to multiple repositories. And this is like the project world. But on the other hand, when you think about it, a lot of companies and also projects are using their mono repos. So for example, Samba, but it's a very huge project. If you want to check out Samba, there is a huge Monorepo, but actually have libraries, the utilities program, things they get. So one contributor is working on one project, but it may be because it's Monorepo. So we are also aware of that. And we add the grain of salt to this. The other thing is the number of contributors, and it's exactly what Marek said earlier. There is the probability that the project will be abandoned. And sometimes it doesn't look like the project is abandoned because, for example, it has multiple stars. There are issues, but for the last two years, none of the pull request or request for change, or whatever you name it. So basically, bug fixes or enhancement to the project were made. And a lot of programmers just don't care to say that, sorry, this project is abandoned, so you don't get the clear information about that. Next to thing is, let's say quite the same, because it's time zone. When thinking about time zone and gopolitical risk, they're a little bit interwind, because it's somewhere done in some time zone. It's probably dont in some country basically. And we are also looking the countries that the software is made. So why is it important? Well, we live in divided world, and open source can be weaponized, literally weaponized against us. And I'm sorry to say that, but we have in the very recent history, the people who weaponize open sourced. And even if we say that, yeah, I'm against someone, and I totally get that and I respect that. Weaponizing the open source put the whole movement of open and free software at risk. And I'll be honest with you, it's weaponized but also on a very different level because when you think for example about the basic freedoms that Richard Stalman back like 50 years ago started and for example an advanced it technologies export control for example if you are buying something from one country you cannot use it in another country. And this is like an enterprise agreement and things I get. So it's already like threat to the open source. So you cannot stress enough the fact that our world is full of imperfection. In that case I will name it imperfection because I would probably use a stronger word but well it's divided and as Marik said, we are from Poland and if there was a country that is constantly threatening me, threatening my family and including nuclear inaccuration of my country I would personally think twice, at least twice before using the software, including open source software as well that is produced in that time zone or country reality time zone is also important because sometimes you can see that the fix or predict when the fix will come because well programmers are also people and let's be honest, the bad guys never sleep. So if something is made, let's say in us it's very likely that if the bug is discovered and published and there is the exploit and they are sleeping, literally sleeping that it might be delayed until work time or at least when they wake up. So yeah, next one is the protect activity and this is like the next vector dimension. So we are basically looking at let's say free things. There is much more but free things. And first one is interesting project index and it's I would say quite sketchy in some cases because if something is popular there is a higher chance that it will be safe because more people will try to break it, not use it, break it. And we all know that Eric as Raymond Linux will, this will say that basically there are enough eyes on the code that all bugs are shallow or will be fixed. And things I get but it's quite criticized because the hard bleed simple mistake. But on the other hand it was fixed. For example in BSD before. On the other hand there is some data and evidence provided by Google actually and their repos that says that well if the project is very popular there's a higher chance there will be a fix that people, the commits to the project, especially external commits to the project with the back fixed security and things I get. The other thing is distribution of activity over the time. Well it is how it sounds. So how much activity is in the protect over time. But very must understand that there are the projects that are very stable and won't get much activity and not because they are bad project, no, but because we are major. I will give you the short example. There is the access control list in Linux and there's access control is utilities. We are using the very same very old, very basic system calls and capabilities to create the access control list. For for example if you are a user and some group you can do something. So it's very not true for this kind of software not to have a lot of activity over time. So we have to take into account that some protect might get very low activity, but it doesn't mean at all that they're unsecure. The next one is the difference of delta basically of active contributor over time. And once more protect can be abandoned. And if there is no one who actually can get the work because there is one contributor, for example, well it's not good, it's not good. Think about the bus factor in that case. So one person and the protect is gone and before someone will be able to hack this project and work on it, we take some time. The other thing is that these contributors also, if you combine this with a time zone or go political risk and things like that, you'll get that. For example, if there was some kind of tragic situation in the world, including some country or countries, that you might actually use the access to it. My guitar. We will try to curse opensource. Yeah. So next thing is the code quality. I'll be honest, I was quite surprised when we discovered that a lot of software won't pass today. Coding standards, sorry, they won't pass. There are so many well known issues with that code. Yeah, issues. For example using voata and c plus plus. But well in theory a lot of people think that well it will be threatsafe. Not at all. There is very good talk about it from Facebook now meta of course the other things like using buffers that are not checked, very popular, especially in c. And when you think about it once more, you have to take into account the different type of project. Because if the Linux kernel is using something that is the buffers, like naked buffers, they probably have a very good reason to do that. But if it's like the utility program, some command guide interface program, then maybe this route destroy, check the buffers. And yeah, we also believe, and this is why the scoring is quite important, that if the code quality is high it will be easier to maintain this project in the long run. Also there is not on this slide, but we are also looking on the things that we call the language popularity and trends. So basically if you have some project that is written in the language that is becoming slowly dead, and I can give you, I know that some people feel triggered by it, but what it is written in Peru for example, very good language without doubt, but this language above. So it's like for example Python and Python three or Python 2.7. Yes, and you have a pervade still maintain the branches of version the language, but the number of programmers who are able to program it is dropping and it's dropping quite sharply. So this project might actually be the risk, especially in the long run, if someone don't migrate to the newer version or to something different. Last one, and this is my least favorite and I will tell you why, a CV plus or dynamics or CVE. And of course we have version two, version three and version four. You might ask why would you have a version two? Well, because sometimes the very old bugs are updated and if there is the update because it was which are rediscovered or the CV wasn't fixed for like ten years, it happened, then we actually need that score because there is no overscore and there is of course a new version of cvss. So it's like Commodore scoring system that tells you, and we are doing basically we're looking in the last 90 days and it's getting on the very thin ice in my opinion. But I don't like it because, well, if you look at the pony award, this is the award from the security community about most of the vendors and that they have mismanaged the security reports and their behavior to it and how they should respond and so on. That's basically it. Of course there's also the good part of the one that says that someone did something very bad is more popular and let's say culture. And this is a problem with vendors, why? Because a lot of vendors might not make the code, but they want CVE because, well, first of all it looks bad. And second of all it's not so easy, it's the extra work. So the programmers like me are like, I will fix that, I won't tell anyone the next version will be fixed. Easy. Why even bother? You know, to make the CV I need the common platform enumeration. So I need to send the special mail with XML in it and then I need to do that. And the whole process of making it, sorry, I will name it bureaucracy is actually more time consuming sometimes than making the fix. And I said, there's also the reputation hit and it's skating on the skin eye on finite. Sorry. Because we are actually with the scoring, we are punishing the good guys, we are unable to punish the bad guys. We tried. Believe me, we tried. We look into a project that does not have this or try to avoid them and then try to with some statistic magic. How much code is put, what languages and things I get get that there should be probably some CVE. But while it's very hard to find, to be honest. So we decided that, well, if it's not stable, we are able to say about the things that we are unable to prove. In that case we can only. And I believe that the scoring must be on the real data. And there is a great blog post from Daniel Stenberg. Daniel Steinberg is the author of C URL. The C URL is like the most popular software used in the world regularly. Guys, Linux is not that popular, because when there is Linux there is this URL, probably. Yeah, and he wrote about that. Well, having the CVE and CRO is the good. And you should also think that if the vendor is honest with you, the programmers, people who manage the protect are honest with you and say guys, look, there is the security problem. We made the fix, fix your system. This is good, but unfortunately the securing is for me. Well, I said it's quite problematic because once more we are punishing the good guys. Marek, can you continue? Thank you Alex, for presenting the approaches. You ate my time, as usual. Okay, so let's have a look when we can use this approach. We find at this time four touch points where we can use it in the software development pipeline. The first one is when we are inventing our architecture. We are looking for accessible software and we can miss the opportunity to choose well. So at the very moment of the starting of the project, we can fail. Next one is when we are building components and to be cover vulnerabilities. We are getting the new version, it's very usual scenario. And we can fail again, because this new version can have dependencies or features which are killing our application. And third point is when we are using the software in production real time and we are trying to maintain it at update components. If you are not checking these components, you are failing again. And the last one is when we approach the moment where the component is not viable for us. It's not developed or obsolete. We know the vulnerabilities will not be addressed in future. Here is the classical production pipeline. So first we have developers, they are choosing this code. Next there is code building, packaging, embedding, coding and so on. And of course dependencies in the data. And here are these four touch points I have said here before. So first one not good choice of the component. Second one unaware updating of the code during building. Third one unaware and unchecked dating software during production phase. And fourth one is when we must choose another component. We can once again fail. Because conference is about devsecops. We must place our concept in the framework, our solution, our approach. It's not solution yet. Scarm is placed in the testing, beyond testing and on the very end in production files in vulnerability testing of software. Because of course as you know, vulnerability emerges during the time. Here is our solution, opensource nation automation of Checking OpenSource this is basically the protect that is co financed from European Union and we are very grateful for this opportunity. It's made with National Research center in our country and basically we want to provide you the platform and the rules, the basic rules and also the system to assess if you are using the right components. For example, you might think okay, we are building some application and this application in the end will use some database, it's very likely. And then you might ask yourself should I use the Mariadb or should I use MySQL or maybe postgres? Because all of them, let's say they are quite comparable and we want to have a comprehensive evaluation system integration in the portal. We want to inform you. So there will be security and security assessment, obvious risk. It will be very practical usage of cvss because for example you have the image, we will give you the golden images for some solutions we are working on. Some of them are open source, some of them also the open source were packed by us in the manner that they provide the whole stack of something. And we were very practical because the CVSS or this common vertical scoring system will for example confirm you that you use the image that is let's say one month old and it already has this and this and this vulnerability. The next thing is that of course we have a web interface and this web interface you can get to the image and get for example the information that well you're using the postgres and for example postgres is using, I don't know, CRL is useful always because I said this is one of the most popular structure in the world but I dont know, it's using the postgres libraries of course. Yeah it makes sense. And with the libraries you can get the securing for the libraries for example, but also the scoring for the project and then the scoring for the whole system. Yeah. And it should allow you to get in depth analysis of the code, quality of the component you're using. Of course the possible vulnerabilities, the history. So as we said, there is like index of something, we name it, the index of contributors contribute over time and things they get. So it should have it and many other risk factors. It's in the mate and will give you the ability to run images that are secured or have at moment things like that. Of course on AWS, on container engines over the docker. Of course container engines. Mostly it means that it will be run on the Kubernetes, your own Linux distribution, ibaba cloud. Kubernetes will be openshift, things like vmware and yeah you have probably right now we have like twelve platforms like the runtime platforms that we are supporting. For each image that we are producing there is quite a lot of images that are regularly updated that have scoring included and so on. It should allow you to streamline your securing assessment in details. For example, oh I want to use the radio. We have scores for some software well known. We are trying to get the most software. We are also doing things for our partners from government and asked us if we can assess some software for them. So it's like a little bit of public benefit from our side. Yeah, but if for example I said you think should I use redis? And then you look into the profile of contributor for example and you think yeah, it looks good or not depending of your go, political risk assessment and things like that. You might ask yourself okay, we can use Redis or Rabbit MQ for making the queues basically in that case. Or yeah, it depends. They're not the same, let's say. But sometimes you can change the one to another and then yeah, I think if it's good enough or not, it will be. At least we're informed. I think it's automation. Yeah, we will end here for your audience. Yeah. When you will probably see that video. We have about a month to finish it. It's already in the state. But I'll be honest, I'm proud of. So I'm eager to wait to provide it. Thank you very much. Thank you.