1. Introduction - where do we stand? (10 minutes)

In this section I will describe the current state of vulnerability management and the challenges organizations face, including:
- Most of the code running in a production environment is third-party code (commercial or open-source).
While this allows focus on the core business logic and increase velocity, it comes with inherent risks.
- The number of vulnerabilities discovered each year is steadily rising
- Exploitation of known vulnerabilities remains one of the most common attack vectors
- Organizations can't keep up and are left with huge vulnerability backlogs
- Current prioritization by CVSS score is suboptimal at best
- These challenges will only intensify over time
I will present insights from research we conducted analyzing the public attack surface for CISA KEV vulnerabilities.

1. The promise and peril of SBOM (10 minutes)

In this section, I will discuss the events that led to the increased adoption of SBOM (Software Bill of Material), shortly explain what is it and what is the problem it tries to solve. We will then discuss some of the challenges standing in the way of SBOM living up to its full potential and review some of the work being done in various governmental work streams as well as in the open-source community around advancing the SBOM ecosystem (adoption, tooling, sharing & exchanging of SBOMs and more…).
I will also argue that SBOM alone isn’t a silver bullet as it is a double-edged sword - with increased visibility comes increased noise which only aggravates the issues discussed in the first section.

1. What do we need to solve? (5 minutes)

Given all of the above we still need a way to answer the “Am I affected?” question at scale.
In this section, we will briefly discuss some of the current alternatives for answering this question and their shortcomings. Including: vulnerability scans, independent Investigation, asking the vendor, and relying on security advisories.

1. A way forward? (10 min)

In this section, I will suggest a shift in the vulnerability management paradigm I believe is inevitable to adopt in order to effectively cope with the challenges presented - as patching everything is impractical, and current prioritization strategies are suboptimal, we need to strive to adopt a risk-oriented approach where we prioritize vulnerabilities based on exploitability.

This cannot happen without automation.

I will present the Common Security Advisory Framework (CSAF) and the Vulnerability Exploitability Exchange (VEX) and discuss how they can help with some of the challenges we discussed. I will offer an outlook into a future in which these standards gain wide adoption and are integrated into security tools and demonstrate how that can lead to effective and scalable vulnerability management.

1. How will this look like? (5 min)

In this section, we will present an example of such an ideal flow in a visual manner.
A potential flow could be for example:
A new critical vulnerability that can only be exploited remotely and requires a specific configuration to be in place for effective exploitation has been discovered in a library used by millions of different applications worldwide.
Luckily, you have an SBOM of your entire environment. You query the SBOM to find 100 occurrences in your environment. Out of these 100 occurrences, 80 are part of 10 different commercial and open-source products and 20 are part of your proprietary code. For 8 out of the 10 commercial and open source products, your security tool was able to automatically ingest their CSAF with VEX statements saying that they are unaffected by the vulnerability with the justification: vulnerable_code_not_present.
You are left with a total of 16 occurrences in 2 third-party applications as well as 20 occurrences in your proprietary code. Luckily, you also have a runtime analysis based tool that determined that only 5 of the remaining occurrences in your proprietary code and 8 occurrences in one of the relevant third-party applications are actually loaded to memory, the rest are installed but are not in use, the tool automatically updated the SBOM with the corresponding VEX statements saying that these 25 instances are not exploitable with the justification vulnerable_code_not_in_execute_path.
You are left with 13 occurrences in 2 potentially vulnerable applications containing the vulnerable library
As a strong believer in layered defense, you also have a network security tool that determined that the third-party application isn’t exposed to the network and hence updated the VEX statements for all 8 occurrences of it as Not Exploitable with the justification: vulnerable_code_cannot_be_controlled_by_adversary.

All this happened automatically without any human intervention.
All you are left to triage are 5 occurrences of the vulnerable component in your proprietary code.

You validate the configuration of the hosts containing the 5 loaded, reachable via the network vulnerable instances and see that only one of the hosts has the configuration required for successful exploitation. You manually update the VEX statements of the remaining 4 occurrences as Not Exploitable with the justification: vulnerable_code_cannot_be_controlled_by_adversary.

You open a ticket for the relevant team to patch the final exploitable occurrence of the application using the vulnerable library and go make yourself a cup of coffee :)

1. Final words and open discussion (5 minutes)

We will discuss some of the outstanding challenges on the road to that vision and open the floor for questions/open discussion.