From CVD to Secure Releases: Automating Security from Source to Releases

From CVD to Secure Releases: Automating Security from Source to Releases

Speakers: Vijay Sarvepalli (Software Engineering Institute), Christopher Cullen (CMU Software Engineering Institute)

Conference: FIRSTCON

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

Overview

In an era where software vulnerabilities are proliferating at an unprecedented rate, particularly with the advent of AI, the traditional model of Coordinated Vulnerability Disclosure (CVD) is proving insufficient. This pivotal talk at FIRSTCON, delivered by Vijay Sarvepalli and Christopher Cullen of the CMU Software Engineering Institute (SEI), explores the critical need to evolve CVD beyond mere disclosure. The core message is a call to action for the security community to embrace early patching and the automation of secure releases, transforming the reactive process of vulnerability reporting into a proactive, systemic approach that impacts the entire software supply chain.

The speakers highlight that while the discovery of vulnerabilities has become increasingly automated and efficient—often accelerated by AI-driven tools—the subsequent patching and deployment of fixes lag significantly. This creates a dangerous chasm, leaving software vulnerable for extended periods. CERT/CC, with its longstanding mission to reduce societal harm from software vulnerabilities, is spearheading research efforts to bridge this gap. Their work focuses on developing methodologies and tools to not only coordinate disclosures but also to actively facilitate patch creation and ensure these fixes are absorbed by packaging systems like NPM and PyPI, ultimately reaching end-users and dependent projects more swiftly and reliably.

This research aims to address the "Anthropos problem"—the human challenges in coordination and remediation—by formalizing a process that can eventually be guided by AI agents. Through real-world case studies, including vulnerabilities found in the open-source LLM serving framework SG Lang, Sarvepalli and Cullen demonstrate how CERT/CC is directly engaging with vendors, even writing and submitting patches, to ensure critical fixes are implemented. The talk provides a detailed blueprint for what effective, extended CVD looks like, emphasizing the essential principles for developing high-quality, deployable patches that secure the software ecosystem from source to release.

Background

▶ Watch: Talk overview: CERT/CC, vulnerability evolution, secure releases (0:30)

The CERT Coordination Center (CERT/CC), established in 1988 by DARPA, has a foundational mission: to identify, help remediate, and repair security vulnerabilities. Over the decades, its role has evolved from handling security incidents to focusing on vulnerabilities, with the ultimate goal of reducing societal harm due to insecure software. Traditionally, CERT/CC has served as a critical intermediary in the Coordinated Vulnerability Disclosure (CVD) process, connecting security researchers (referred to as "finders") with vendors who own the vulnerable products, and ultimately informing the public. This "three-player game" aims to ensure responsible disclosure, timely patching, and public benefit.

Despite these efforts, significant challenges persist in the vulnerability ecosystem. Manual vulnerability discovery and coordination are notoriously slow; research indicates it can take a deeply talented researcher approximately a month to find a good bug, 22 additional days to exploit it, and at least 90 days for coordination in a traditional, manual workflow. Compounding this, vulnerabilities, particularly in open-source software, exhibit an alarmingly long average lifetime—around four years. Even in highly active projects like Chromium or OpenSSL, the lifecycle of a vulnerability can be protracted. The mean time to fix a vulnerability is approximately 119 days, with a median of 267 days, underscoring the difficulty of patching.

These delays are often less about the technical complexity of the fix and more about coordination delays. Factors such as social networks, communication practices, and the maturity of a vendor's bug tracking infrastructure play a far more significant role than the technical severity of the problem. A three-line code fix, for instance, might still take six months to disseminate across the affected ecosystem. The speakers emphasize that bugs will always exist; the focus should shift from building "perfect software" to rapidly and sustainably responding when flaws are found and exploited.

The problem has been drastically exacerbated by the rise of Artificial Intelligence (AI). AI tools are capable of finding vulnerabilities at an unprecedented scale, generating thousands, and sometimes millions, of reports in open-source projects. The rate of CVE publication reflects this explosion, showing no signs of slowing down. This overwhelming volume makes it impossible for vendors to coordinate, patch, and resolve issues in a timely or comprehensive manner. The true challenge is no longer finding vulnerabilities, but fixing them throughout their entire lifecycle and ensuring updates reach all dependent products and packages, such as those within the vast and complex ecosystems of NPM and PyPI. Open-source projects, in particular, face immense pressure due to their widespread adoption; a simple expression calculator NPM project, for example, can have 28,000 downstream dependencies, making comprehensive remediation a monumental task. The "copy.fail" incident, where a known vulnerability with attack methods was practically impossible to implement across the supply chain, serves as a stark reminder of these systemic failures.

Recognizing these systemic issues, CERT/CC's research extends beyond traditional coordination. They are delving into systemic vulnerability research—identifying vulnerabilities that persist, are impractical to patch globally, or never fully disappear from the supply chain. Crucially, this talk focuses on their efforts to create patches early, working with researchers to develop fixes that vendors can readily absorb, and then helping to propagate these fixes to downstream dependencies. Early efforts included collaborating with GitHub on their security advisory framework and directly assisting with patching for projects like PPD and dnsmasq, learning valuable lessons about the practicalities of patch development within the embargo period and the challenges of engaging with diverse open-source maintainers.

Key Findings

▶ Watch: AI's impact on vulnerability growth and supply chain complexity (7:00)

The central finding of CERT/CC's current research is the imperative to expand the scope of Coordinated Vulnerability Disclosure (CVD) beyond mere publication to active, collaborative patch development and strategic influence on the software supply chain. This shift is a direct response to the escalating volume of vulnerabilities, particularly in the open-source and AI-driven landscapes, which overwhelm traditional remediation processes. The CERT/CC's approach involves not only identifying vulnerabilities but also actively assisting vendors, especially in resource-constrained open-source projects, by providing ready-to-implement patches.

This proactive stance led to the identification of four critical principles for effective patch development, which CERT/CC advocates for researchers and, increasingly, for the guidance of future AI agentic tools:

1. Fixes Security Vulnerabilities with Positive Test Cases: A patch must demonstrably resolve the reported security flaw. This requires a positive test case that proves the vulnerability can be exploited before the patch and is mitigated afterward. For open-source projects lacking robust testing infrastructure, this also presents an opportunity for the patch developer to introduce foundational test cases.
2. Does Not Break Existing Features with Negative Test Cases: Equally important, the patch must not introduce regressions or break existing, expected functionality. This necessitates negative test cases that confirm the software's original features remain intact after the patch is applied. The goal is to ensure that the vendor can adopt the fix without fear of disrupting user experience or core capabilities.
3. Maintains Developer's Coding Style: To maximize the likelihood of acceptance, a patch should adhere to the existing coding style and idioms of the project. As exemplified by the challenges with the dnsmasq project and its highly specialized developer, imposing an alien coding style can create resistance and delay adoption. The patch should integrate seamlessly, making it easier for maintainers to understand and trust the changes.
4. Impacts Adoption and Deployment: For a patch to be truly effective, its metadata and structure must facilitate its rapid absorption into the broader software supply chain. This means ensuring that CVEs (Common Vulnerabilities and Exposures) are properly formatted and linked to the affected products, allowing automated tools like NPM audit, pip audit, GitLab's audit systems, and Dependabot to quickly identify and propagate the fix. Without this, even a technically perfect patch can languish, requiring manual intervention by platform personnel and delaying widespread protection.

These principles serve as a rubric for human-driven patch development and, crucially, as guidance for training AI agentic tools like Code Mentor and Copilot. The talk notes that Code Mentor already incorporates the first three principles, albeit with slightly different terminology. The ultimate vision is a future where an AI-driven system, governed by a "Voltron" protocol, can manage the entire vulnerability remediation workflow, from patch creation to its secure journey through the supply chain, ensuring technical efficacy, feature integrity, style consistency, and broad deployment impact.

Beyond patch development, the case studies with SG Lang revealed systemic issues unique to open-source AI systems:

• Unknown Functionality Leading to Attack Surfaces: Features are often implemented without full awareness of the security implications, especially when combined with inherently insecure practices like pickle.loads.
• "Whack-a-Mole" Vulnerabilities: Similar vulnerabilities can manifest across different parts of a codebase, requiring repeated fixes for the same underlying issue.
• Precarious Coordination and Lack of Formal Escalation Paths: The informal nature of open-source development can lead to dropped communications, unaddressed reports, and disclosure without a corresponding patch, placing a significant burden on coordinators and reporters.

These findings underscore that while the technical aspects of patching can sometimes be minimal (e.g., a few lines of code for a CVSS 9.8 vulnerability), the surrounding coordination, communication, and supply chain integration are often the most formidable challenges.

Technical Deep Dive

▶ Watch: Research focus: systemic vulnerabilities and early patch creation (13:00)

The core of CERT/CC's practical application of extended CVD is demonstrated through two detailed case studies involving SG Lang, an open-source Large Language Model (LLM) serving framework. SG Lang is a significant project, having recently received over $400 million in funding and being widely adopted across various industries. It's designed to run diverse LLM models (e.g., Qwen, Deep Seek, Mistral) and is frequently exposed to the internet for user interaction, making its security posture critical.

The first case study focused on a series of pickle deserialization vulnerabilities. A pickle file in Python is a serialized representation of Python objects, essentially functioning as a "save state." However, the act of deserializing a malicious pickle file can lead to Remote Code Execution (RCE), as arbitrary code embedded within the file will be executed during the loading process. The official Python pickle documentation explicitly warns against using it with untrusted data, stating, "The module is not secure."

CERT/CC identified three distinct pickle deserialization vulnerabilities in SG Lang:

1. Multimodal Generation Module Vulnerability: SG Lang's multimodal generation module would automatically start a server that bound to all network interfaces without any authentication. This endpoint would then perform pickle.loads on any incoming data. An attacker could send a maliciously crafted pickle file to this unauthenticated endpoint, triggering RCE on the SG Lang server. The vulnerability was particularly insidious because error handling would only kick in after the malicious code had already executed.
2. Encoder Parallel Disaggregation System Vulnerability: Almost identical in nature to the first, this vulnerability existed within a different operational mode of SG Lang, the encoder parallel disaggregation system. It similarly involved an automatically started server performing pickle.loads on unauthenticated input, leading to RCE.
3. Crash Dump Replay Vulnerability (CERT/CC Discovery): During their investigation, CERT/CC discovered an additional vulnerability within a script designed to replay crash dump information. When SG Lang crashed, it would generate a pickle file containing crash data for later triage. The replay script used pickle.loads to process these files. While requiring local file system access to the crash dump folder (making exploitability lower than the network-exposed vulnerabilities), an attacker capable of placing a malicious pickle file in this location could still achieve RCE.

These pickle vulnerabilities highlighted systemic issues: the existence of unknown functionality creating attack surfaces, exacerbated by the use of an inherently insecure serialization method, and the "whack-a-mole" nature of fixing similar issues across different code paths. CERT/CC's suggested patch involved two key changes: fixing the exposed servers and replacing pickle.loads with msgpack, a safer and more robust serialization format. Despite this, vendor interaction was minimal, leading to disclosure without a direct vendor-provided patch. Interestingly, the open-source community independently mirrored CERT/CC's suggestions, eventually leading to the adoption of msgpack in some areas, but also demonstrating a breakdown in direct communication and a duplication of effort.

The second, and even more impactful, case study involved a GGUF RCE vulnerability in SG Lang, which was later assigned a CVSS score of 9.8 by CISA. This high-severity vulnerability gained significant public awareness. The issue resided in an insecure reranking endpoint that accepted GGUF model files. While the system was intended to sandbox these models, the sandboxing mechanism failed. Consequently, an attacker could embed malicious code within a GGUF file and send it to the reranking endpoint, resulting in its execution on the SG Lang server. Given SG Lang's frequent exposure to the internet, this presented a highly probable exploitation vector.

In this instance, CERT/CC again faced a lack of vendor response. Chris Cullen then proactively created and submitted a public pull request with a patch. This fix was remarkably simple, described as "barely a few lines of effort," requiring only a couple of hours to implement. The patch successfully addressed the CVSS 9.8 vulnerability, demonstrating that even critical security flaws can sometimes be resolved with minimal code changes when the problem is clearly identified and a well-crafted solution is provided. Cullen noted that he spent more time developing the proof of concept, testing, and researching concepts like Ginger 2 sandboxing than on writing the actual fix. This successful, rapid merge by the maintainers showcased the potential of collaborative, proactive patching when practical and when the maintainer community is engaged.

Demo / Proof of Concept

▶ Watch: Case Study: SG Lang and pickle deserialization vulnerabilities (24:30)

While the talk did not feature a live, interactive demonstration in the traditional sense, Christopher Cullen's segment served as a comprehensive "real-world example" or proof of concept for CERT/CC's extended CVD workflow. This section meticulously walked the audience through the practical application of their research, illustrating how CERT/CC moves beyond mere vulnerability disclosure to active patch development and advocacy within the open-source ecosystem.

Cullen's presentation of the SG Lang case studies—the pickle deserialization vulnerabilities and the GGUF RCE—effectively acted as a step-by-step demonstration of CERT/CC's proactive engagement. He detailed:

1. Vulnerability Discovery and Analysis: Explaining the nature of pickle files, their inherent insecurity, and the specific mechanisms by which RCE could be achieved in SG Lang's multimodal generation module, encoder parallel disaggregation system, and crash dump replay script. He also outlined the GGUF RCE, detailing the insecure reranking endpoint and the failure of sandboxing.
2. Vendor Engagement and Challenges: Describing the repeated attempts to coordinate with the SG Lang maintainers, the lack of initial response, and the implications of this communication breakdown. This highlighted the "Anthropos problem" and the precarious nature of coordination in open-source projects.
3. Patch Development and Suggestion: For the pickle vulnerabilities, CERT/CC developed and suggested a patch that involved replacing the insecure pickle.loads with msgpack and addressing exposed server configurations. This demonstrated their commitment to providing concrete solutions, not just problem statements.
4. Proactive Patch Submission: For the high-severity GGUF RCE (CVSS 9.8), Cullen himself crafted and submitted a public pull request. He explicitly noted that this patch was "barely a few lines of effort" and required "only a couple of hours" to implement, effectively proving that significant security improvements can sometimes be achieved with minimal technical lift when a coordinated effort is made. The successful and rapid merger of this pull request by the SG Lang maintainers served as a clear validation of CERT/CC's approach.
5. Lessons Learned on Impact: The entire narrative underscored how CERT/CC's intervention, including the discovery of additional vulnerabilities (like the crash dump replay issue) and the public submission of patches, led to broader security gains, even in the face of communication challenges.

This section effectively served as an extended proof of concept, illustrating the practicalities, successes, and challenges of CERT/CC's evolving mission to not only disclose but also actively contribute to the remediation of software vulnerabilities, particularly in the complex and rapidly expanding landscape of open-source AI. It showed the current "manual" workflow, which is a critical step towards informing the future development of AI-agentic systems for patch generation and deployment.

Defensive Implications

▶ Watch: Q&A: Risks and benefits of AI agents for patch creation (34:30)

The insights presented in this talk offer critical defensive implications for various stakeholders across the software supply chain, from developers and maintainers to security teams and deployers. The pervasive and accelerating nature of vulnerabilities, particularly in open-source AI systems, necessitates a fundamental shift in defensive strategies.

For Open-Source Project Maintainers and Developers:

• Prioritize Secure Coding Practices: Explicitly avoid inherently insecure serialization methods like Python's pickle.loads for untrusted or external data. Opt for safer alternatives such as msgpack.
• Implement Robust Sandboxing: For any functionality that processes external or user-provided models (e.g., GGUF files), ensure that robust sandboxing mechanisms are in place and thoroughly tested. The SG Lang GGUF RCE demonstrated that even intended sandboxing can fail, leading to critical vulnerabilities. Research and utilize established sandboxing techniques, such as those related to Ginger 2 sandboxing.
• Improve Communication and Bug Tracking: Establish clear, formal escalation paths and maintain responsive communication channels for vulnerability reports. A mature bug tracking infrastructure is crucial to prevent dropped communications and ensure timely remediation.
• Embrace Collaborative Patching: Be open to receiving and reviewing patches from security researchers and coordinators. Leverage external expertise to reduce the burden on internal resources, especially in resource-constrained open-source projects.
• Adopt Patch Principles: Developers should internalize the four patch principles: ensure fixes have positive and negative test cases, maintain coding style, and ensure proper CVE formatting for downstream consumption.

For Security Teams and Coordinators (like CERT/CC):

• Extend CVD Scope: Beyond disclosure, actively engage in patch development and advocacy. This proactive stance can significantly reduce vulnerability lifetimes, especially for high-impact flaws in widely used software.
• Focus on Systemic Issues: Identify and address underlying architectural or design flaws that lead to "whack-a-mole" vulnerabilities, rather than just patching individual instances.
• Guidance for AI Agents: Develop clear, human-derived principles for AI agentic tools that generate patches. These agents must be trained to not only fix vulnerabilities but also to produce high-quality, maintainer-friendly code that doesn't introduce regressions or deviate from project style. The "Voltron protocol" concept highlights the need for structured, state-aware AI-driven remediation workflows.

For Deployers and Users of Open-Source Software:

• Leverage Supply Chain Security Tools: Actively utilize tools like NPM audit, pip audit, and Dependabot to continuously monitor dependencies for known vulnerabilities (CVEs). Ensure these tools are integrated into CI/CD pipelines and regularly acted upon.
• Understand Open-Source Risks: Be aware of the unique challenges in open-source vulnerability management, including potential delays in patching and coordination breakdowns. This awareness should inform risk assessments and patch management strategies.
• Demand Secure Releases: Advocate for vendors and maintainers to adopt secure release practices that prioritize timely patching and effective communication of security updates.

The talk underscores that the chaotic nature of vulnerability management in the AI era demands ad hoc work and seizing opportunities for "smaller efforts" that can yield "large dividends." By adopting a more holistic, collaborative, and eventually automated approach to security from source to release, the industry can hope to regain control over the escalating vulnerability landscape and mitigate societal harm.

Key Takeaways

• Evolving CVD is Critical: The traditional model of Coordinated Vulnerability Disclosure is insufficient for the current landscape, especially with the rapid, AI-driven proliferation of vulnerabilities. CVD must evolve beyond mere disclosure to actively facilitate early patching and secure release management.
• Open Source Faces Unique Challenges: Open-source projects, despite their widespread adoption, are often resource-constrained and lack formal escalation paths, leading to significant delays in patching, communication breakdowns, and the persistence of known vulnerabilities.
• Proactive Patching is Essential: Security coordinators and researchers should consider developing and submitting high-quality patches directly to vendors. Even minimal code changes (e.g., a few lines of code for a CVSS 9.8 RCE) can have a profound impact when effectively coordinated and accepted.
• Quality Patch Development Requires Specific Principles: Effective patches must demonstrably fix vulnerabilities (with positive test cases), avoid breaking existing features (with negative test cases), adhere to the developer's coding style, and ensure proper formatting for rapid adoption by supply chain tools like NPM audit and Dependabot.
• Insecure Serialization and Sandboxing are Key Vectors: Developers must avoid inherently insecure practices like Python's pickle.loads for untrusted data and implement robust, thoroughly tested sandboxing for any user-provided or external code/models (e.g., GGUF files).
• AI Agents Will Play a Future Role: The future of vulnerability remediation will likely involve AI agentic systems to automate patch generation and deployment. However, these agents must be meticulously guided by human-derived principles to ensure the quality, integrity, and deployability of their generated code.

About the Speaker(s)

Vijay Sarvepalli and Christopher Cullen are affiliated with the CMU Software Engineering Institute (SEI), a federally funded research and development center sponsored by the U.S. Department of Defense. Both speakers are actively involved in the CERT Coordination Center (CERT/CC), a division of the SEI. Their work focuses on the critical mission of coordinated vulnerability disclosure and advancing research into how this process can be extended to better address the challenges of modern software security. Vijay Sarvepalli is a key figure in driving the strategic vision for CERT/CC's research into systemic vulnerabilities and secure release automation. Christopher Cullen brings hands-on experience, having directly engaged with recent vulnerability cases and patch development efforts, including the detailed case studies presented in this talk. Together, they represent the leading edge of research aimed at transforming vulnerability management into a more proactive, automated, and impactful discipline.