 Hello, please welcome on my presentation about how to find vulnerabilities in VMAS. And so let's start. So what is the VMAS? Yeah, we know the VMAS is actually pretty lame name. And nobody from us really likes it, but we continue with it. It was just first thing we started using, and yeah, it's with us forever. And actually it's for vulnerability metadata as a service. And it just means it's an API service, it's a SQL service, and it's completely stateless, and it's not authenticated. And its primary goal is to find vulnerabilities for RPM-based systems. And we do that based on static evaluation of the package profile of given systems. And so it doesn't take into account any mitigation applied on that system. Yeah, and there are also secondary goals that VMAS provides. And these are for providing metadata about packages, repositories, erata, CVs, and so on. And so what are these technical details about VMAS? So it's a set of microservices written mostly in Python. And we are using Postgres database. And this set of Docker containers is developed using Docker Compose or using OpenShift. And we are not, from the web applications, we are not directly connecting to the database and fetching data. We are using some pre-computed structures to achieve higher speeds of getting results. So here I will just explain the architecture. We currently have five containers. User can access publicly two containers. This is the web application, this is the main and three-point for APIs, and API doc container for just getting some insights on how it works. And in the backend we have a repo scan container, which is used for scanning repositories and fetching CV repositories and so on. And the repo scan and the web application is communicating on internal web circuits. And the repo scan component is the only component that's actually touching the database. And also the repo scan component is pre-processing data from database and making it available from the web application. Also the repo scan component has its own API, which can be authenticated and is used by administrator to add to repositories or CVEs. There are a couple of endpoints. I can show you more. OK, so the updates API is the main API to get vulnerabilities of your package profile. And we have all APIs in variants for get request and post request. Request is always to get updates for single package, or updates or details about single CDE, to get the details about single repository, get details about single eratum, and so on. And the post request is used to get these things for multiple entities at once. So if I look it on that more, it looks like that. In the request you can specify package list and repository list and release words, base cards. And these three attributes are not actually required. There are some mechanisms that will guess the repositories and related products and will return you some available updates, even if you don't specify these three things. And this is how the response looks like. For some old package you will get available updates so you will also find out in which repository you will find this update, of course. And also you will receive all necessary details about the updated package and also the eratum, which will provide this package. And then you can take the eratum and you can ask about details about this eratum, which will return you, for example, affected CDEs or some descriptions and metrics. And the same for CDEs API. There are also some CVSS scores and so on. And yeah, these are the APIs we are using, we are providing. These are public APIs. And for administrators we have, of course, the APIs for adding repositories or synting repositories and CDEs and other utilities for managing the VMAS instance. Okay, so, and we in eratum are providing one public instance of VMAS, which basically contains metadata about everything Red Hat is providing in Red Hat subscription management. And this is about 18,000 repositories. Basically, it's mostly about, I don't know how many content sets multiplied by different architectures multiplied by different release versions. And in these repositories is contained about 1,800,000 packages. And they also store here the CVS obtained from list and from Red Hat CVFs. And I can show you a demo, how to use that. I tried to write some simple script, which will, is it visible? Or can I make the font bigger? Okay. Okay, this is the REL 6.9 server, which is basically basic installation, not updated base minimal package set. And it's 6.9, so it's like, I don't know, one and a half year old. So there will be multiple vulnerabilities. So I have here VMAS report tool, which is something client, which will contact the VMAS server and provides the package list of this system and tries to get available updates. Calls few APIs and displays it on the output. This is just a simple tool, basically. It's available on Wi-Fi. And here I will just display some details about currently configured VMAS server, which is display version and the version of data provided here. We see it was changed like today at 3 AM last time. And so I will just, on the system, I will run this tool. And I will get a list of vulnerable packages I have here on this REL 6.9 server. It's quite a lot, but not that much. And here list of unapplied security advisories and also list of CVs, which are fixed by these security advisories. It's just a simple listing. Actually, in the data return, you can also assign the CV. You have also CVs assigned to Erata. And you can see here all these associations, what's fixed by what, and so on. It's a simple listing. Yeah, this is on REL 6.9 server and I have also an example on REL 7.4, which is also more than one year old and just a bit different set of data. So we don't have any Fedora or other repositories synked in our REL 7.4 instants, but it's possible, definitely, to sync anything. But yeah, there is definitely some luck in the support of the SUSE repositories and CentOS, because there is no update, there are no update info provided by default. But yeah, it may change. We may support for also different sources in future. And we have a couple of challenges we need to solve in Vimas, but also we try to solve most of them, but not every problem has some easy solution, so some of these problems are not fixed yet and maybe they will never be fully fixed. For example, we need to choose between speed and what everything we will cache and how much memory it will actually web application use, because we try to cache as much as possible in the web application. Is it better? Is it better somehow? Okay. Yeah, this is the problem about speed and caching and memory usage. Our web application containers are taking more than 1 gigabyte of memory and it contains one, almost everything we need to return to users. And yeah, it's quite difficult to balance the cache data and the speed and the memory usage. So the second issue is, for example, the automatic product and repository updating, because if we store, for example, 80,000 repositories and if there is no mechanism to tell these repositories are updated, these repositories are static files on some HTTP server, just some metadata stored in repo data directory and it can be time-consuming to download all refreshed metadata. So about that we can try to optimize that. And another problem is there are differences in CV metadata if we take this CV metadata from different sources. For example, if we take the CV metadata from Red Hat and we take this CV data from List or Mitre, so all of these organizations are using different metrics for example CVSS score and these numbers are different so we need to choose which value we will use. And another problem is our inconsistencies in repository metadata and this is the endless problem because even between Red Hat repositories there are differences because every repository metadata were generated at different point in time so they can be in different format you can use different checksum for packages and can use some different time stamps there are basically many problems with that in general but it's getting better slowly but it's getting better so this is some challenges we need to solve and what's the future of VMAS basically what everybody can VMAS use for it's an API service so it can be easily integrated with some other projects mostly it's useful for system management projects or content management projects and actually the VMAS is already used in Red Hat Insights and there are some ideas how to use it in Red Hat Satellite maybe in future and basically these are some internal Red Hat projects where this VMAS can be used for so that's it do you have any questions? so the question was if the project is open source yes the VMAS itself is open source so you can deploy it as you want in your environment any other do you have any time frame that you want to integrate VMAS into Red Hat Satellite? so the question was if there is any time frame to integrate VMAS with Red Hat Satellite I think there are no concrete time frames for this and this was just an idea so it's not planned yet and it's not sure if it will be planned but it was just some discussions do you have any plans to going to the FEDORA REBUS? sorry? do you have any plans to going to the FEDORA REBUS? yes also the question was if we have any plan to pull FEDORA REBUS yes yes we definitely have plans we also contained FEDORA REBUS in our stable instance but we had some issues with that because the packages were colliding but it was probably resolved already but we did not update do you have any time frame? I don't know ok please say again the question was if we can store if we can scan devices in future what do you mean by scanning devices? we are using RPM based evaluations so there were some plans to investigate how we can integrate with other scanning vulnerability projects but currently there are no plans to scan differently in VIMAS than using RPMs ok ok so the question was what effort is needed to get for example RPM fusion into the VIMAS yes so if the RPM fusion is providing for dot xml which has provided advisories and CVs CV associative to these advisories so then it's definitely already possible to pull RPM fusion to VIMAS any other question?