Hi everyone- this is Nikki liescho I'm working as a senior backend developer. In the secure composition analysis team I would like to give you a short demo on our efforts on continuous advisory intestines as an intro. What you can actually see here in this image is the big picture right. So, on the left side, we have some advisory sources.

For instance, examination DB or the gitlab advisory database, or the 3v database can be an advisory source and what we would like to do is ingest the advisories as they come in and store them in a bucket on on cloud storage and why we want to do that. We want to do that, because a gitlab instance can pull this data store it in the postgres SQL database, and then we can basically have continuous injections of ingestion of advisories, um and this is a bit more specific of what we actually do with ingestion.

So this part, basically, is this whole image over here. So we have three main components. The first one is the advisory feeder advisory feeder is scheduled to be triggered by a job, and it will basically read data from um an advisory.

In this case is the gitlab advisory database for every new or updated advisor it'd be Post in a pub sub topic, which will be then processed by The, Advisory, processor and stored in the license, DB SQL, um and on a later point we have a schedule trigger for an advisory exporter, job that is going to basically read the data from the license, DB and store them in the cloud storage bucket.

During our previous demo, we demonstrated our advisory feeder, so that was our first integration. During this session we would like to show you our progress, our second iteration, which is basically introducing the advisory processor, and that being said, I would like to show you the database I'm, whatever I'm going to show. You today is on my personal gcp project, so you don't have to worry about anything. You see there, it's not in production right now.

um So what you see here is the SQ. It's it's. Basically, the the postgres license. Db database tables diagram. So you might be familiar with this. There is one new addition to this. This is the gitlab advisory database. This is a very simple table that will store advisories coming from The gitlab, Advisory, DB or gymnasium DB. You might know it like, as that, and it's very simple. It has a uuid, a unique identifier, a timestamp, and it also has the whole advisory injection B data right now, just for demo purposes.

If we execute this very simplistic query, you will see that we have no data at all. I did that on purpose so that we start from a clean state um and what I would like to do is I would like to trigger the feeder, so I would like to trigger the feeder, and this will basically publish a couple of messages on the pub sub topic, and these messages will be picked up by The, Advisory processor and store them in the license DB in order to not start from scratch.

I have updated the cursor of the advisory feeder so that it starts from a certain point in time right, so it doesn't fit all the advisories that it's in the gymnasium DB, but just a couple. So let me trigger this. So this is what you see here. This is the binary of of the feeder I'm going to run it locally.

um So, let's see what happens.

So demo effect basically happens. This is on me. Let me change to the and go to the correct folder.

And run it so the first thing that does the feeder is that it checks out the gitlab advisory DB. It reads the cursor: this is not the initial commit, uh it will check the last commit and it says that there are 192 changes, so 192 advisories will be sent to the database um here. I have the logs of the cloud run. So basically, our advisory processor runs on cloud run and, if I refresh, you will see here quite some incoming HTTP requests and we have some 200 responses which is expected right.

So it looks like the advisory processor actually is processing all these messages. And now, if I go here and now, if I execute this command, I see that I have uh I, have some data. So that's nice, and what it's also interesting to see is: let's count those lines and make sure that it's 192.

Yes, so, as you see, we have 192 unique advisories and that number actually matches the number that the advisory feeder um notify this right. So it notified us that there are 192. advisories being published, and this is the number of advisories that we have stored in the database, and that is my demo. Thanks for watching.