Hello everybody. Thank you so much for joining us, my name is Anais. Work with a open source team and accurate security, and I'm gonna be running this webinar.

I know many of you who are joining have met us a coupon before. So if you just want to post high in the chat, like, if and tell us if you've met us at a coupon or other conference, before that, that would be really cool just to to see whom we've met in person. If there's somebody here in the chat, isn't the Babina who we've met in person or Yeah. Just tell us what what are your main interests in learning more about implementing opens or security scanning?

I'm monitoring the chat, so if anybody wants to share, then I'm gonna see the messages and we can just talk a little bit about it. Otherwise, I'm gonna started with the webinar as well. Let me just go ahead and share my screen.

You can see can see my presentation, right, just to confirm that I'm not gonna talk just to myself. Yeah. Awesome. Yeah.

You're all good. Okay. Cool. I see if anybody wants share on a chat. I'm gonna see it.

So feel free to post your interests in open source security scanning. This webinar is really about to do and those of implementing Trivy, our open source security scanner, but also just in general how you could go about implementing security scanning in your infrastructure in your own projects, in your demo environments, in your home lab, or within your teams at scale.

So yeah. You see that. Cool. Awesome. Yeah. So I work as developer advocate. I have been working as developer advocate at various, companies and in different industries in the tech space for the past five, six years.

I have a bachelor in computer science, which I'm really proud of. That's why I like to highlight it because I did that as part of while I was working. That took me a long time to get. And I worked for more or less a year aside reliability engineer for a startup in the UK.

I like to highlight that because I'm really interested in anything observability, monitoring related.

Yeah, so I also love to combine our security tools with open source monitoring tools such as Pires. And we're gonna talk a little a little bit about that as well in this webinar.

Now, I'm also an ambassador of different organizations I'm a GitHub star, a grafana Labs Ambassador, and then also an open UK ambassador. Now if you are in the UK, anywhere close to London, Open UK is hosting and opens this conference next week on the sixth and seventh of February. So checked it out. It's called state of OpenCon. I think they're also live streaming, the the main talks. So do check that out. If you're interested, they have some great, host speakers panelists, check that up if you're interested.

Now this webinar is based on my experience of implementing Trivy in different environments and talking to lots and lots of different users, open source users at conferences, but also on our Slack and on GitHub discussions on how they implement security scanning. I'm also basing a lot of what I'm sharing in this webinar on different blog posts, such as a blog post from bias engineering, from economics metal, lift engineering, and merge apply. These are all example companies who have written about their integration of security scanning specifically, Trivy, in their environment and how they went about setting that up and making the best open source security scanning.

So if you want to learn more about any of these integrations, you can check out our Trivy GitHub discussions where we have an adoption section where companies just share how they are using Trivy and share blog posts such as these ones. Now if you are implementing Trivy and your company, we would also love to hear from you about that in the GitHub discussions.

So just a quick overview of what I'm plan to share in this, Webinar. It's not gonna be a list of these other things you should this is a checklist of what you should be doing versus this is a checklist of what you should definitely not be doing. That's not what's gonna be in its webinar. I'm gonna talk first about security scanning. How does it even work and why and when you get started with it? And what's the main goal of security scanning?

Who should do security scanning and then show you on the basis of Trivy, how Trivy can help you and how just generally the value that security scanning can provide you and your project.

And based on the some of the blog posts that I just highlighted, as well as my experience.

I'm gonna share some strategies on how you can approach implementing security scanning. Now at the end, of this webinar, I'm gonna give a live demo on how Trivy works and how you can get started with Trivy and where you might or might not use Trivy in your environments.

So this is the overview. Let's get started on security scanning. Who is used to security scanner before or who is completely new to security scanning?

This is really this very nice focus to bring everybody first on the same page, and then we're gonna expand from there. Basically, to get cyber security you don't have to be a security expert.

When I got hired by accurate security, I've never really used the security scanner before fun fact.

But I did well so far. And there are many other people, many engineers who don't actually are security experts and who just want to make sure that their resources, their development resources doesn't don't have any, vulnerabilities, any misconfigurations within. That's exactly what a security scanner can help you with. So a security scanner, a tool, usually a CLI tool, or a tool that you installed in UCIC pipeline, has a list of different resources different, databases that it accesses information from. So for example, for vulnerabilities, it has the national vulnerability database where pulls information from and has, the vulnerability databases from different vendors such as Ubuntubun to DBM Red Hat, who all publish vulnerability information on which vulnerabilities are found in different versions of their software, for example.

So as security is gonna pull all of that information, it also has a list of frameworks and best practices. So for example, in the Kubernetes ecosystem, there is there's certain guidelines on how you should be configuring your Kubernetes cluster and the workloads that you run on Kubernetes.

So these are defined in frameworks and best practices and quarter site within a security scanner. And then a security scanner is Trivyl also takes a list of potential misconfigurations.

Now, these are a list of best practices. Here are the things that you should be doing, or these are the things that we have served people, get wrong and, malicious entities try to exploit. So for example, the aqua security research team is always looking for, new loopholes loopholes loopholes in this configuration that people can exploit and how actually people are exploiting that. And then based on that information they gather, they codify that into a list of potential misconfigurations, and that's also provided to, for example, Trivy and, other securities cannot also make use of these kind of information. So it has all of that data. Then you provide a security scanner with the, for example, a configuration file that you want to scan for misconfigurations.

And a security scanner will perform kind of a comparison scan of sorts. It will check what configuration have you set up. And what, the best practices tell the security scanner how something should be con configured. And then it can it will just run a yes or no comparison.

Is this misconfigured? Yes or no? If it's misconfigured, it will produce, a section in a scan report that details how your configuration file is misconfigured. That's in simplest form how a security scanner works.

Now, across yourself, the supply chain, you have lots and lots of different tools and platforms and resources that you deal with that you work with on a day to day basis, Now these are the actual, dependencies of your software, of your application, the libraries that you install in your file systems, the tools that you use such as git, as well as all any deployment tools that you use and set up.

But also as part of your software supply chain is, for example, the processes that you have in place in your team on how you make upgrades or, get started and implement new features.

That's all part of the software supply chain. Now the thing is with in security scanner, we try to scan as much as possible of hours after supply chain. Now we can only scan what we can actually codify, but you can actually write down what is tangible for security scanner to analyze basically.

So if, teams, if projects are using, self deploy those self those development platforms where you can just do click ops and provide the platform of a container image and they will set any everything up in the background. That's not good for a security scanner because a security scanner will not have access usually to any configuration that that platform will set up. So the goal of security scanning is that you have as much as possible, fortified, ideally in a form that you can store the resources and gets and then also provide to a security scanner to a platform to scan for security issues.

Now as part of security scanning, we try to discover any security issues as early as possible when we get started, developing a part of our application, implementing any feature, testing any feature before it actually hits our production environment. So where you get started with a new aspect or a new part of your application.

It's usually far easier to fix any bugs, to fix any security issues as well, and the business impact will be far less than if you wait, to actually identify security issues until the end right before you deploy something new to your production environments. Because the complexity of your resources ultimately increase over time. So the goal is really to to implement security scanning as early as possible in your system development life cycle and then fix those vulnerabilities as well.

So what issues can security scanners actually identify or what should they discover? Now the following list that I have here is really based on Trivy and Trivy security scanning and the scanners that are encoded in Trivy. No. Different types of scanners will have different, yeah, different security issues that they identify. For example, intradi, we have vulnerability scanning, Now you will have other scanners that just focus on vulnerability scanning. So their only focus is to scan, for example, your container image for vulnerabilities.

Now this is a screenshot of, Trivyl vulnerability scanning.

And as you can see, we are basically specifying Trivy. And then with the image command, we want to scan our note nineteen Alpine image for vulnerabilities.

Now we specify also some additional flags, the first one is that we only want to see critical vulnerabilities, and then we want to ignore all of the vulnerabilities that don't have a fixed yet available. And these filters allow us ultimately to see only those vulnerabilities or security issues that we can do something about that are meaningful to us.

So the first thing within vulnerability scanning is that you're provided with a list of vulnerabilities that are found, for example, within this container image. So you have the library that you're using, but that's used within that container image, you have the name of this, like, the CBE ID of the vulnerability, and the severity, not the severity and these other information also metadata information that you can find on the vulnerability is pulled from a variety of different locations, generally from the national vulnerability database, but then also it's compared against the information found from vendor specific vulnerability databases.

So this is where information such as disability after vulnerability is coming from. And then the status of the vulnerability is also usually provided by the vendor. In this case, the vulnerability has been fixed. Here's the installed version of the version that you actually have in your local moment on your or in this case that's installed in this container image and then the fixed version, that has the fix implemented of the one for the vulnerability. And then we have here some additional metadata information, the title of the vulnerability, and a link to the act for vulnerability database, but you can also find more information. So this is generally the information it's provided within vulnerability scanning for Trivy.

Now, Trivy also dismiss configuration scanning. I mentioned it a bit before, as I explained what security scanning actually is. Now instead of providing here another screenshot, I thought it's more practical to showcase some of the misconfiguration that you could identify with a misconfiguration scanner. So let's say you have set up your, installation of your application, with terraform, or with a Kubernetes Yellow manifest, you can scan that, those configuration files. Also your Docker file for any misconfiguration, is there anything misconfigured?

Now, Trivy can also scan you AWS services from its configuration and many other resource types and identify what have humans configured.

Now, this table here specifically.

You don't have to wait every section, but it's basically taken from a public GitHub repository from a list of variety of different misconfigurations that relate to how different organizations have stored their data. And basically how the data storage has been misconfigured.

And then as a result of the misconfiguration, the data that has been exposed off that business, customer data, or other sensitive information that has been exposed publicly. So this information is from twenty twenty one.

And it's basically a list of everything that went wrong related to data storage. And a lot of these really could have been identified by a misconfiguration scanner. Then you have some of the issues are really were really Trivyl. So you can you have, for example, no password protection or any kind security protecting the database was set up and that exposed over four hundred forty million records.

That's a lot. Right? And that's something that you you might think it's really easy to identify that, or it's really stupid for somebody not to set something up like that, but given how extensive this table s, if you actually look at it, on GitHub, it happens quite often to different companies. And, generally, within misconfigurations, they can have two different results that you really want to prevent.

The first one is that you misconfigure something in your application and how your application is supposed to run. This can lead to an incident. So your application not being accessible for your customers. That's something you generally want to avoid.

Right? It can have a business impact, but it happens to all organizations at some point that, something goes wrong and a part of your services is maybe not accessible. The way that it should be. Now the other type of misconfiguration relates to information being exposed that should not be accessible to certain people or publicly in that in that case.

Note in the case of misconfiguration, it relates to security information if that comes out, right, if people identify that your customer data has been publicly accessible or other security issues that could have been easily mitigate it.

If that comes out, that's a lot more, a lot more for your business, and the business impact is a lot higher because just generally will stick with people a lot more that something went wrong related to security of the application stack.

Now the third type of scanner we have in Trivy is the exposed secret scanner and basically is part of all of the different Trivy scans that you can run, but that's your container image, that you're scanning, or you scan your configuration files, it will try to identify if there are any exposed secrets. So in this case, in this postgres image, there is a private key stored within the container image, and that should be the case. Now you can also use trevor to scan your own resources, obviously, if there are any, any data that shouldn't be within that resource that might be pushed to then external registries.

The last scanner is the license scanner. So the license scan is generally used for companies to identify which licenses are used within a different libraries that you're making use of So different organizations will have different requirements on the on the licenses that they can use versus that they can't use.

This CNCF has, for example, for all of the projects we're gonna CNCF some strict guidelines on which licenses they can use versus not.

And, yeah, that leads us to, to Triley. This is Triley.

The four different scanners.

If you're completing a YouTube TV, It's an open source all in one cloud native security scanner.

I generally only work with our open source tool at aqua security we have just reached actually twenty thousand stars for Trivy, which is a huge milestone and just resembles, the adoption that we have achieved with this tool.

And just how large the community has become. Now Trivy is used under the hood, to power Akra enterprise to power the platform.

And you can imagine it similar to how other open source project are used by enterprise tools, under the hood to ultimately provide an offering around. You know, at the moment, we don't have, like, a clear onboarding path of this is Trivyl, and then to unlock x rays at additional features, you move to Apple enterprise. It's really truly is kind of the the engine within aqua security to to power the enterprise security scanning as well. Now with Trevi, the Openzer's tool is really focused on security scanning, the main goal of Trevie is to produce scan reports. It's not focused on managing those scan reports or helping you to set up, Trivy in your different environments. That's that's not a focus of tribute. Tribie's main goal is security scanning.

Now I mentioned that it's a all in one cloud native security scanner as part of this cloud need to focus that we have. We have a tricky operator.

If you're familiar with Manidis resources, the Trivyew operator is a Cuban native operator you install and manage it as you would with any other Cuban news operator in your Cuban News cluster. No. You don't have to make use of containers or cloud native environments if you want to use Trivy. We just generally say that if that's the kind of company, the kind of environment you're operating in, you can get more out of truly because you can use the same scanner for all of your different scanning needs versus you could also just use Trivy, to scan your file system, to scan maybe external, third party resources before you use them. You don't have to use Trivy also in your QB cluster in similar environments.

Now we have, as of now, over twenty five different integrations, twenty five different integrations are listed on our ecosystem page and our to be documentation.

Now these are just the the integrations that we know of. There are probably a lot more integrations developed by the community that we just haven't listed or nobody has edit to the, GitHub list yet.

But it's just another indication of how much more TreV is as a security scanner and how much it has reached an adoption. Now if you're using Treving, we would highly appreciate if you could also give us a star on GitHub as we move towards the thirty thousand stars. That would be really exciting.

Now some of the other benefits of Trivy and also in some of the ways that different security scanners defer from each other first thing it's installation options. Obviously, your environment, your setup might be slightly different to how other whenever company sets up their environment or the operating systems they use, or the infrastructure resources they make use of. So it's really important that if you're using security scanner also across different teams, then you can install it, in your different environment environments. And have different installation options available.

Then the other thing is, as mentioned, we have a strong focus on installing TriV in your Kubernetes cluster, but also using TriV the CLI tool to scan your Kubernetes cluster and cloud native workloads.

The other thing for TriV is the scan coverage. We have a vast list of operating systems and, languages, programming languages that truly can scan.

And access basically access information on to provide you with a list of security issues.

And the last thing I didn't mention is the target audience or I mentioned a little bit.

So Trivy is, again, it's folk it doesn't have a specific, focus group on the ideal user.

Basically, whether you are a security professional and you want to run compliance scanning on your infrastructure resources or you were a hobby engineer and you want to use Trivy to make sure you're not, accidentally, providing your NPM private key on your GitHub repository, you can use Trivy. I actually have I presented Trivy just a few months ago at conference that was more focused on front end programming and front end related frameworks and languages, and I showcase training. And after I have I've shown Trivy and the the security scanning. Somebody came up to me and told me about exactly that use case that one of their private keys was for several months, actually in their public github repository and could have helped them to use security scans such as Trebby to identify these.

Yeah, to identify any exposed secrets in that case. So here's a quote by wise engineering on why they have chosen Trivy.

It's in their blog post, so you can read up on that later on as well. Now, their blog post is not focused solely on Trivy and they are set up off Trivy but just in general how they have, basically advanced their security platform within wise and engineering teams. So they say Trivy has all the characters that we need, it's well supported, maintained and has capabilities to scan containers for operating system based vulnerabilities. This will increase our visibility and package updates on libraries for the application binding in containers.

So the goal for vice one day, we did their security scanning with India. With their in their application and different teams was that they want to get insights into the different vulnerabilities that are present in their different resources that they're using but they wanted to be able to make the scan results specific to the different teams. So really relevant to the different teams at low level. So different teams can really dig into the vulnerabilities that their resources are affected.

Right? And then they also wanted to have a way to aggregate to schedule results to see over time. Okay. How does our security posture of our services, of our organization as a whole change over time?

So that leads us to strategies for actually implementing security scanning. What would we recommend able to do or what, basically do these organizations that I've just highlighted, how did they go about it? What kind of questions that they answer in those blog posts, to get started with security scanning and implement security scanning effectively.

The first one is that you really want to get an idea of the resources that you have currently installed in your different environments that you make use of, the different teams in your organization make use of. Ideally what you want to do is that different teams can use the same security scanner or the same tooling.

So it's if people have to, for example, move between teams, they don't have to learn a completely new tool.

You also kind of prevent you want to prevent the the risk that one person is the main go to person for a specific tool. Right? Because if that person needs the company, then you could be stuck in a knowledge gap So these are things that you want to avoid.

Ultimately map your existing resources, and these are all of the different resources across your software supply chain. What are you currently using? What can you scan? What of the resources can you not scan at the moment? Because they might not be enough format that make them, that makes it easy to scan them. Right?

So again, if you have configuration files or generally if you have configuration files such as terraform, home charts, humanitas, manifests, or similarly makes it far more easy to scan them versus if you use, self serving developer platforms.

Just one example.

So I've met the different resources and answer questions such as what are you currently using? Where do these resources come from who are the third party providers when you use the resources from. That's really important because you ultimately want to ensure that you're only using resources by trusted entities, by trusted parties whom you know that, they have incentive to, to provide you with the right yeah, with secure resources and update also the application stack and the resources they provide you with.

Then you also want to ensure that, you know, where are your resources stored? How are they stored? How are they updated over time? Who's using them and who's updating them over time? If you know when different resources are updated, then you can then you have it easier to, implement security scanning at that point in time. So these are not becoming different processes of updating, the resource and then updating the resource for security patches.

You also want to map the different dependencies between resources if one dependency affects another. Right? If there's, for example, a vulnerability, in one part of your application stack that then is then used and implemented in another part, it will just carry on forward. Right? So if you have an idea of the different dependencies, between your different resources, you get can get easy an idea of, where should you implement the security scanning and fixing those security issues.

The next thing is, talk to your stakeholders, talk to anybody who will have an interest in the security scanner. Right?

A lot of these blog posts that are highlighted, the people share or the author or the people contributed to the to the blog post share how they really needed to have cross team collaboration and communication in place to make the integration with the security scanner most effective. If you don't know how different tools, or different teams are currently using their tools and upgrading their their resources in response to security issues, then you will have it difficult to implement a solution for different teams across your organization.

So you ultimately want to identify who will be responsible to perform the scam.

And which resources should base scan. So what a lot of people do is that the person who's modifying the resources, for example, or is responsible for certain then also responsible to scan it. Now in the case of voice engineering, I spoke with one of the engineers at a conference, a few weeks ago, before Christmas. And, they told me that they have a security team who's performing the scan, and then the scans of the different resources are provided to the teams who are actually managing the resources. So that's the relation that they have in place. So you want to figure out for you and your company who will ultimately perform a scam and who is then responsible to take a look at a scan and also update your resources based on the security issues that you have seen that you presented with.

The other thing is how often are you supposed to run a scan? Versus it's supposed to run, when is it supposed to run?

This is different if you're, for example, expecting people to use security scanning locally on their local machines, as they change resources or if you implement security scanning in your CSCD pipelines in a more automated way whenever resources are changed or if you implementing continuous security scanning in your infrastructure, for example, in your Kubernetes cluster. It will be different at each stage. You also want to take a look again at what tools are you already using, and this is different to what I mentioned before. You want to have an idea of the tools that you're using to scan them.

And then you want to have an idea of the tools that you are using to implement security scanning within. So for example, I love using prometheus and grafana as my observability, as part of my observability stack within my Q Minis cluster, and I can implement and integrate the Trivyl operator with those with my observability infrastructure really easily and then, see the scan results in Prometheus and in Refana.

I will show it to you in a second when I when I move on to the demo.

But that's just one example on how I'm integrating the security scanner within my existing resources.

And then you also want to again talk to people what outcomes are ultimately important to them and to the individual teams. What needs to happen or how does the security scanner have to look like to make it work for them?

Then once you have an idea of all of this, and again, at up to this point, you might have played around with some security scanners and you have an idea. What's available out there? You might have chosen one or and settled for Trivy or, or got an idea of which other scanners are available.

But to this point, you don't necessarily have built an extensive solution yet. Now that leads us to our proof of concept. You want to ultimately integrate the security scanner that you've chosen, any existing workflow and start there really with the easy wins. So don't implement the security scanner everywhere that you want to implement it in a long term, but just that small and see how it, for example, the security scanner works out in one workflow and one of your CACD pipelines before you integrate it in all of your different CACD pipelines.

Now you want to also mimic as part of this simple integration, how it's supposed to be used, how the security scan is supposed to run-in the long term So you can then talk to, different stakeholders, who might not have used the security scanner up to that point. And see, comfortable using the security scanner as its intended to be used. Not as they would want to use it, but as you, the person who's setting everything up, intends it to be used. Because ultimately if they don't feel comfortable using it, if they don't if they feel like they have to adapt their current workflows too much, or if it's just becoming another chore for them to deal with, They might not actually use whatever solution you provide them with.

And then you also really want to identify and define ownership levels ultimately, we talk a lot in this industry in the space about shifting left and, obviously doing something like security scanning as early as possible in our develop a life sack. Right? And that's great. The issue is that a lot of times, as part of shifting left, we ask engineers to do a lot more work than what they've signed up to do or what they have time to do. And as I mentioned before, when we talk about incidents, to make our application run and work and for users to access it, we don't need security scanning to be implemented or we don't need to patch security issues.

So a lot of times security is getting instant just an afterthought because it's not needed to make our customers happy. Right?

However, when it goes above the line to the point where we have, security critical issues that need to be fixed that resolve result in incidents where actually customers have to be notified about the breach or what has happened, then that's ultimately too late when when security scanning should have happened before, but didn't because nobody felt the needs of actually making work and taking care of it.

And then the last thing is once you have installed the security scanner in one specific environment, it's one one specific way, let's say, you can iterate, from there and expand your use of the security scanner. Now keep in mind if something is not working for one team, don't make them continue with the setup or, trying to make the security scanner work for them, in the way that you intend to because ultimately, it's probably got just gonna lead to more frustration and fewer people looking at the scan result, especially if it's not very interesting to be to look at. So something else that wise engineering, for example, put a focus on, they want they integrated the security scanner, in that case, Trivy, with their existing monitoring solutions, and that included, open source, but also proprietary solutions But he said, okay.

We have these existing dashboards. We want people to see the scan results in a visual way. And having these dashboards of the different security issues just make the scan results an entire process of security scanning and fixing security for more exciting because then you can or actually see the impact that you have if you fix security issues. Like, you see vulnerabilities going from, I don't know, hundreds to zero or something like that.

So the other thing is that while technical integration, or for example, integrating security screening will always be very similar. So whenever I talk to people on how to set up Trevie, how to make the best use of Trivy, it's always gonna be someone less strategy. However, the way that security scanning is integrated in existing processes, and your workflows, and provide two different teams. Also, especially teams who don't have a strong security background. Right? Will always be different between different organizations.

So let's go ahead and just give a give a live demo on how you can get started implementing vulnerability scanning and security scanning overall.

Can you see my terminal? I hope you can see my terminal.

Are people still there?

Caros, are you still there? Am I alone?

No.

Yeah. Maybe. Okay. Okay. I might be my myself. That's cool.

Okay. We have here our example application or an example, application set up or somebody raised their hand. If you have any questions, post them in the q and a or in the the b naught chat, and I will see them. Happy to answer questions, especially now during the live demo.

Then, yeah, just interrupt me with questions, and I will go ahead and answer them. This one question by one. Thank you, Ron, for for posting it. Could you say a few word or two about road map of Trivy development? For example, Serv integration for license scanning, in GitHub.

Yeah, when I get to GitHub, I will I will address that. It's part of my demo. It's a good question.

Cool.

Okay. So just for people who haven't used Trivy before, there are different ways that you can use Trivy.

So generally as part of Ruby, you have lots of different commands.

So for example, AWS, just getting your AWS services, config is a shortcut for misconfiguration scanning. The power system is to scan your local power system, the to the image command to scan any container images, then Trivy Kubernetes is to scan your Kubernetes cluster, for example, and then you can also scan remote repository your root file system, and SBOMs for vulnerabilities as well as virtual machines.

So these are the the scan targets we refer to them in three d. So I have here this example application and I hope you can see that even though I have here this annoying bar. Let me just move that.

And I want to scan my local application.

So for example, after I made changes to it, for any security issues. And I do that with the TriV file system command, so TriVFS, and then it just provides the path to the file system that I want to scan for vulnerabilities. Now this is a, TypeScript slash JavaScript application.

And it will basically use my package manager, sign PM in that case, and the library that it can find within.

To scan those vulnerabilities. Now this is the information I'm provided with. I think there's a question about the database. Are you half now you're using the database information about Cves are the updated things. So you can see here it's downloading the database.

Now this is because I've I think I've cleared the cache earlier from Trevi where it stores all the database information And so it needs to re access no not the database. Now generally, the database on vulnerabilities is updated every six hours by default.

You can increase that. You can, for example, specify a flag that says, Hey, please as part of this can also update the database. So as part of every again, you can also update the date the database. That's completely, feasible. You can also, specify Trivy to run-in a client server mode environment so you can specify where the database is supposed to be stored and how Trivy that's supposed to perform the security scanning is supposed to access that database.

Now this is the information on vulnerabilities.

And that's within the Trivyl CLI. Now the Trivy operator, works similar. It uses a Trivy operator in your communities, Tessa uses Trivy under the hood, and I will show you that in a second as well. And it also updates the database by default every six hours.

Yeah. I hope that answers that's that's the information you were looking for. And that basically includes, information from the national vulnerability database as well as vendor specific information.

Now as part of our first system scans, it will perform generally scan on any exposed secrets in my file system as well as a vulnerability scan.

Now, I can specify as part of the file system scan. I could also specify that I want to just, do a misconfiguration scan. So I can say scatters and then misconve and specify that I want to, for example, scan my Docker file for any misconfiguration issues.

That are present. So in this case, there's one high misconfiguration issue, present, but I could also use the command to scan, for example, a directory that contains all of my different configuration files. So you don't have to perform, for each resource type a different scan. It just has to be, for example, vulnerability scan roosts, a misconfiguration scan.

Now As part of my file system scan, I could also say I actually as part of my file system scan, I only want to see high vulnerability issues. As I've shown you earlier in a screenshot, so you can specify that you want to see as part of the severity, you only want to see high and critical issues Oh, spelling would help.

And then your only shown really the high vulnerability that you can already fix, that there's already a fix available.

And then again here in the actual vulnerability you can also find more information on how your system might be affected.

Now I've already built a container image that's part of my, Docker help ID, Docker help account, and it's version zero point two point two.

Or actually one. Let's start there.

And I can scan the container image that I built based on the stalker file that I have here in my local repository, I can scan that for vulnerabilities. So basically once I've packaged it out, And as you can see, the different vulnerabilities in my container image, then there are in my file system. So if I run it through the file system command again, just for comparison, there are different vulnerabilities in here than are in the container image. In an image, even indication. Right? But basically as part of the Trivyl security scan of your container image, it will also scan any operating system that you're using as, for example, the base container image. So in this case, I've used here as part of my Docker file.

Actually, for this image, I used, the this note based image, and this has these additional vulnerabilities within.

Now I've then went ahead and I've updated this space image and I updated it to a new version and built a new container image which is zero point two point two, with my updated information. And if I scan that now for vulnerabilities, it doesn't have the additional vulnerabilities in open SSL in that, note base image that I have been using. So basically before I used a different, note Alpine container image as my base image and that had a dish vulnerabilities that I was basically adding to the container image. So this is just to highlight that you have certain vulnerabilities within your file system.

So these are, for example, the vulnerabilities I have in my case in my file system in my application.

But then you add additional security issues when you misconfigure For example, your, where is it? Your Docker file, as you misconfigure that, there are misconfiguration issues and then as part of the base image that you choose in your Docker file, you can introduce new vulnerabilities within that. So at each stage, you want to identify any potential vulnerabilities that you can exclude that you can fix, that you can do something about.

Now this is obviously all done on my local environment through the Trevisalign. Right?

Now generally you can use Trivy locally as you update different resources or you can set up an integration. For example, we have escote integration where you can run for the also for your local development environment.

And scan and resources within scan, for example, also your file system had also scan from its configuration issues, but generally people then want to integrate Trivy in your CICD pipeline.

That's what we're gonna look next when I find yeah. Okay.

This is the same application. And I have here a Trivy GitHub action and that Trivy GitHub action basically scans, the container image that I've built in my GitHub action CSD pipeline.

So Over here I built and push a new container image and then I scan that for critical high and medium vulnerabilities.

And I produce just a normal Txt file with the output. It's just a normal table for my output similar to what I've seen here. So this is basically the table format. You have different format options, inch VIV.

So one of them is the table format, which is the default format. You can also have chase an output or you can have a serif output. Now the serif output I'm using later on here, in a second scan because I want to have two different reports. I want to have first the normal table format report because I want to create a pull request with that vulnerability, list of vulnerabilities basically from this scan, and then I'm rescanning the same resource But this time, I want to produce a service report.

Now Trevi also has an option where I could, for example, in the CLI, I could convert one format into another format.

I'm not doing that here for demonstration purposes and Trivy action, and I don't think that the Trivy GitHub action has that functionality at the moment to convert between different reports.

So as you can see, sometimes with turbo, you have to run scans multiple times to get your different report formats because every scan will report will produce one single report.

Now it doesn't run entire scan again. It will use the cached information on that, for example, this container image, that has stored and then we use that only if a layer of that container image has changed it will be scanned that layout.

So there was a question on the server of license scanning.

So license scanning and GitHub with the serve information. So, basically, You have I think you're talking about correct me if I'm wrong.

We have here. You see here for everybody else. I'm producing the serif report and I'm doing that because Trivy has an integration with GitHub, with the GitHub security tab where it can upload that scam.

To GitHub, to the security tab. Now right now, there's no way to actually integrate that with the license scanning. So you are asking Ron, I think, when will we have that integration in place?

Just type yes somewhere. Yes. Okay. Awesome. I got that right.

So basically, I don't know when it's on a workbook, I would have to check, have you started a feature request? I would highly recommend you to do that on our, Trivy GitHub discussion.

Oh, so being annoying.

So if you're on a Trivy repository head over to the discussion section and create a new feature request, a new ideas section. Here. Fill that out with your idea of what you want to see.

Now the Trivy GitHub integration is the only one that we officially maintain from aqua security, the others community maintain. So by people who are using, trippy. But if you want to see any updates to this integration, and please do let us know there.

Yeah.

Yeah. Please check that you have created a feature request because that allows us to track these kind of, requests on three d.

Now I've shown you that for the first scan, I created a pull request with the vulnerability list. And this is based on the merge five blog posts that I've shown at the beginning, that they basically said, okay, they want to have for each security scan. They basically want to upload a new file that showcase the security scan to see if there are any new vulnerabilities, they would be added to that file. Now in this case, I'm committing this file for the first time and adding that to my main branch, but basically the next time I run a security scam, if it changes, then I will have a new PR here.

From the, from the GitHub actions pipeline. If it doesn't change, then I won't see a new PR. And this, basically allows you to track, if there are changes, if there are new vulnerabilities, and it allows you in this pull request to make decisions about this vulnerability. Now the issue he really is And it's quite manually to track vulnerabilities over GitHub PR's, right?

But that's kind of a workaround if you're using Trebby.

You can integrate it with tools such as mergeify, with other open source tools, but ultimately you will have to set these things up yourself.

That's kind of what you get, Rich, for Veeam, of a free tool, free and open source.

Other question by one, is there a white couple vulnerabilities of the base image and of my application, other resources without scanning both manually and reducing.

So you are asking basically that I just like to repeat questions just to make sure I understood them. So basically you're asking if there's a way to for me scan this container image that I'm using as my base image, without getting my application workload, but also not no, to decouple it. No. So you want to see which ones are part of the base image versus which ones are part of the, of the main image of basically whatever I'm adding. So that's shown to you. It should be shown to you.

Is it? So in this case, it's telling me that I'm not actually sure if it's shown to you properly.

I think it is because basically if I go into I will show you a different example. So if I go to my, demo.

I have here, yeah, a repository that just basically double different infrastructure files. So some as terraform, then a Docker file in the Docker directory, and then you may need to see my manifest here. And if I scan that with the Trivyl config command, it will show me the misconfigurations which are in each file. For example, it will tell me here in the terraform in this terraform file, it has these misconfigurations versus all of Dismuth configurations are in oh, there are lots.

Are in the community to this manifest. Right? So you can distinguish easily within the misconfiguration scan. So I think I would have to scan a more complex container image, I think, to to see that, but it should be it should be made clear. Otherwise, also create that as a feature request.

Cool.

I think these are all the questions for now. The last thing I wanted to show is, so once you have basically installed three d in your local environments and you have agreed with a new team. Okay. Here's how you should perform the scam. So for example, whenever you set up a new configuration file, whenever you change the docker file, the other configurations, you should perform a scan. You could then enforce also policies. For example, if you change a a docker file if you change your Kubernetes manifest.

In a PR, that PR, you should comment the Trivyl scan or something like that. Right? You could enforce these kind of additional practices within your team to make sure that people are actually performing and scanning.

That's one option to go about it. Now the other option is obviously to have continuous scanning in UCIC pipeline of your different resources as they change. With Treba, you will have to set up the different scanning by yourself. So the misconfiguration scanning, the file system scanning, the container image scanning will have to be included in US E SED pipelines, The other issue is with the SED pipeline so you can specify for Trivy, for example, in the pipeline if it's supposed to fail or not.

There's an exit code that you can specify.

The thing here is that if it doesn't fail, right, and you have additional vulnerabilities, in this container image, people might ignore them. Right? You always have run into run into the risk of people just ignoring the vulnerabilities that they have in their system. So you need a way to, make it again people's responsibility to enforce the people take ownership of these different vulnerabilities to maybe have people responsible for different resources in a compelling monthly basis who has the least number of vulnerabilities in their resources or gamify the system a bit to incentivize people to actually look at the security scans.

The last thing I wanted to show you is that you can also integrate, Trevi in UK. We need cursor. So I have here, one note kind example cluster, and I have the Trivy operator running. Now if installed the Trivy operator through a Helmchart, and it's just basically a part, part has a container, running in my Kubernetes cluster, And that is performing vulnerability scans. So for example, in my demo repository, I have a deployment running, And this deployment has two replicas and it's running in my demo namespace and it's the same container that I've shown you earlier.

So Trivy as soon as Trivy saw in my Kubernetes class that there's a new container it then performed different scans of that new installation of the deployment. It performed this configuration scan of the deployment and also a vulnerability scan. And here's the vulnerability scan of the tag zero point two point one, mining in my, cluster. And as you can see here, four medium vulnerabilities, and two logo vulnerabilities as part of this image.

But as I've shown you, I've updated actually this, the tag. Right? I've updated my container to have a new base image. So I don't have these vulnerabilities anymore.

And now I need to actually find my application. Yeah.

So now I want to update the running application or the container that's running in my application and update to the new tag that I have that doesn't have the vulnerabilities from before.

So I would just do a new cube petal apply.

And Oh, I have to change I'm the wrong application. So let me just change back to my website.

Website.

And here I'm applying the new resources.

That I've just shown you that here. Yeah. Yeah. The service, Email manifest, and then the deployment email first of two replicas, and I'm gonna deployed it to the DMo name space.

Now, q four, deploy name space, demo.

And now it we configured my deployment here on my manifest with my new, tag of the container image zero point two point two. So I should see that now running in my custom. I go back into my custom.

You can see the vulnerability report is gone, the old one. And here's a new vulnerability report with the version zero point two point two. And as you can see, that doesn't have any vulnerabilities. And that's the scan within my custom. Now Trivy will create the vulnerability reports and all of the other reports within your cluster as CRDs, Kubernet is custom research definitions, and that makes it possible for you to manage the vulnerability or like the security reports from the Trivyl operator, like you would manage any other Kubernetes resource. So for example, I export metrics from my applications into, Grefana and Prometheus.

And I want to do the same with the metrics that I collect from the Trivy operator for example on my vulnerability reports. And that's something I can do because Trivy creates them as CRDs.

Now the other thing is you saw the old vulnerability report for zero point two point one being deleted and that's because every report is attached to the resource that it's reporting on. So for example, this vulnerability report is attached to the replica set within the demo name space, this replica set of two, that I've installed at whenever I update the Beverly Gazette, the old report is deleted and the new work port is gonna be attached. So also if you want to store reports long term of Trivy, it's on you and how you export the report out of your custom. But I want to just show you as a last thing, my grafana dashboard.

That you can set up with Trevi.

So in my monitoring space, I have prometheus and grafana running, and I can head over to the services, and, port forward grafana to access it, and then it can head over and just refresh.

The dashboard.

I hope everything is gonna work. So if you go find it running locally, after I port forwarded it from my cluster, So again, this is all a daemon environment. It's all running locally. And I can head over to my dashboards and here I should see my TriV operator dashboard.

And a Trivy operator dashboard shows me a list of just my vulnerabilities, misconfiguration.

Explode secret and Arabic assessment issues as well. So Arabic acceptance basically everything on how you misconfigured, the access control of your different resources.

Now if I dig into, for example, vulnerabilities, I can see the different types of vulnerabilities I have in my cluster And I can also see by name space, for example.

No. Actually, my demo name space, there shouldn't be any vulnerabilities anymore.

So It just refresh in the last five minutes, let's say.

Yeah. So as we can see here, is this short gap shows it really nicely. We had first and online demo namespace six vulnerabilities.

And then, the vulnerability report got deleted by the Tribune operator as we updated the replica set, and now we have zero vulnerabilities.

And then we can just look at our different container images.

That are installed in the vulnerabilities within as well. Now you can totally change and update this dashboard how you like it. Does it just the example dashboard that we provide, for the Trivy operator?

And there's also there's a tutorial that we have as well.

And to review operator documentation.

So on cash, I hope I pronounce your name correct, says I have more than forty microservices running and running Trivy takes time which increases the time for deployment, what should be the solution?

So It depends. Do you mean, running your pipelines and running Trivy in your pipelines takes additional time or running Trivy in your Kubernetes cluster because I presume if you want Trivy in your Kubernetes cluster, you wouldn't update all of the microservices at the same time.

Basically, one issue that some people face, which is justified.

Yeah. Running in prevalence. Let me just finish this part. So something some issue people face is that if they run Trivy in their community disaster, every time there's a new container image, the Trivy operator will create a job, Kubernetes dropped and then scan that container image for vulnerabilities.

Now this job obviously takes resources and it will just spin up perform the scan, and then if the job will be deleted. Right? But that means that if you have hundreds of parts same, hundreds of different container images running a new cluster or different replica sets, then Trivy will create a scan for each of these different container images. So if you spend it on your cluster with hundreds of pods of replica sets, it will take lots of resources at the beginning for Trevi to perform all of these different scans, and that's something that's an issue people have thrown into. So you can set a maximum of, scans that truly can perform at the same time, and then it will, for example, perform it at batch so first ten scans once they are done and we'll perform the next ten scans. And that helps people when they set up the initial cost up. Right?

Now in your CSDD pipeline, you will have to scan each container image individually. Right? So something I would suggest you if you want to use TriV open source, to create, I guess, shorter pipelines and more dedicated pipelines for different purposes that might be one approach of going about it. So, when you change one container image, it will it will trigger the specific pipeline versus scanning all of your resources, all of your container images at once. No, I don't know how the enterprise platform actually goes about it.

Again, with Trevi, you will have to perform separate scan for each resource that you want to scan.

Now you can message me in Slack the accurate security select channel, and then I can follow-up with more information on what other people recommend doing. It's also sometimes worth posting in our, Trivy discussions. Where are they?

Yeah.

In here, sometimes people post, q and a's and other questions and then also community members answer also on Slack. If you have questions like these, like, for example, saying, hi, I have forty microservices and Trivy pics a long time in my publics. How do other people handle that? Right? Lots of times, other people have encountered these issues, and they have better suggestions than I do, what worked for them.

But, yeah, one option would be to have more dedicated pipelines?

Not sure if that's a helpful recommendation right now.

Cool. This is all I wanted to show if there are any other questions happy to answer them.

Otherwise, that's it from my side.

Cara, are you still there?

Don't know if it helps if I speak louder. I don't think so.

No. I'm here. I'm here. It's all good. It's all good. Well, thank you everyone for joining.

Yeah. Great questions. Available for you. Let me stick around another few minutes or ask to stick around for another few minutes in case anybody has another question?

Oh, I've actually not finished quite with the presentation. I just realized.

I can just finish with the presentation. Oh, and now I'm jumped to the end. Let me just go back to the slide that I was at.

Now we went through the different vulnerability scanning and everything. Now I talked a bit about how you can manage different vulnerabilities. Right?

Me just oh, lit it up.

Contact my mouse now. Okay. Here. Cool. So, basically, mergeify point out a real problem and that's also the problem of the forty microservices that in the question that the real problem is identifying a good security scanner, good vulnerability scanner. Trivy is amazing.

But Trivy is just Trivy. Right? The real issue is that you want to have a way to manage vulnerabilities and a vulnerability life cycle. So for example, what I've shown you to create a new PR with your new scan So you see the difference in the vulnerabilities that you have already had in your container image versus new vulnerabilities and that allows you to then, for example, comment, while you don't want to fix certain vulnerabilities.

You need to basically identify a way that you can manage vulnerabilities and ignore certain vulnerabilities and have a reason for that. Right? Like, if your engineers decide they want to ignore certain vulnerabilities because their part of the application is not affected or something, they should be able to provide a reasoning and people should be able to track that over time. So if that engineer leaves and somebody new has to scan that resource for security issues, they can see the reasoning.

One thing is, again, continue scanning, that I've shown you earlier.

And then the other thing is, to create a pull request. That's another option with Twilie.

And then obviously to use different tools. There are lots of different open source tools as well as platforms such as the AWS security hub that allows you some integration with Trivy.

But again, it's on you to set that up since it's an open source tool and make it work for you.

Yeah, keep in mind, today's following, best practices, assign ownership, keep it simple at the beginning. So for example, lots of people start with vulnerability scanning and then go into the different types of scanners, versus implementing all the different scanners at once.

We use the existing tools. The easier it is for people to use their existing workflows and tools. For example, if I'm already extensively using Prometheus and grafana, it makes sense to see the scan results there because I don't have to open a separate dashboard, whereas if you're using already extensively AWS or de facto, then it makes sense to utilize those tools and visualize scans for people. People love to look at visual representations of what's going on.

Even if some engineers don't. Anyway, here's some resources. I'm sure we're scanning we're scanning. We are providing the presentation at the end as well.

Cool. There are more questions. So let me answer these questions.

Yes.

There is also in the resources let me go back. Here is the monitoring repository that basically is used with, the tutorials that we have on Trivy documentation and on a Trivy operator documentation.

But it also shows you the different commands that I used to set up, for example, prometheus and Mifauna. And then there's also the Trivyl demo repository that has lots and lots of different examples on the different since you can do.

So, Harish is asking, Trivy also supports s bombs. Can you share the powerpoint slide Yes. We're gonna share the powerpoint slides. Yes. So Trivy allows you to generate s forms.

So if I go to the documentation, I need a small number. I can't work with it.

So here we have this one of scan targets or s bonds.

So you can, create a new s bond and you can create that you can then scan that aspump for vulnerabilities.

For example, this command would create a new aspump in the s p d chasing format, and then you have that file saved here as an output option, and you would use Trevi to then scan that as for vulnerabilities.

Now, it will show you the same vulnerabilities that you can find in your file system or in your container image at a different layers, The difference is scanning s bombs that were having s bombs in the first place, that the s bomb is just for you to see over time how you application, how you stack evolves in the library resources it uses. The other thing is if you can attach an s form to your container image in a remote registry. And if you perform a normal Trivy container image scanning, Tribble will first check if your container image has an s spot in the registry because that scanning can, can be faster than scanning the container image directly SBOM scanning is usually faster than scanning container images because through the already has a list of vulnerabilities.

I hope that answers the SBOM question.

And have a link to the rep repository with Trivy examples. Yeah. We will provide that. Awesome. Cool. I think this was really the end of the webinar.

If there are no other questions.

Cool.

And again That's great. Thank you, Sunny.

If you are using Twilio in your company, we would love to have you add yourself here to the adopters list. We also have for another fourteen days, our Twenty k celebration going on with a little giveaway. So share with us what you love about Treving, and you have a chance to join us by Thank you everybody.

Bye bye.