Sep 29, 2023

Understanding Vulnerability Management, Supply Chain Security, & SBOMs with Yotam Perkal

TLDR;

Context is key when it comes to Vulnerability Management. Instead of focusing on Vulnerabilities by severity, organizations should evaluate the exploitability and actively exploited vulnerabilities for Prioritization.
When looking at Vulnerabilities do not take CVSS Base score at face value, organizations should understand & utilize Temporal and Environmental elements and the score as well.
From a Supply Chain Security perspective, start with basics like SBOM to help with Visibility and add additional layers like CISA KEV Threat Intel, EPSS Score, Asset Information & SSVC for context and prioritization.

Transcript

Host: Hi everyone, this is Purushottam and thanks for tuning into ScaletoZero podcast. Today's episode is with Yotam Perkel. Yotam currently leads the Vulnerability Research Team at Resilien. Prior to Resilien, he worked at PayPal Security Organization dealing with vulnerability management, threat intelligence, and insider threats. He is also a committee member of the working groups around open source security as well as several CSAG work streams around SBOM and WEX. Yotam, welcome to the show! For our audience who may not be familiar with you and your work, do you want to share about your journey?

Yotam: Yeah, sure. First of all, thanks for having me. It's great to be here. And yeah, you describe it pretty accurately. I actually was fortunate enough to kind of go through various different positions in the industry. I started actually as a software automation engineer doing testing for security-oriented products. And then...

I moved to software engineering and then more to the more data science, machine learning aspect of security and conducting security research. Yeah. And for the last four years, I'm with Resilient, mostly doing security and vulnerability research. Also had like a short stint as leading the cloud engineering team at Resilient.

So doing some more like DevOps work, which was interesting as well. Yeah. But that's basically it.

Host: Lovely so you have experience on both the engineering side, DevOps side and also security so you can see them from both the perspectives right, makes a lot of sense.

Yotam Perkal: Yeah, I think for me, I'm a really strong believer also in, I enjoy it personally also to have like a broad base of knowledge and trying to tinker with all sorts of things. I think at the end of the day, you can pick on more tools in your belt so that when you tackle a problem, then you'll have more ways to go about it. So yeah.

Host: And you also get different perspectives, right? While working on let's say security makes a lot of sense. So I asked this question before we start the podcast for everyone and I get interesting answers also, right? What does a day in your life look like?

Yotam: Exactly. Um, so, uh, it, it varies. I think, um, uh, a lot is focused on the research front. Uh, I, I do a lot of research around, uh, things that are kind of. Related to what our product does. Uh, so a lot of, uh, vulnerability, uh, management, uh, package managers, uh, vulnerability scanners, uh, looking at various gaps of these tools or things that are kind of scanners.

I just gave a talk at B-Sides, Las Vegas, about hidden vulnerabilities in Docker containers. So stuff that are installed, that are deployed, not via the package managers. And because the scanners rely on the package managers in order to identify them, then they're basically blind. They don't see the package exists. And then if that package has vulnerabilities, they don't see it.

So it's a lot of varied work in terms of the research. It's super interesting. And also some of the insights that stem from the research also kind of go back towards the product. If there are interesting gaps or things that the research kind of surfaces, then we make sure that our product is able to identify them and address them.

So that's also another aspect.

Host: Lovely. So what we'll do is when your talk is available, which shows how vulnerability scanners miss. If a package is not listed in the package manager, we'll tag that when we publish the video so that our audience can also get benefit from that.

Yeah, so it sounds like you love vulnerability management. And that's one of the topics we want to talk about, right? So let's dive into it. So the first question that I have is,

as we are all familiar, cyber attacks have affected over 60% of the companies. And all of these start with some sort of vulnerabilities. And it looks like there is a gap in organizations' vulnerability management process, right?

So my question is

When it comes to managing vulnerabilities, where do organizations make mistakes?

Yotam: Um, so I think, yeah, like you said, I don't know if I'd say all attacks, um, start with vulnerabilities because you also have like, you know, social engineering or, you know, uh, fishing, but, but it's definitely one of the, the main vectors, uh, in terms of initial access to the organization is, is definitely constantly, and even I think in the last years it's on the rise, uh, exploiting known vulnerabilities.

So it's definitely a super impactful aspect of security practices. And I think it is challenging, especially if you've done manual triaging of vulnerabilities, you know that it's a very specific...not very rewarding process when you have to go through and validate the output of the scanners and make, and you know, check whether it's applicable in the case of your specific organization, your specific environment.

So it's very challenging. And I think a lot of like, maybe I wouldn't say mistakes, but a lot of organizations simply don't have, there's always like this long tail of organizations that, that are less mature in terms of, you know, they don't have the people or the processes or the technology in place in order for them to be able to cope with the amount of vulnerabilities that they have in an effective manner.

Host: Okay makes it so maturity the right skill set right people those are like some of the mistakes or not even mistakes like those are some of the gaps that happen right.

What are some of the challenges that organizations face? Let's say an organization has the maturity then in are there any challenges that they are facing even though they have let's say the process tools and people.

Yotam: Mm-hmm.

Yeah, so definitely. You know, we see there is a constant rise in the amount of vulnerabilities that are being discovered and published. And it's not really surprising. We are at a point where we rely more on third party software, whether commercial or open source, in order to… to advance the business objectives of organizations. It allows us to run faster, with the rise of DevOps, et cetera. So hardly you see people writing code from scratch. You either import libraries that you use or use, I need a web server, so I'll just use Nginx, which is an open source one. So again, it has advantages. It allows us to move faster, to deploy faster, to focus on.

you know, the core business logic, but it also comes with risk. And one of those risks is in the form of, of known vulnerabilities. And I think as systems get more complex, um, and the amount of code that is being written, uh, keeps rising. So we have more vulnerabilities. And so definitely one of the challenges is, is just being able to cope with this, this sheer volume, um, of vulnerabilities. Yeah. And, and I think also, um,

The old paradigms, the way that we used to do vulnerability management has to change because this gap isn't something that is going to vanish. It will only get worse because we see the trend. So if in the old days you'd say, okay, you need to patch everything, I don't think that's really practical or even smart advice these day and age.

Host: Yes. Right. And so one of the things that you highlighted is the known vulnerabilities, right? And there are so many types of vulnerabilities we hear about. Like it's not like that they were existing. They are now more visible now because of S-bombs and other initiatives. There can be like cloud misconfiguration, zero days, data encryption or like insider threads.

And as you rightly said, an organization cannot just fix all of them because either you cannot just change like thousands of vulnerabilities and fix all of them. And also that doesn't directly help your business priorities. So sometimes you deprioritize the vulnerabilities related work. So let's say I'm a first time security leader. How should I stay on top of all of this?

Yotam: Mm-hmm. So I think you touched on that's a great point because as we gain more visibility with the growing adoption of Espo, which is great, now we know more about what's going on in our environment, we have more visibility, we have more context, which is great, but it's kind of like a double-edged sword because now we know more, we have more things to address, to attend to.

So it's definitely a challenge as you highlighted. And I think in the context of what to start with as a first time, someone who's just starting to gain grasp of everything, which can be overwhelming. So I would say start with the basics. The basics can go a long way. So things like asset inventory, password policies,

Logging, having logging in place, monitoring in place, just to have visibility into what you have, it's a super important aspect, I think. And I think also, if you need to invest in something when you start off, I think you should invest in automation. Because when you have automation in place, it allows you to reduce the total manual work that you need to take. In order to address different security challenges. So that's what I would recommend.

Host: Okay, and one of the things that you rightly highlighted is that nowadays we don't write things from scratch a lot, right? We see if there is an open source version, then we start adopting it. Maybe we do due diligence or sometimes we miss to do the due diligence or as you highlighted right I need a web server there is nginx maybe I'll just use that right away. So

As part of that, we often get inundated with so many vulnerabilities, right? The share volume is high. How should security leaders ensure that they are focusing on the right and the highest priority vulnerabilities?

Yotam: Mm-hmm. Mm-hmm. So again, I think that that's a really good question, because that's the challenge. That's really the challenge. We need some kind of crystal ball that will let us know what we need to focus on. And I think in that aspect, the key is context. So we need to have as much context available for us as possible in order for us to be in a more intelligent way that is optimized toward reducing the risk.

So we need to focus on the vulnerabilities that matter most. And then the question is, OK, so where do I get this context? So I think there are two main sources, I would say, if I can divide it like to two. And I think they're both equally important. So you have internal context, which comes from the context of the context.

things like asset criticality, business context, or things like specific configuration, like environmental characteristics of your environment. And then you have external context, which is like exploitability. Can the vulnerability be exploited? Is it actually being exploited in the wild?

And if not, what's like the probability of exploitation of it to be exploited. So this is where things like UPSS comes in, which I think we'll probably discuss later on. So, and I think, so the more context you have, then you are able to make sure that you, you make the right decisions and, and you, you focus on what matters most in terms of, of risk reduction. And then once you have that context, then all you need to do is not that it's just simple and unfortunately most organizations aren't at that point yet.

But what you should be doing is have some kind of process in place in order to take that context and make it actionable. So this is where things like SSVC, which we'll also hopefully discuss later, comes into play, which you have like this decision process that you can make based on that context.

And then you know, okay, these are the things that I deal with. And these are the things that I deal with if I have time. And these are the things that I currently leave aside. So that's kind of the way I see it.

Host: And that makes a lot of sense, right? It should not be that you are just going through criticals first, high, second and then you continue rather add the context to it so that you can do better prioritization of the vulnerability. Makes sense. One of the things you highlighted earlier like the basics when it comes to doing the basics is asset inventory, right?

And one of the aspects of vulnerability program is that recent rise of adoption of like the open source software, it has become more challenging now, especially like recently we heard about the supply chain security attacks on SolarWinds, Twilio, PiPi, OpenSSL and many more. So we received this question from a first time security leader,

How to design the vulnerability management program so that we can tackle the challenges with supply chain security.

Yotam: Um, so I think, uh, in that context, I think it's often, uh, kind of tempting to try and look at supply chain risk in the same lens that, that we look at, at vulnerabilities. But but often, you know, that that's not really the case. It's kind of two different problems that are related. They have a lot of common aspects. And I think a lot of, of the ways that we try to deal with vulnerabilities can apply to them. For example,

SBOM can provide value growth in terms of vulnerability management, incident response, as well as in the context of supply chain risk. But I think it is a different, more complex problem. And I think there is still, the way I see it, there is still a gap in terms of the mindset in the industry, in the different tooling and package repositories, in how they approach it. And I'll give an example. So.

So for example, now when you have like a malicious package or discovered that is pushed or like there's a thousand packages, malicious being pushed to IP or NPM or whatever. So the way it's currently being handled is the packages are being removed, which is kind of makes sense, you know? Okay, we don't want any more people to download it. But what about like the evidence? Like how do we know that the same person behind those thousand package won't deploy?

like push another thousand the next day. So when we simply remove it and don't keep any of the context, then it's harder to look at it from a higher level and kind of see the pattern, see the trends, look at it from an attacker perspective. And it's not like there's one of my colleagues from Checkmarks, a company that deals with this problem, he says, we're not facing a malicious package problem. We are looking at malicious.

You know, attackers, we need to identify the attackers, the patterns, the trends. So I think that is something that conceptually, I hope will change over time. I think OSV, which is an effort that again, there is like a group of security researchers and from different companies in Israel that we, there was like this forum that we created, SCAR, when we try to tackle problems that are more like vendor agnostic and the industry level.

And so a lot of the work is talking with folks from, from those kind of, that are in this intersection and trying to convey this message. And I think one of the positive things that I see is, um, OSV recently added support in their schema for, uh, this kind of context. So, okay.

The malicious package, what is the method of injection? Is it compromising of the pipeline? Is it this specific version? Is it the rogue developer that pushed malicious code? What does the code do? Is it a crypto mining? Is it expert trading data? All these sort of things that are up until now weren't really recorded or documented in a, at least in a way that is approachable and can help.

doing more security research and moving to a point where we're more proactive and less reactive.

Host: Okay, nice. So one of the things that stood out, what you said, and sometimes is confusing is that focusing supply chain is equal to vulnerability management, but it helps that these are not exactly the same. Of course, there is overlap, but it is not the same.

And the OSP that you talked about, what we'll do is when we publish the video, we'll also tag so that our audience can go there and learn what's going on with that world right OSV and how is it at a context, how is it helping with the supply chain security.

So a follow up question to that is, let's say I understand what's the difference between both of them. Is there a framework that I can follow to make sure that my supply chain security is taken care of?

Yotam: Mm-hmm. So I think there are a couple of interesting initiatives in that direction. I will say that I don't think it's a problem that one standard or one tool or one framework or one vendor will solve. It's a complex problem. And I think we need industry-wide collaboration to tackle it effectively. But there are definitely some interesting initiatives that try to help address it.

Some things that come to mind that I'll highlight is SLSA, which is like the supply level. Basically, you can look at it as a maturity level of the repository in terms of how they are, the security practices that they apply. And you can get to the various, the higher SLSA level you are, the more.

Robust and reliable, we'd say the practices. So there's the OpenSF scorecard, for example, that tries to give various, there are different checks for again, like the maturity of the repository are there being code reviewed before code is in merchant to the main branch, various kind of security best practices. And then it...

Based on all these checks, it gives a total score that is supposed to help you if you want a specific functionality. You find two packages, and then you're debating between them. And then it can help you make a decision that choose a more mature, more security-aware kind of project. And it also aims to help drive the maintainers to up their scorecard scores so that users will trust them more. So a lot of things like that.

Host: It's a sort of win-win for both, right, both for the maintainers that their sort of profile is getting like they're getting better scores and also the folks who are adopting they also see and they also adopt based on that score as well.

Yotam: Yeah, exactly. Uh, and I think one, uh, we, uh, another research that we recently conducted was utilizing this open step scorecard and looking, for example, you see this, uh, this trend now with generative AI and NLMs.

And we kind of showed that projects that became super popular in, on GitHub, like tens of thousands of stars in a matter of days or weeks, their security practices aren't there yet. So their, their scorecards scores are really low and people often don't even.

I wouldn't say don't address it at all, but maybe don't address it enough or take it as part of the decision process in terms of which project to use. And I think it's important to raise awareness to that. So that's also something that research that maybe we can link in. And I think it's interesting. And also, so there are additional like more like frameworks.

There's a something called the Open Software Supply Chain Attack Reference, which is OSCAR, kind of like the Mitra ATT&CK for supply chain risk. So kind of mapping out the different avenues in which supply chain risk can occur and what stages, et cetera. So it's also something that I think is worth knowing. And the Secure Supply Chain Consumption Framework, which is also

So there are various projects. I think still, the more we'll see, and we're starting to see more sophisticated attacks from that supply chain, then it will get more industry and security research focus, and hopefully there will be a more higher level view of the problem, and we'll see more solutions.

Host: Makes sense. One of the things that you highlighted earlier is again, like S-Worm, we use open source more nowadays. So S-Worms are sort of becoming a key building block when it comes to building software and supply chain risk management.

But can you help us understand why would organization need a software buildup materials in the first place?

Yotam: Mm-hmm. Um, so I think, um, the, the main, the main, uh, there are a lot of different like use cases for us, for us, but I think ultimately the way I see it, it provides, um, visibility and transparency. And also it allows, uh, software consumers to, to demand that transparency from, uh, the vendors that provide them their, the software, um,

And I think it's also like the way I see it, it's kind of like a vehicle for context. So you have this kind of base layer, this building block, which is machine readable. Currently, it's more discussed in the context of dependencies and licensing. But once you have that, then you can layer in additional context.

on top of that and then you can use that context to make decisions in a way that you can automate and action on in a way that is scalable. So for example, let's take the VEX, which is vulnerability, expert ability. Basically it's something that you can.. tie into your SBOM or it can be independent of the SBOM.

And it lets you know whether a vulnerability is actually exploitable in the context of, let's say, a specific product or in the context of a specific environment. And then once you have the SBOM and you can layer in that information, then again, you have more context in terms of what you need to focus on.

But I will say, like I said, it's not like a silver bullet. It's more the way I see it. It's a building block. It's super important to have, to standardize. But then once you have that, then it gets interesting and you can, more use cases will surface over time.

Host: Mm-hmm. So it's a way of discovering the dependencies and then the things which were not earlier visible even now, you can see. So it helps you build the context. Now, let's say you ask all your vendors to give the S-form data. You have the S-form data. What are the challenges of sort of not collecting, like interpreting that data that organizations face, and how can they overcome those challenges?

Yotam: So I think, so S-bombs are getting into a point that they're now more common, like most people have heard of S-bomb in some way or another and more people are starting to utilize it.

And I think a lot of more people are appreciative of the value, like the potential value that they can provide. But as you mentioned, there are still some challenges. I think one of the main challenges is again, it's like a chicken and egg thing.

So you need adoption for it to be more valuable and applicable. So one is driving adoption. And I think we also need to kind of lower the barrier of entry that is required to produce S-bombs. And again, push more vendors to provide them, which is also will come from pressure from the consumer. And there is also some regulatory pressure.

That we see that kind of starts to mandate these things. But I think ultimately the main value, like the main driver will be from the value that they can provide. Because I really believe that it can solve a lot of problems. It can help solve, it won't solve. But, and then there are like additional problems that I think as it will mature and gain more adoption, things that we consider like big issues now will… seem less of an issue.

Like for example, I often hear claims about, you know, the trust issue. How can I trust the S-BOM data? So first of all, have something, even if you can't trust it, at least you know what you have at certain level of credibility. So I think something is better than nothing. And these are things that need to happen gradually. So.

So that's one, or the quality aspect. So how, again, how can I know that the SBOM is in good quality? And I think once, for example, if a vendor gives you an SBOM, then you don't have to immediately trust it and accept it as the ground truth. If you have a tool in your environment that can generate the same SBOM based on the runtime or the code. The build process and your tool tells you something that the vendor didn't tell you, then you can confront the vendor and tell them, okay, you said that this is what you have in the environment, but my tool says that this is what you have. So again, these are problems that as more maturity and track record and more tooling will evolve, I think that it's less of a problem than often people make it to me.

Host: Makes a lot of sense and you're right that it helps you with the visibility. Now you know what is the surface area which you were even not familiar with earlier. It helps you build trust with your vendors because now they are sharing their S-BOMs and if you need to validate you can validate as well. And so you are at a better position in terms of understanding different attack vectors even coming through the vendors. So yeah, that's it.

Yotam:Yeah, I think if an example that I like to give in that context is let's take vulnerability scanners. So we all agree that there are super important, super valuable aspect of our security process. But, you know, we live with false positives, false negatives of vulnerability scanners all day long and no one raises an eyebrow. So, and they still provide an immense amount of value, but they have, they're not, I wouldn't say I trust the scanner output at face value.

So again, I think it's that we need some proportion and something is better than nothing. And again, over time, these things that are like big, like arguments against maybe adopting NS1 will start to hear less and less.

Host: Mm-hmm. Yeah, hopefully the adoption like as you said, it's a chicken and egg problem. So hopefully things get better sooner than later. One of the things we earlier spoke about is the prioritization, right? Like if there is a shared volume of vulnerabilities, how do I prioritize? One of the things folks look at is the vulnerability score. And there are multiple frameworks to do that like CVSS, EPSSS, SSVC.

And in fact, CVSS released a new scoring system, like version 4.0 a few weeks ago. And EPSS had something similar. They released 3.0. So how do they differ from each other? Can you give me at a high level, how do they differ? And what's the effectiveness of these frameworks in the vulnerability management programs?

Yotam: Sure, yeah. So again, this is my opinion. I also recently gave a talk about that specific topic in the last, besides Las Vegas.

But I think it's a really important point to discuss. So let's start with CVSS, which is basically kind of like the de facto standard for kind of scoring, assessing vulnerabilities.

And as you said, version 4 just recently started to roll out, which I think is good. It aims to address a lot of the issues that former versions of CVSS already had, like the granularity to be able to have a more granular score. So the differentiated, there are tens of thousands of vulnerabilities with a 9.8 CVSS score.

What's more severe, like it's not entirely sure. And recently we had a bunch of those that are published that the maintainers say that they shouldn't even be a vulnerabilities, let alone a 9.8 severity score of vulnerability like in Postgres and Curl. But so put that aside, but I do think that they're doing a good job. I think one of the problems with CVSS is not CVSS as a system. And I think

it again, it provides a lot of value. Um, but I think the way that people use it isn't, isn't the way that it's meant to be used. So for example, like the CVSS three score, even it comprised of three, like different aspects. So you have the base score, the temporal score and the environmental score. And what you see on NVD is just the CVSS base score. And, uh,

The creators of CVSS, the maintainers, the folks from the SIG, they specifically highlight the fact that you shouldn't use CVSS based as your sole, like for vulnerability polarization. But as consumer organizations, they see this is the score that they get from NVDA and they don't do this additional enrichment with temporal environmental context. And then… they use it for prioritization, which it wasn't designed to do. It's a metric for severity of the vulnerability, but it doesn't take into account, again, like is there an exploit available? What's the likelihood of exploitation? What's the likelihood of exploitation in the context of my environment, etc? So that, I think, is a main problem with the way that people use currently UC of CVSS.

So I think there's also educational aspects to do there. And then you have additional, I think, EPSS really shows high potential in terms of adding an additional signal for prioritization. So like,

So like regarding, if I go back to CVSS, so we said, okay, it's not really a reflection of risk. It's also like not really scalable because if you look at NBD, 57% of the vulnerabilities that have CVSS-3 score are vulnerabilities that are high and critical vulnerabilities. So even if you say, you know, like, fix or focus only on the highs and the crits, you're still left with too much vulnerabilities, far less, far more than you can handle. So most organizations… usually are able to address like 10% of their vulnerability backup. And other than that, a lot of those vulnerabilities that are high-end and criticals, they won't ever be exploited.

Because less than 5% of vulnerabilities will actually be exploited. And even a fraction of those are exploitable in the context of your environment. So I think this is where EPSS comes in, because it allows you to get that visibility into this aspect of exploitability.

So EPSS or things like Thread Intelligent Feeds like Cisa, Kevin and others, allows you to take into account that aspect of exploitability, which again is a really strong signal for prioritization simply because of the fact that the majority of vulnerabilities are not ever exploited. So that's like.

Host: Yeah, yeah. And that goes back to what you were saying earlier, right? There is that sheer volume which sometimes gets overwhelming and as you said, like there are 57,000 critical and high, you cannot fix them. And by the time you fix few, there would be few more which are discovered. So it becomes a challenge. So that brings me to the question. Let's say I'm a startup growing, I'm running a growing startup in either health tech or What process should I follow?

Yotam: OK, so that's, again, it's a great question. And I think like the earlier question about as a startup or a leader is just starting out, we should start with the basics, like we did before. So the basics in the context of vulnerability management, the way I see them, are visibility. So make sure that you know what you have, that you have an SBOM.

Whether there are enough open source tools that can provide you with an S-bomb like SIFT, like dependency track, which is an OS project. So it doesn't necessarily have to be a commercial product. Obviously, commercial products have their benefits. And I work at one of commercial products that offers those benefits. But again, it doesn't have to be straight off the bat, something commercial.

There are a lot of open source solutions and tools that can get you that visibility. And once you have that, then start layering that like additional context. So as I mentioned before, there are a lot of different feeds like CISAC or EPSS, which are, you know, they're freely available. You can consume them. You can enrich your vulnerability data. A lot of the, like the commercial tools already it's what I'm glad to see is it's becoming table stakes.

If you say, see, things like that, in the past, they weren't there, that we just had CVSS or like proprietary scores from different vendors. We're starting to see that becoming table stake, which is great, but you can also consume it by yourself. It's freely available, accessible online. And so layer in that context. So if you have that asset inventory,

So layer that in as well and map your critical assets. And then you can take all that context. And again, it can be a gradual process. So if you don't have asset inventories, then that's OK. So then just use the CVSS. You can use, for example, the vector and focus on vulnerabilities that are exploitable via the network or on network-facing assets if you have that.

But if not, then use the EPSS and CSECEP and things of that nature. And then you have the SSVC, which is again, another great resource, which is the Stakeholder-Specific Vulnerability Categorization, which is... I would sum it up like simply as basically a decision tree that you take this information and you form a decision process around it. So it allows you to both...

communicate internally or externally to auditors or whatever, this is how we prioritize vulnerabilities at the moment. So for example, is the vulnerability, if you have a tool like Resilient that can tell you if something is loaded or accessible, like reachability analysis, then fine, you can use that. If you don't have that, then you can say, okay, if the vulnerability is likely to be exploited, then it goes here. If not, like basically the assessor, so you can tailor it based on the level of context, the amount of information you have, and also based on your capacity.

So you can kind of build a tree in a way that the bottom layer will give you the top 10% if you know you can only handle 10% of vulnerabilities in a given month. Then make sure that you build a decision process that at the bottom of the funnel, you have these 10% of vulnerabilities that matter most in terms of the… risk reduction. So this is something that I think can be used to help us understand

Host: Yeah, so I like how you structured it, right? Like start with the basics, get some of the visibility through S-forms and all, then start ingesting your, like C-secure data, threat intel, or the EPSS integration.

And then if you have asset-related information, asset information, bring in that. So as the organization scales, like start tackling one of these areas so that you sort of add more context to… the dependencies or vulnerabilities and that helps you with the prioritization.

Yotam: Yeah, exactly. So start with the visibility aspects, like know what you have, and then start layering additional context so that you can make more informed decisions about the prioritization.

Host: Yeah, yeah, makes a lot of sense. And that's a great way to end the security section as well.

Rating Security Practices

We have another section which primarily focuses on rating security practices.

So the way it works is I'll share a security practice and you need to rate them one through five, five being the best. And again, like if you want to add context to why you think it's a one or a five or any number, that would help.

So let me start with the first one. The first one is

Conduct periodic security audits to identify vulnerabilities, threats and weaknesses in your systems and applications.

Yotam: OK, so I think it's super important. So I would say even five, but I would alter maybe the sentence a bit. I don't think that like, I think that the keyword here is periodic. And I think we should even go further and say that, like, ideally, you'd want to bless you. No, no worries. So I think it's.

It's important, but ideally I change the word periodic and into like continuous, because I think you'd want to continuously monitor, because as we like mentioned earlier on, like in the world that we're living in with, you know, CI and CD, things are constantly changing. Things are very dynamic. So you can have a Docker container with a version that has no vulnerabilities and the next day you pull in.

the latest version that has now a new vulnerability or something is discovered. So you have to have this continuous monitoring aspect. So when things change, dependencies change, new hyper

Host: Okay, makes sense. The second one is provide training and awareness programs to employees so that they can identify and respond to potential security threats.

Yotam: So I would say I would go with maybe a three, not because I don't think it's important. I think it's super important, the educational aspect. But I think, again, because of the reality that we live in, you know, things change like constantly and at a very high pace. So and technology is changing so fast that you will always have like new emerging technologies that require like… additional training and awareness.

Like for example, let's take again, like the LLM landscape. Like if we go back a year, no one knew what prompt injection is and now everyone's talking about it. So it's hard to keep up with these shifts. It's not linear, it's like jumps. So I think it's again, and I'm not saying don't educate, it's super important or the move like to more memory safe languages again.

It's important, but I think what's more important are the principles, to focus on the principles because technology will keep changing.

Purusottam: Make sense. The last one is, development regularly tests an incident response plan to help quickly detect, respond to, and recover from security incidents.

Yotam: So that one, I would also give a five. I think it's super important. I think it's really, like one of the things that I got to do for while at PayPal, which I took a lot from is doing like security control testing. And I think that is a practice that is often not given enough credit, not, you know.

people don't do it enough. And organizations can have, especially the big ones, the bigger the organization, the more tooling it has. But you don't always validate that these tools can do what they say that they're able to do. And I think it's super important both in terms of these kind of things, like tabletop exercises and check, validating your incidence response team.

and making sure that your tools do what they say they can do, identify gaps, and also how you can better leverage and create synergies with the different data points that you have from these different tools and the processes around that. So I think that is a super important and kind of undervalued even practice.

Host: Yeah, and I think you highlighted tabletop exercises, right? Generally, it's recommended that you do those exercises every few months so that you understand your preparedness, incident response preparedness. So yeah, you're spot on there. So yeah, thank you so much, Yotam for joining us and sharing your insights on vulnerability management and supply chain security.

Yotam: My pleasure. It was a great talk. And again, thanks for having me. Had a great time.Host: Absolutely. It was a pleasure here as well. And to our viewers, thank you so much for watching. Hope you have learned something new. If you have any questions around security, share those at scale20.com. We'll get those answered by an expert in the security space. See you in our next episode. Thank you.