[0:11] Hi everyone, welcome to our webinar. My name is Daniela, I’m a solutions engineer here at OX. Thank you all for joining us today. We have a few industry experts here: Cam, Sean, Ron, and Jack, and in a few minutes I’ll let them introduce themselves. We’ll start with a brief introduction from each...
[0:11] Hi everyone, welcome to our webinar. My name is Daniela, I’m a solutions engineer here at OX. Thank you all for joining us today. We have a few industry experts here: Cam, Sean, Ron, and Jack, and in a few minutes I’ll let them introduce themselves. We’ll start with a brief introduction from each panelist, then get into a deeper discussion about our topic, which is decoding AppSec reporting. We want to understand together how we can move from metrics and the different alerts that application security tools raise to more meaningful insights. As usual this is a question-friendly webinar, so if you have any question, feel free to drop it in the chat and we’ll address it during our discussion. I’ll let Cam introduce himself first.
[1:27] Thank you, Daniela. Hi, my name is Cam, Kamalesh. I’m the director of security engineering and operations at Mambu, and part of my responsibilities also involve AppSec, in addition to infrastructure and SecOps. Previous to Mambu I was head of corporate security at a prior company, and before that I was with cybersecurity vendors, helping customers navigate their challenges and drive adoption for vendors like Palo Alto, Cisco, and Juniper. That being said, I’d push back on the characterization as an expert; I know enough to hurt myself, I’m not entirely sure I know enough to help myself, but it’s great to meet you all.
[2:42] Thanks for having me. A bit about myself: I started off as a developer and spent numerous years in development, then moved over to security, and I’ve been in AppSec for a good number of years now. At the moment I’m head of application security at a company called Feature Space, which is software that helps combat financial fraud. Before that I was at a company called Immersive Labs, and before that Secureworks. I’m quite active in the community and enjoy helping out and sharing guidance and advice where I can.
[3:46] Sean, to be honest we have a very similar introduction, because I also started as a developer and then moved to cyber security, and I always say I’m here more years than I care to admit. Ron, you’re up next.
[4:04] Thank you. My name is Ron, I work as an information security officer in the application and product development space, so my daily work is supporting teams to mature their secure development processes. From my background, I started in business informatics, more the interface between IT and business processes, then ventured into compliance and auditing, before taking a turn back into IT, and about 10 years ago application security hit me, and it was a slippery slope into development security and data privacy. I’ve focused the last three or four years mainly on development security.
[5:14] Cool, we’re happy with whichever reasons brought you here. Jack, you’re the last one.
[5:21] Good to be here, welcome everybody. My name is Jack, I’m the group information security officer of Exact group, and we build business software, mainly financial and HR software, so a lot of data and a lot of different products. I’m responsible for the policies, but also the monitoring and the controls within the development phases of all those products and the cloud infrastructure where we host them, mainly public clouds, for our customers mainly in the Benelux and the DACH region.
[5:59] So your applications are different applications per customer?
[6:04] We have a few crown jewels, very big applications, but we also do acquisitions, so smaller applications hosted on AWS or Azure. We have a portfolio of products.
[6:25] Thank you all for sharing. Diving into the topic of our webinar: effective reporting is essential to reducing risk, aligning security and business needs, and enabling teams to take action efficiently. We want to make sure the organization isn’t facing breaches and that we increase productivity as much as possible. In this session we’ll explore strategies for overcoming the reporting challenges we face, even with just one tool that alerts on many issues, or many tools alerting on a lot of vulnerabilities. We’ll touch three subtopics: first, why decoding is necessary, why we can’t just go by whatever the tool alerts us; second, the risks and challenges in decoding the reports and alerts; and third, the different solutions and approaches. Let’s start with the first. Cam, why is it even important to use some kind of digestion, to decode and contextualize the information around vulnerabilities we get from the different tools when it comes to risk assessment and reporting?
[8:16] Great question. Here’s the thing: when we talk about vulnerabilities, especially the way they’re scored, if we’re talking about a CVSS score, there are different parameters and vectors assumed when they’re scored. When we talk about risks versus vulnerabilities, we have to contextualize the severity, because even if you have that specific library or system in your estate, it’s not always a guarantee that the particular set of vectors the CVSS was scored against is actually relevant to your organization and infrastructure. So when doing a risk assessment, and I’d definitely take a risk-based approach to vulnerabilities, it’s very important to take these factors into consideration, because one of the things we have to watch out for is a very common term in security operations: alert fatigue. If you look at an RSS feed of CVSS vulnerabilities, it’s a never-ending feed; there are so many vulnerabilities reported, and the reality is we have to have a filtration mechanism to focus on the right vulnerabilities. That’s where you bring in contextual information and look at it critically: why is this vulnerability important to fix, what is the right prioritization? NVD might say this is critical, but is this actually critical for my business? That level of filtration is absolutely necessary, because prioritization is essential. Developers have limited bandwidth; they’re constantly bogged down by business outcomes, and while they’re very willing to fix vulnerabilities, prioritization becomes a key factor to focus them on what is actually effective and necessary, and to create that traction that helps us improve security posture, which is the ultimate goal.
[11:24] Definitely, and it brings up an interesting point. As an application security vendor ourselves, we’re trying to understand the different metrics that application security teams or developers need to evaluate beyond global metrics like CVSS, like whether something is exploitable. Right now this is something teams often have to do manually, though we also see a trend of AppSec and ASPM vendors trying to automate it. So Cam, what are the most common mistakes you see teams or developers make when triaging or prioritizing reported security issues? Sean, do you want to take this?
[12:44] Absolutely. It’s important to realize what security is about: at the end of the day, managing risk. I always view security in its simplest form as managing risk. We aim to get rid of risk, which is never going to happen; the business needs to move forward. I could have the most secure system ever, a rock that does absolutely nothing and adds no value, 100% secure, and even then you might question whether it’s 100% secure, but it’s meaningless and valueless. On the flip side, we could have all the features and no security, which is also not right. So it’s about balancing. One challenge companies and sometimes security professionals get is they don’t take their own context into scope. To Cam’s point, a vulnerability may have a CVSS 10, but you may not use that function, or you may have a firewall in front of it so deeply that it’s totally pointless, and to view it as CVSS 10 might mean it just drops to low. This is why the word risk is important. When people view vulnerabilities they immediately jump to CVSS. I like CVSS, but it’s used incorrectly: if you go to NIST’s website, under the vulnerability metrics it clearly states that CVSS is not a measure of risk, yet we use it as one. So we need to change how we deal with this. Look at the history: Heartbleed wasn’t a CVSS 10, it was around a 5, but it was a big thing. Log4j, everyone lost their marbles, when in reality if you worked out the real risk, the impact was high but the likelihood was low. So coming back to reporting, we need to add context: don’t just look at the CVSS score, how likely is it to be exploited, what else do we have in place to prevent the impact. And on top of that, we need things in place to guide development teams on how to remediate. Too often security teams say “go fix it,” and the team asks “how?” Or development teams say “we fixed it,” and you ask, “how do you know, if you’re asking me to test it?” So we have to work with development teams, and one way is having the right information in the reporting for them to understand how to fix it and how to test it.
[16:06] You made two interesting observations. The Log4j example is the most representative, because everyone was hysterical about it, and even now articles are released about how, with very deep transitive dependencies that aren’t even direct, the likelihood of being exploited drops drastically, to less than 1% for a Log4j transitive dependency being actually exploitable by an attacker. So another factor to consider beyond the CVSS score is: is this something an attacker is actually able to exploit, especially in a second or third transitive dependency deep in the tree? And the second thing, about helping developers understand how to fix vulnerabilities: everyone talked about shifting left for years, and it’s important to stop vulnerabilities as early as possible, but in a lot of cases developers aren’t sure: we need to upgrade from this dependency to that one, but that doesn’t say much to me as a developer about what other adaptations I need to make to really fix it without breaking the application. So when prioritizing, we should consider not just the risk but also whether this is a major fix or a major version jump that affects functionality, to understand which vulnerabilities to prioritize first.
[18:12] Moving to my next question: when I work with potential customers, we meet a lot who have more than one scanner for application security, sometimes even two that do the same thing. There are so many scanners out there, including open source. How can you tell if you have too many scanners, and how do you verify you have the right ones? Ron, do you want to take this?
[18:57] Thank you. First, what scanners are we talking about? We have the reactive ones, intrusion detection and so on, a whole world. The ones I mainly focus on are everything to do with producing software. There you have to separate the different functionalities: static analysis, software composition, and increasingly container posture management and what happens in production. So you should cover the whole length, from coding, to third-party code, to everything that happens in containers, which in the past was vulnerability management on virtual machines, very far from development. Then the question is how many per section, which gets more difficult, because in the past you had specialized providers offering a single functionality, and now many are moving into platform security, which is generally good but leads to overlap. So you have more scanners for one topic. In the past, not all functionality was covered by some vendors, so there was often a need for multiple vendors, especially across the whole length from static to Kubernetes and cloud. Then the second part: how do you deal with the overlap? You have to prioritize and decide. In my experience we decided on a primary target and something corroborating, based on the quality we perceived. But that raises how much corroborating information you want: a second, third, fourth opinion. It’s basically based on your risk appetite. If you have software with high risk, say an IAM system or a browser, you certainly want more than if you’re producing everyday software with less security impact. And when it comes to the actual teams, it depends on how much you can handle: the moment you realize you have findings you constantly ignore and never react to, you should consider reducing. Although that becomes more problematic with recent legislation, because you’re supposed to provide things without vulnerabilities, and the question is how much you have to invest to figure out they’re free of them. It’s a two-edged sword: ignoring things you could have found, versus saying if I won’t react to it, it just lowers my overall ability to react to specific findings. And on open source: if you have nothing, you should certainly think about open-source solutions; it costs some work, but you should not have nothing.
[23:58] I definitely agree, it’s better than nothing. It’s an interesting approach, the first time I’ve heard someone say I want as many tools as possible, even paid ones, because each tool has a specific area where it shines, a specific language with amazing coverage, or a category like DAST, SAST, or code smells. But eventually we get back to: okay, we have those tools, and I remember asking the first person I spoke to about this approach, how many of those are you actually fixing day to day? And it was, not as much as we would like. So it’s important to first understand whether we’re leveraging the maximum potential of the first tool before we move on to another.
[25:12] Exactly, it’s not that you should have the most possible; it depends on your scenario. Some companies have a lower risk tolerance and invest in people to work on those findings. It’s not one-size-fits-all, but you should have one major tool you work with, and at the point when you cannot fix any more, additional information doesn’t necessarily help. What I see sometimes is that it’s not really that you have additional vulnerabilities, but more corroborating information that enriches the existing information, or adds elements another tool might not provide, or where you have a specific compliance obligation requiring specific reporting, and then it gets messier.
[26:10] I agree, some tools might occupy the same space, both being static scanners, but one integrates with our pentest results and the other with our cloud environment. That takes us back to prioritization, because the more integration points we have, pentest results, DAST connectors, a cloud environment, the more it helps us prioritize. Jack, do you want to share the methods you use to make your prioritization of vulnerabilities as accurate as possible?
[27:02] Interesting question. It’s a combination of what my predecessors said: it’s mainly about scan and verify. With most vulnerabilities, especially Log4j and infrastructure vulnerabilities, we have tooling to verify whether the vulnerability is really there, because if a vulnerability pops up, and most of the ones with cool logos and cool names had the entire world running, you have to verify whether you’ve actually implemented the software or third-party component in a way attackers can use to their advantage. So we scan a lot, all our products, and conduct manual tests like pen testing, but we always verify the results are really there, and then classify them: this is a vulnerability that can cause a system to go down, or it’s really a remote code execution. If a vulnerability only hurts the application by making it go offline, and it’s not our crown jewel, and it would cost two years to fix, can we fix it differently, can we use obfuscation or something else to make it not available from the outside? We’re not always in the game of fixing all vulnerabilities; I think that’s a fantasy, that any company can fix all vulnerabilities. You should check what vulnerabilities need to be patched ASAP, which can wait a few weeks, and which you should take offline or remove a piece of functionality. We’ve taken the liberty to remove certain functions, because a function was only used by a handful of customers out of millions, it was vulnerable, and the business case to fix it was so hard, so we removed that third-party component. Sometimes a third-party component is built by one person who put it open source and never updates it, and commercial companies use it; if there’s a vulnerability, who’s going to update it? Nobody’s responsible, so you have to choose: find something to replace it, or remove the component and function entirely. So we classify and prioritize, fix the criticals within certain boundaries, move down to the lows, and certain lows just wait for a major product overhaul once per quarter.
[30:42] Maybe another interesting question: since you’re a B2B company, not a consumer app like Waze, do you also take under consideration how big the customer using the application is?
[30:55] Most of our applications are SaaS, one platform for hundreds of thousands of customers, so we prioritize on the amount of customers on the platform and the data in the application, because we also have applications with fewer users but very sensitive HR and medical data, which under GDPR has significant protection. You classify your applications as crown jewels or not, and that prioritizes how you patch.
[31:38] This is still leveraging business needs and tying them to the prioritization mechanism.
[31:45] If we could spin up a thousand employees to patch, we would, but employees are scarce, especially in application security, really understanding and patching vulnerabilities. So you need techniques: web application firewalls, virtual patching, removing functions. You cannot patch everything, so prioritization is which vulnerabilities to mitigate, which to accept, and which to remove entirely. It’s every time a business decision, not mine; I only tell the business, we have a vulnerability and I think this is its criticality based on thresholds: CVSS is one, but also can it be exploited, how many scanners picked it up, how vulnerable are we, is there an indicator of compromise. Then we prioritize.
[32:53] Definitely. Now to my favorite topic, a challenge for everyone dealing with security. Say we have the most amazing security team, the most perfect tool, and the most perfect prioritization mechanism, and we know exactly the top five vulnerabilities to fix, it’s not a lot, but we still need to get the dev teams to understand the severity and ensure they actually fix it. This is a big friction point. Sean, how do you get your dev teams to understand the severity of reported items, and how do you get them to fix them?
[33:46] One of the things is to understand how dev teams work. If you’re just talking to your dev teams, you’re probably not going to win, because it’s not just dev teams that determine the work they do; you also have to speak to your product teams, who put the work in front of the dev teams. So work with development teams, but also with product teams who lay out the upcoming work. If you can get on the product team side, you’ll have a wonderful journey with all the vulnerabilities addressed in a relatively short time. One of the biggest challenges security teams forget is just going to the dev teams in a silo; you have to work with product teams. Similarly, make both teams aware of why it’s important to fix, not just because it’s a severity one. What does it actually mean if it’s not fixed, how does it affect the product and the company? It’s a cliche that security is everyone’s responsibility, but showing them what it means to them personally helps them take more interest. And leverage real-world examples; this is one reason I love using the likes of Equifax, not because I hate the company, it’s a really good example of the consequences of not getting fixes in, because at the end of the day you lose customers, and it could be your job on the line because of redundancies. And make sure they’re working on the things that really matter. As Jack said, you’re not going to fix all vulnerabilities; I’ve seen companies try to fix everything, which is as dangerous as not fixing things, because you spin your wheels so much that you’re not focusing on the ones that really matter and will cause the most harm.
[36:20] I want to extend your questions, how does this affect the product, the customers? The strongest question is how will this affect sales. That’s the one thing everyone can agree they don’t want to harm, and being on the sales team myself, I see how much the things we ask the development team to fix get prioritized. So if you thought having the product team on your side is good, try having the sales team on your side, it’s even better. Now, lots of AppSec and ASPM tools integrate with Jira, Azure Boards, Slack, or Teams to send alerts, but you can get conflicting messaging between tools: one reports a vulnerability as high, another as low. How do you define your level of trust and handle those conflicts? Ron, do you want to take this?
[37:57] I’m not sure you can handle it perfectly. You’ll have one primary tool you work with, and then you try to add additional information, which is how we try to avoid real conflicts. But in the end, as Jack said, you have to take a risk decision: is that something you’d work on? This becomes more difficult with certain obligations we’ll run into. When you’re a product vendor selling a product with digital elements, basically all software, you have to reduce the vulnerabilities, even all of them, and the discussion is how far that extends. So I’m not sure it will really be a conflict in the future, more a way to maybe eliminate certain parts. I see it as an opportunity: if one tool doesn’t find it and another does, you have a data point to investigate why it might not affect you. On the other hand, if you have multiple tools all screaming CVSS 10, that’s something to definitely focus on. So initially it helps with direct prioritization, and afterwards it helps identify things you maybe should not look at because one tool is overly broad. The main thing with third-party products is: is it the correct dependency, is the dependency actually affected, how do you match it, who do you believe? We already have a lot of conflicting information, NVD, which we know isn’t always perfect, GitHub advisories, Google, and so on. As long as we integrate that information well, finding a consolidation and correlation layer rather than looking into 15 different tools, it can even help. That’s where ASPM tools come in: you have something in static, but in dynamic testing you cannot find it anymore because you cannot actually exploit it. So it doesn’t have to be a curse, it can be a blessing.
[41:18] Two things come to mind. First, the very important point about crossing information with pentest results and so on, which is something we’re planning to do in OX, those integration points that let you cross all this information. When I do POCs, I always try to see what vulnerabilities came up and their severity, and people sometimes neglect understanding why each vulnerability got the severity assigned to it. Having that elaborated well in the tools you use is priceless, and I feel a lot of AppSec engineers and security specialists don’t put enough emphasis on that when evaluating a new tool. So a tip for the audience: don’t just look at the face value of vulnerabilities, also look at how easy it is to understand why this severity was assigned. That opens the door to another discussion: everything around ASPM, sold as a single pane of glass to view all security risks. Jack, I see you half-smiling, so the next question is for you: what risks do you see in using an ASPM tool?
[43:22] Same as with all the other buzzwords from the last few years. I still don’t believe ASPM tools are mature enough to buy or implement. We have discussions with suppliers who offer those solutions, but a real single pane of glass for application security information, I’ve not seen it yet. Most suppliers try to sell me the golden bullet of information security, but as a profession we should think about what information we really need and then come up with a platform that shows that data. Can it be named ASPM? Yes, but the vendors also tell me ASPM is function X, and the next one says it’s function Y, so I’m still struggling with what ASPM means. Do I think if it matures it can give us more information? Yes. Currently I connect all kinds of platforms via APIs to a dashboard that gives me the information I need and lets me drill down. Can it be better? Always. For the rest I do what was said before: a vulnerability is reported, is this really a vulnerability, check and verify, and work from there. If we can implement a nice tool that replaces a lot of my dashboarding and gives me direct commands to virtually patch or update my rules, that would be great, but I’m a little pessimistic about the effective working of those tools. Let’s see what the future brings; those tools need to mature, as do most companies on application security.
[45:44] First, I’m doing my best not to take everything you say personally, but it’s an interesting discussion. How do you think ASPM vendors in general can do better?
[46:11] Make choices about the integrations they support and support them very well, because most ASPMs support almost everything, and if you really want to connect and get certain data, it’s a custom build. And I think ASPM should do something with virtual patching or updating rules in firewalls or web application firewalls, so you have that single command ship: this is a vulnerability, I send a command to my WAF, I’m safe, and I can continue. I really think the world is getting worse: zero-days pop up every few months, and every year there’s a very severe one that shakes the world. Log4j was two years ago, we had Citrix a few years ago. If we had a tool that says we’re using this component, yes we’re vulnerable, but here’s an indicator of compromise and the way to mitigate it by sending a command to disable this function, all in a span, that would be the golden bullet, because you can not only see the vulnerabilities but act on them almost directly. I’m not talking about patching, but virtual patching or disabling certain functions.
[48:08] First of all, Jack, we’re hiring a new product manager if you’re interested, kidding, but it is an interesting discussion. We’re internally thinking about the most beneficial integration points to really get that single pane of glass. I agree this is a new term and a new product industry invented in the past few years, and it’s interesting to see where the future takes us.
[48:55] Most vulnerabilities are reported on Friday afternoon, so if we have something that virtually patches for the weekend so we can start on Monday, that’s what I’m searching for.
[49:07] We work Sunday to Thursday, so Friday afternoon we’re already off, but I definitely agree. We’re moving to the third subtopic: solutions and approaches. Cam, what are some of your key approaches for security leaders to ensure they have adequate levels of risk treatment to identify the different vulnerabilities in their applications?
[49:46] One thing we have to understand is what actual problem we’re trying to solve. One problem I foresee, especially in prioritization, is that there’s a translation between an objectively characterized vulnerability with a specific rating and a risk. While there are some objective ways of looking at risk, risk assessment is to a certain extent an intuitive exercise that comes through years of experience and properly understanding the potential impact on the organization. The challenge is that when our analysts evaluate these vulnerabilities or receive RSS feeds and report to management, without additional help in contextualization, a single pane of glass to compare and correlate different sources, it’s difficult to make this translation from a vulnerability score to a risk score. Because more often than not, when you report security issues to senior leadership, they understand risk, not CVSS scores. So this translation needs to happen at the grassroots level, and with so many sources of information and very little correlation, that part is relatively broken. One strategy is having a single pane of glass that gives analysts enough information to make this determination. The other aspect is organizational: sometimes, because some issues are difficult to fix, I’ve had developers in former organizations say “this is too difficult to fix, can you just lower the risk rating so we stay within SLAs?” That’s an organizational problem: accountability for fixing risks needs to be shared, resting partly on the developers themselves. So both technically, you need a single pane of glass, correlation, and good processes that digest information and present it in a business-literate way for executives, and organizationally, you need buy-in from engineering leadership that if something is genuinely a critical risk, we adhere to the SLA, barring exceptional cases like Log4j, which was incredibly tricky to fix. That’s where ASPM can integrate into Jira systems to track how tickets are progressing and give an end-to-end view.
[54:33] Two interesting points. When I was a developer, my first job in high-tech, I wasn’t even familiar with the term SLA; I had no idea it was something we agreed on for every customer. So in many cases this isn’t even in developers’ state of mind. And the second thing: I understood you to mean taking the vulnerability represented in a tool and understanding the real use cases it exposes you to, because if you tell a CISO, or anyone not on the security team, “we found this CVE with this CVSS score,” it doesn’t tell them anything; you need to switch the language to which attack behaviors this actually exposes you to. Now to a buzzword you cannot avoid: AI. Sean, can you share how automation and potentially AI can help in cleaning up application security reports and vulnerabilities?
[56:28] AI is going to take our jobs and solve everything, and if I still get paid, I’m okay with it. Joking aside, one challenge with AI is that a lot of the marketing has given it a bad reputation, when there’s really good value in AI if used correctly. If we look at CVEs, the number is just growing and growing; CVE Details has a nice graph of this. For teams to stay on top of this manually just won’t scale; you’d have to hire loads more people, which probably won’t happen, or change the approach. One way is automating things that can be automated, and as part of that automation, leveraging AI to help. I use the word “help” rather than “solve,” because you still need humans, especially for the trickier things. Where I view AI coming in is helping with the more mundane, lower-level, easy-to-reproduce stuff. I haven’t seen the tool that solves it all yet, but I’m hoping the field gets to where AI and automation deal with the mundane and humans focus on what really needs attention. Today there are things for automation: in GitHub, Dependabot can raise automatic PRs, no AI involved, but leveraging that alleviates some burden so teams focus where they add value. And this is where automation is key: if you’re updating libraries, you want all your automated testing in place, so when you change something, the likelihood of it breaking is lower. It’s an area that’ll be interesting over the coming years, ignoring the marketing fluff; I view AI as a tool to help us do our jobs better.
[59:41] I agree. It’s amazing how concentrated you are with the two angels in the background that seem to do a lot and we hear nothing of it. We already see automation, not anything new, opening pull requests or automating the creation of tickets. But as you said, it’s limited, because even if we automatically open a PR, a developer still has to review the fix and make sure it doesn’t affect the functionality of the application, and that’s something security teams often miss: you open the PR automatically, but what about the functionality of the code? Someone still needs to review it. My next question is to Ron. I assume most of us are based here in Europe, so what challenges do you foresee, especially given EU law, and when decoding application security reports, does prioritization alone help when we take EU legislation into consideration?
[1:01:37] We’re looking mainly at two different legislations now being discussed that will go live these days: NIS2 and the Cyber Resilience Act. With NIS2, when you’re providing software, a lot of the risk-based approach still works, because you’re managing your own risk, you can make decisions, and you have to have a system in place that proves your cyber resilience. There, prioritization plays a big role, and you need that insight and contextualization to make the right decisions. It gets more difficult with the Cyber Resilience Act, because then we talk about products we deliver, and it’s not necessarily the amount of risk you manage but the amount of vulnerabilities; it’s constantly about vulnerabilities. There’s one part about risk assessment, identifying what your product will be used in, but a current technical guideline for proposal from the office of information security says that when producing software that is vulnerability-free, you cannot use the risk approach to get yourself out of it, saying “it’s not risky.” You have to address vulnerabilities, so the jump from vulnerability to risk gets more difficult; it gets more into informing others how they can manage their risk using your products. Automation helps a lot there, because you are suddenly forced by law to evaluate the vulnerabilities in your software from your SBOMs, possibly with NVD or others, and create advisories, which means the amount of advisories will skyrocket. If you don’t do that in a machine-readable, automated form with all the CSAF standardization, it’s basically impossible; you cannot read all CVEs or all security advisories and match them to your environment manually. The other part is informing your customers about how they might be affected, or if it’s still in triage, and there’s a lot of argument to inform people about negative situations too. With Log4j, it didn’t matter how much the actual risk was, it was a perceived risk and there was a lot of panic, and no company would have been unhappy to get, the day after it was published, information from all their suppliers saying “we’re not affected, we’re not using Java.” So it doesn’t help me when someone says you have a CVSS 10 vulnerability; I need to understand why and how I can be affected, and that needs to be high quality, because developers normally aren’t security or exploit experts. The easier it is for them to identify if they’re affected, through reachability analysis or understanding how the vulnerability works, the better, and that’s key to providing accurate, fast information to customers. On fixing, does prioritization help? Yes, to a degree, because vulnerabilities need to be addressed and fixed in a reasonable time, which is different for a CVSS 10 and EPSS high than for low risk, but in the end you have to fix. So what is the lowest threshold not to act? That will be interesting to see play out.
[1:06:36] Thank you so much. We’re about seven minutes over time, so I’ll wrap up. I want to thank you all; I hope everyone took some insights. Based on what Jack said, I’ll be pitching some ideas internally at OX. I hope you got meaningful insights on how to review your AppSec reports and findings, turn them into meaningful actions, and who to work with internally to prioritize. Thank you again Sean, Ron, Cam, and Jack, for taking the time to participate, and thank you to everyone who joined. That’s it, thank you so much, have a good day.
