Supply Chains and Malware Campaigns: Is CVE the Right Way to Name the Game?

Supply Chains and Malware Campaigns: Is CVE the Right Way to Name the Game?

Speakers: Art Manion (Deputy Director, Tharros Labs); Caitlin Condon (VP of Research, VulnCheck); David Welch (Chief Architect, HeroDevs); Shelby Cunningham (GitHub)

Conference: VulnCon

YouTube: https://www.youtube.com/watch?v=XPb2bTzpBAs

Overview

In an era increasingly defined by complex software supply chains and sophisticated cyberattacks, a critical question looms over the cybersecurity community: Is the established Common Vulnerabilities and Exposures (CVE) system adequately equipped to track and communicate information about supply chain compromises and malware campaigns? This panel discussion, featuring leading experts from across the vulnerability and open-source ecosystems, delved into this "super hot and spicy topic" at VulnCon, challenging conventional wisdom and exploring the practical realities faced by defenders.

The discussion, featuring Art Manion, Caitlin Condon, David Welch, and Shelby Cunningham, meticulously dissected the nuances of CVE rules, particularly their application to intentionally malicious code embedded within otherwise legitimate software. Drawing on real-world incidents like the XZ Utils backdoor, the TJ Actions compromise, the Shai Hulud malware campaign, and the Trivy compromise, the panelists offered diverse perspectives on the utility, limitations, and potential evolution of CVEs in responding to these evolving threats. Their collective expertise—spanning vulnerability management, threat intelligence, open-source project support, and advisory database curation—provided a comprehensive look at an issue central to the future of software security.

The urgency of this conversation stems from the cybersecurity industry's heavy reliance on CVEs for vulnerability tracking and management. However, CVE's foundational rules, crafted decades ago, primarily address accidental software flaws. The proliferation of sophisticated supply chain attacks, where malicious actors deliberately inject code or compromise legitimate accounts, stretches these definitions to their breaking point. This panel not only highlighted the existing gaps but also sparked a vital dialogue on how the security community can forge more robust and consistent mechanisms for identifying, alerting, and ultimately defending against these increasingly prevalent and impactful forms of cyber espionage and sabotage.

Background

▶ Watch: Is CVE right for supply chain malware campaigns? (0:28)

The cornerstone of modern vulnerability tracking systems is the CVE (Common Vulnerabilities and Exposures) program. Designed decades ago to provide unique identifiers for publicly known cybersecurity vulnerabilities, CVEs have become the de facto standard for security advisories, vulnerability databases, and automated scanning tools. This widespread adoption means that any significant security event often prompts the immediate question: "What's the CVE?"

However, the CVE program's rules were primarily conceived to address traditional software vulnerabilities – accidental flaws, bugs, or design weaknesses that could be exploited. The rise of supply chain attacks and malware campaigns, where malicious code is intentionally injected into legitimate software or distributed through compromised accounts, presents a definitional challenge. Specifically, CVE rules 4.1.8 and 4.1.9 govern the inclusion of malicious code:

• Rule 4.1.8: "general purpose deliberately malicious code must not be determined to be a vulnerability." This rule typically excludes standalone malware (e.g., malware.exe) from receiving a CVE.
• Rule 4.1.9: "products that have been modified to become malicious, for example, Trojan horses, backdoors, or similar supply chain compromises may be determined to be a vulnerability." The crucial word "may" grants CVE Numbering Authorities (CNAs) discretion, allowing for the assignment of CVEs in cases where benign code is co-opted for malicious purposes.

This distinction creates a gray area. While standalone malware is out, a legitimate library containing an injected backdoor might be in. The panel acknowledged that this ambiguity, coupled with the lack of robust, universally adopted malware tracking systems for the open-source community, often compels data providers to "retrofit" existing vulnerability pipelines. Platforms like OSV (Open Source Vulnerability) or the OSSF's malicious packages repo have emerged to address this gap, but none currently possess the ubiquitous integration and recognition of CVEs.

David Welch articulated a key tension: CVE, originally intended for identifying vulnerabilities, has evolved into a "vulnerability management and notification platform and ecosystem." This functional expansion means that regardless of strict definitions, a CVE often becomes the most effective, if not the only, way to disseminate critical security information to a broad audience of defenders and operators. The central problem, therefore, is not just one of classification, but of ensuring that the mechanisms for identifying and communicating any security-impacting event are effective and widely accessible.

Key Findings

▶ Watch: CVE helped during a critical incident (TJ Actions) (12:20)

The panel explored several high-profile incidents, each highlighting different facets of the CVE dilemma:

XZ Utils Backdoor (CVE-2024-3094)

The discovery of a sophisticated backdoor in XZ Utils on March 29, 2024, by Microsoft researcher Andres Freund, served as a stark reminder of the potential for deep supply chain infiltration. In this case, malicious behavior was embedded directly into legitimate code, leading Red Hat to issue CVE-2024-3094. Shelby Cunningham noted that this decision was based on the premise that an industry-wide identifier was necessary to notify and raise awareness for such a critical backdoor.

The panel largely agreed on the utility of the CVE in this instance. Art Manion, despite initially asking Red Hat not to assign a CVE (highlighting the definitional struggle), conceded that its presence undeniably aided information propagation. David Welch emphasized the practical necessity: "If it didn't end up as a CVE, as an operator for 20 years, I don't know how I would have ever found out about it." He added that without a CVE, dozens of organizations, particularly those with limited resources, would likely have missed the alert. Caitlin Condon echoed this, noting that without a common name, information would have been "all over the place," making effective response extremely difficult. This case underscored the pragmatic value of CVEs as a universal signal for severe security events, even if their strict categorization as "vulnerabilities" is debated.

TJ Actions Compromise (CVE-2025-30066)

The March 14, 2025, compromise of the TJ Actions changed-files GitHub action, discovered by Varen Sharma of Step Security, presented a different challenge. Here, the maintainer lost access to their development account, preventing them from publishing an advisory or requesting a CVE ID through their usual channels. Mitre, as a CNA, stepped in to issue CVE-2025-30066.

Caitlin Condon, who was directly involved in responding to this incident, confirmed that "having the CVE available helped with response because that was baked into the workflows that already existed." She humorously recounted being called to respond 20 minutes before a wedding ceremony, emphasizing how the CVE enabled rapid, integrated alerting. This incident highlighted the critical role CNAs play in stepping in when maintainers are compromised and unable to communicate. The consensus was that in such cases, where malicious code is injected and maintainer communication is severed, it is appropriate for the broader security community, through CNAs, to intervene and issue a CVE.

Shai Hulud Malware Campaign (NPM)

The Shai Hulud campaign, which spread worm-like malware across hundreds of NPM packages in multiple waves (September and November 2025), presented the most significant definitional challenge. Unlike XZ Utils or TJ Actions, there was no single "root package" or upstream vulnerability in the traditional sense; the malware propagated through various dependencies. NPM's existing malware takedown procedures and npm audit mechanisms handled the alerts, resulting in hundreds of GitHub Security Advisories (GHSAs), but no CVEs were assigned.

Art Manion and Caitlin Condon argued that Shai Hulud, being "general purpose malicious code" or a widespread campaign without a discrete vulnerability, did not warrant CVEs, aligning with CVE rule 4.1.8. Caitlin specifically stated, "we didn't assign a CVE to WannaCry," drawing a parallel. However, David Welch strongly advocated for individual CVEs for each poisoned component. He argued that if a package, when installed, directly leads to an attack (e.g., stealing keys, propagating malware), it represents an "exploitable flaw" that requires an "automated signal" for defenders. He questioned whether npm audit alone was sufficient, especially for organizations with limited resources.

The discussion then turned to CVE rule 4.2.13, which addresses how to handle multiple products affected by the same vulnerability. The rule advises against assigning multiple CVEs if products share the same vulnerable code. The panel noted that CVE lacks an inherent, machine-readable way to group related incidents in a campaign without creating an overwhelming number of individual CVEs or forcing manual cross-referencing in descriptions. This "issue bankruptcy" or the sheer volume of IDs for hundreds of packages was seen as a significant hurdle.

Trivy Compromise (CVE-2026-33634)

The Trivy compromise, occurring on March 19-22, 2026, involved a threat actor using compromised credentials to publish malicious releases of the Trivy vulnerability scanner (a Go package) and its Docker Hub image, injecting credential-stealing malware. This incident had significant downstream effects, impacting packages like Light LLM and TelnetX in the PyPI ecosystem. GitHub issued CVE-2026-33634 for Trivy, listing Light LLM and TelnetX as affected products, with individual advisories provided in the GitHub Advisory Database and PySec.

This case further intensified the debate over single vs. multiple CVEs. David Welch argued strongly for separate CVEs for Light LLM and TelnetX, given their distinct ecosystems (PyPI vs. Go) and widespread impact. He highlighted the fact that many users might not even be aware they are using Light LLM, especially in the context of AI interfaces (e.g., Claude, ChatGPT). He stressed that if Trivy got a CVE, Light LLM, with its extensive reach, should also have one to ensure broad notification.

The panel acknowledged that the CVE record for Trivy did list Light LLM and TelnetX as affected products and linked to individual advisories, providing a mechanism for connecting the information. However, the core issue remained: in a situation spanning multiple package managers and affecting widely used downstream components, who has the ultimate authority to name the vulnerability, and how can information be effectively coordinated without CVEs for each critical affected component? Art Manion maintained that while "the poison is in the package," the question of whether each poisoned package constitutes a distinct "vulnerability" for CVE purposes remains complex.

Technical Deep Dive

▶ Watch: Malware campaigns: one CVE for all or per package? (18:20)

The core of the panel's technical discussion revolved around the interpretation and application of CVE rules, the capabilities of various vulnerability and malware tracking systems, and the nature of supply chain attacks themselves.

CVE Rule Interpretation:

The ambiguity of CVE rules 4.1.8 and 4.1.9 is central. While "general purpose deliberately malicious code" (like a standalone malware.exe) is explicitly excluded from CVE assignment, "products that have been modified to become malicious" – such as Trojan horses, backdoors, or supply chain compromises – may be assigned a CVE. This "may" clause grants CNAs significant discretion, leading to inconsistencies. For instance, the XZ Utils backdoor was classified under CWE-506 (Embedded Malicious Code), providing a clear justification for its CVE assignment by Red Hat, as it represented malicious code inserted into an otherwise legitimate utility. This contrasts with the Shai Hulud campaign, where the lack of a single, identifiable "vulnerability" or "upstream" source led to no CVEs being issued, relying instead on NPM's internal mechanisms and GitHub Security Advisories (GHSAs).

Vulnerability and Malware Tracking Systems:

The panel highlighted the diverse landscape of tracking systems, each with its strengths and limitations:

• CVEs: The most widely recognized and integrated into Vulnerability Management (VM) tools, Software Composition Analysis (SCA), and Security Information and Event Management (SIEM) systems. Its strength lies in its ubiquity for vulnerabilities.
• OSV (Open Source Vulnerability): A more flexible format designed for open-source vulnerabilities, capable of handling broader types of security issues, including those from malicious packages. It was mentioned as a potential alternative or supplement.
• GitHub Advisory Database (GHSAs): Curated by GitHub, this database publishes advisories for vulnerabilities and supply chain incidents, including specific malicious packages. Shelby Cunningham's role directly involves this. GHSAs were used extensively for Shai Hulud and for the downstream effects of Trivy.
• NPM Audit: A built-in command-line tool for Node.js projects that checks for known vulnerabilities in dependencies, including malicious packages. It was the primary alert mechanism for the Shai Hulud campaign.
• Go Vulnerability Database (pkg.go.dev) and PySec Database: Ecosystem-specific databases for Go and Python, respectively, which provided advisories for the Trivy and Light LLM/TelnetX compromises.

The challenge arises when these systems operate in silos. As David Welch pointed out, many organizations prioritize CVEs above all else. If a critical incident is only reported in an ecosystem-specific database, it may be missed by broader security operations.

Nature of Supply Chain Attacks:

The panel discussed various attack vectors:

• Backdoor Injection: As seen in XZ Utils, where malicious code (liblzma backdoor) was subtly introduced into a core utility. This is a direct modification of benign code.
• Account Compromise: In TJ Actions and Trivy, attackers gained control of legitimate maintainer accounts to publish malicious versions. This bypasses code review processes and directly injects malicious payloads into the distribution channel.
• Worm-like Propagation: Shai Hulud demonstrated a campaign where malware spread across hundreds of distinct NPM packages, often without a single upstream source. This makes traditional "patch the root" approaches difficult and raises questions about how to identify and track such a diffuse threat.

Challenges with CVE for Campaigns:

A significant technical hurdle for CVEs is the lack of a machine-readable way to group related incidents under a single campaign identifier. While descriptions can manually cross-reference other CVEs or advisories (as seen with Trivy listing Light LLM and TelnetX), there's no inherent, programmatic link. This becomes problematic for campaigns like Shai Hulud, where assigning individual CVEs to hundreds of affected packages would lead to "issue bankruptcy"—overwhelming CNAs and defenders with an unmanageable volume of IDs without clear aggregation.

Art Manion noted the historical context: CVE was designed for "enumeration," not necessarily for tracking complex, interconnected exposures or campaigns. The current system is more geared towards one vulnerability = one CVE.

Proposed Heuristic for CVE Assignment:

An audience member proposed a pragmatic heuristic for CVE assignment: "If the mitigation for the users, not for the owners of the code, is to change version, then it should probably have a CVE." This resonated with the panelists, particularly David Welch. This approach shifts the focus from the nature of the flaw (accidental vs. intentional) to the actionable response required by the defender. If the recommended action is a version change, a CVE provides the necessary signal for automated tools and operational workflows. This acknowledges that whether the unwanted behavior was an accidental bug or a malicious injection, the impact and the remediation step for the end-user are often the same: update or remove the affected component.

Demo / Proof of Concept

▶ Watch: Audience asks: incident response vs. vulnerability management (52:50)

This talk was a panel discussion and did not feature a live demo or proof of concept. Instead, the panelists engaged in a robust discussion, drawing upon real-world case studies and their extensive experience to explore the complex relationship between CVEs and supply chain compromises. The "demonstrations" were the detailed retrospective analyses of incidents like XZ Utils, TJ Actions, Shai Hulud, and Trivy, serving as concrete examples to illustrate the theoretical and practical challenges discussed.

Defensive Implications

▶ Watch: Heuristic: CVE if mitigation is version change (58:40)

The detailed discussion on CVEs and supply chain compromises carries profound implications for defenders, highlighting both current best practices and areas for urgent improvement.

1. Broaden Vulnerability Intelligence Sources: Relying solely on CVEs as the definitive source of vulnerability information is no longer sufficient. The Shai Hulud and Trivy cases demonstrate that critical malware campaigns and compromised packages may first, or even exclusively, be reported in ecosystem-specific databases like NPM audit, GitHub Security Advisories (GHSAs), OSV, PySec, or the Go vulnerability database. Defenders must integrate feeds from these diverse sources into their security operations to gain a comprehensive view of their exposure. David Welch's experience as an operator for 20 years underscores this: many organizations, especially those with limited resources, might miss critical alerts if they don't expand beyond CVEs.

2. Prioritize Automated Scanning and Tracking: Regardless of the source, automated tools are paramount. The panel stressed that defenders need automated signals. CVEs, when assigned, seamlessly integrate into existing Vulnerability Management (VM), Software Composition Analysis (SCA), and dependency scanning workflows. Caitlin Condon's account of the TJ Actions incident highlights how the CVE enabled rapid, automated alerting and response, which was "baked into the workflows." Organizations must ensure their tools can ingest and act upon information from multiple vulnerability intelligence feeds.

3. Implement Robust Software Bill of Materials (SBOM) Management: The complexity of supply chain attacks, particularly those with downstream effects like the Trivy compromise affecting Light LLM and TelnetX, necessitates granular visibility into software dependencies. An accurate and up-to-date SBOM allows organizations to quickly identify if they are using an affected component, regardless of whether it's directly identified by a CVE or through an ecosystem-specific advisory. This is crucial for understanding the blast radius of a compromise and prioritizing remediation.

4. Enhance Incident Response Playbooks for Account Compromise: The TJ Actions and Trivy incidents underscore the critical need for well-defined incident response playbooks that account for compromised maintainer accounts. These playbooks should outline procedures for verifying legitimate maintainers, coordinating with CNAs or platform providers (like GitHub), and rapidly issuing alerts, even when the primary maintainer is locked out. The panel's discussion on "who's responsible" when a maintainer is compromised points to the need for clear escalation paths and community involvement.

5. Advocate for CVE Program Evolution: The ongoing debate within the CVE program regarding the inclusion of malware and supply chain compromises indicates a need for evolution. Defenders should actively participate in relevant working groups, such as the CVE Research CNA Working Group (as pitched by Shelby Cunningham), to advocate for clearer rules, improved mechanisms for grouping related incidents (beyond manual references), and potentially a broader definition of "exposure" that encompasses malicious code injection. This collective voice is essential to shape the future of vulnerability identification to meet modern threats.

6. Adopt a "Change Version" Mitigation Strategy: The pragmatic heuristic proposed by an audience member—"if the mitigation for the users... is to change version, then it should probably have a CVE"—provides a clear actionable principle. Defenders should operate under the assumption that if a software component needs to be updated or replaced due to any security-impacting event, a clear identifier (ideally a CVE) facilitates this critical action. This aligns with the operator's need for a concrete step to ensure safety.

7. Prepare for Widespread, Diffuse Attacks: Campaigns like Shai Hulud, which affect numerous independent packages without a single upstream vulnerability, challenge traditional remediation strategies. Defenders must be prepared for scenarios where hundreds of individual advisories might be issued, requiring sophisticated tooling to aggregate, prioritize, and manage the remediation effort without falling into "issue bankruptcy." This emphasizes the need for advanced analytics and automation in vulnerability management.

Key Takeaways

• The CVE program faces an ongoing challenge in adapting its historical focus on "vulnerabilities" (accidental flaws) to the modern threat landscape of supply chain compromises and malware campaigns (intentional malicious code injection).
• While CVE rules traditionally exclude "general purpose malicious code" (4.1.8), the exception for "products that have been modified to become malicious" (4.1.9) provides a critical, albeit inconsistently applied, pathway for identifying backdoors and Trojan horses like the XZ Utils backdoor.
• Existing vulnerability management and notification platforms are heavily reliant on CVEs, making their inclusion crucial for broad awareness and automated defender response, even for cases that stretch the traditional definition of a vulnerability (e.g., TJ Actions compromise).
• The lack of a robust, universally adopted alternative for tracking malicious packages and malware campaigns often forces the security community to "retrofit" CVEs or rely on ecosystem-specific advisories (e.g., NPM audit, GitHub Security Advisories, PySec), which may not reach all defenders.
• For widespread malware campaigns affecting numerous distinct packages (like Shai Hulud), the current CVE model struggles with balancing individual identification against the risk of "issue bankruptcy" and lacking a programmatic way to group related incidents.
• A pragmatic heuristic suggests that if the primary user mitigation is to change the version of affected software, a CVE is likely appropriate, focusing on the actionable information needed by operators to ensure safety.

About the Speaker(s)

Art Manion is the Deputy Director at Tharros Labs and a respected member of the CVE board. With many years entrenched in CVE and CVD (Common Vulnerability Scoring System), he is a veteran in all aspects of vulnerability coordination and management, bringing a deep understanding of the program's history and rules.

Caitlin Condon serves as the VP of Research at VulnCheck, where her work focuses on initial access intelligence and emerging threat response. Her passion for the vulnerability space is evident, and she co-chairs the CVE program research working group, actively shaping the future of vulnerability identification.

David Welch is the Chief Architect at HeroDevs, bringing over 20 years of industry experience. He is deeply passionate about open-source software and security, leading the technical direction for programs that provide never-ending support for end-of-life open-source projects. His perspective as an operator and advocate for open source is crucial.

Shelby Cunningham has been a curator of the GitHub advisory database for five years. Her duties include reviewing vulnerability information for inclusion in the database, publishing information to the CVE list as part of GitHub's CNA responsibilities, and notably, responding to supply chain incidents where GitHub security advisories are published.