In an era where cyberattacks affect over 60% of companies, the entry point for hackers is often a known vulnerability. However, the traditional advice of “patch everything” is no longer practical or even smart in today’s complex digital landscape.
We spoke with Yotam Perkel, Lead of the Vulnerability Research Team at Resilien and a committee member for open-source security working groups, about the shifting paradigms of vulnerability management (VM) and the intricacies of securing the modern software supply chain.
You can read the complete transcript of the epiosde here >
Where do organizations make mistakes in vulnerability management?
The traditional approach to vulnerability management is often unrewarding and ineffective. Many organizations struggle with a “long tail” of maturity, lacking the people, processes, or technology to cope with the sheer volume of vulnerabilities discovered daily.
A significant challenge is the rise of third-party software. While using open-source libraries and commercial components allows teams to deploy faster and focus on core business logic, it introduces a constant stream of known vulnerabilities. The old paradigm of “patching everything” is no longer practical or smart; organizations must move away from manual triaging, which requires validating scanner outputs against specific environments—a process that scales poorly as systems grow in complexity.
How can context transform vulnerability prioritization?
With 57% of vulnerabilities listed in the National Vulnerability Database (NVD) carrying a “High” or “Critical” CVSS score, organizations often find themselves with backlogs far larger than they can handle. Most organizations can only address roughly 10% of their backlog in a given month.
The solution is context, which Yotam divides into two categories:
- Internal Context: This involves understanding asset criticality, business importance, and specific environmental configurations—such as whether a vulnerable component is even reachable or loaded.
- External Context: This focuses on exploitability. Is the vulnerability actually being exploited in the wild, or what is the probability of it being exploited soon?
Prioritization becomes more intelligent when these are combined. Since less than 5% of vulnerabilities are ever exploited, focusing on high/critical scores alone is an inefficient use of resources.
Is supply chain risk the same as a vulnerability problem?
While related, supply chain security and vulnerability management are distinct problems. A major gap exists in how repositories currently handle malicious packages. When a malicious package is discovered, it is typically removed to prevent downloads; however, this often erases the context of the attack.
Yotam argues that we should focus on identifying the attackers and their patterns rather than just the packages. To address this, initiatives like the Open Source Vulnerability (OSV) schema have added support for context, documenting the method of injection (e.g., pipeline compromise vs. rogue developer) and what the code actually does, such as data exfiltration or crypto mining.
What frameworks help secure the software supply chain?
No single tool or vendor can solve supply chain risk; it requires industry-wide collaboration. Several initiatives offer a roadmap for maturity:
- SLSA (Supply-chain Levels for Software Artifacts): A framework that defines different levels of security practices for software builds.
- OpenSSF Scorecard: This tool runs automated checks on repositories to assess security health—such as whether code reviews are required before merging—giving projects a total score to help consumers choose more mature libraries.
- OSCAR (Open Software Supply Chain Attack Reference): Similar to the MITRE ATT&CK framework, this maps out the various avenues and stages of supply chain risks.
Recent research shows that many popular AI and Large Language Model (LLM) projects on GitHub have surprisingly low scorecard scores, highlighting the importance of using these frameworks as part of the adoption decision process.
Why is the SBOM a critical building block for transparency?
The Software Bill of Materials (SBOM) serves as a machine-readable building block for transparency. It allows consumers to demand visibility from their vendors regarding what is actually inside the software they use.
An SBOM becomes a “vehicle for context” when layered with other data:
- VEX (Vulnerability Exploitability eXchange): This can be tied to an SBOM to indicate whether a specific vulnerability is actually exploitable or reachable within a given product or environment.
- Verification: Organizations don’t have to trust a vendor’s SBOM at face value. Tools can generate an SBOM based on runtime or build processes to verify the vendor’s claims.
How do CVSS, EPSS, and SSVC differ in effectiveness?
Understanding different scoring systems is vital for effective program design:
- CVSS (Common Vulnerability Scoring System): The de facto standard for assessing severity. Version 4.0 aims to address the lack of granularity found in earlier versions. However, many organizations mistakenly use the “Base Score” alone for prioritization, ignoring the temporal and environmental factors that truly reflect risk.
- EPSS (Exploit Prediction Scoring System): A strong signal for prioritization that predicts the likelihood of exploitation.
- SSVC (Stakeholder-Specific Vulnerability Categorization): This is essentially a decision tree that helps organizations communicate internally and externally how they prioritize vulnerabilities based on their specific capacity and environment. It allows teams to build a funnel that ensures they focus on the top 10% of vulnerabilities that matter most for risk reduction.
What is the roadmap for a growing startup to build a VM program?
For security leaders just starting out, Yotam recommends a gradual, visibility-first approach:
- Start with Visibility (The Basics): Establish an asset inventory and generate SBOMs for your applications. Open-source tools like Syft or Dependency-Track can help gain this baseline visibility without commercial investment.
- Layer on External Context: Integrate freely available feeds like CISA KEV or EPSS to enrich your vulnerability data with exploitability information.
- Invest in Automation: Early investment in automation reduces the total manual workload required to address security challenges.
- Operationalize Decisions: Use a framework like SSVC to build a repeatable decision process that funnels the most important 10% of vulnerabilities to the top of your list.
