Protecting Customers Through Smarter OSS Management

Protecting Customers Through Smarter OSS Management

Speakers: Lisa Bradley (Product Security Leader, Dell Technologies); Patricia Tarro (Open Source Security and Dependency Management Leader, Dell Technologies)

Conference: FIRSTCON

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

Overview

In an era defined by escalating software supply chain attacks and increasing regulatory scrutiny, Lisa Bradley and Patricia Tarro from Dell Technologies delivered a compelling talk at FIRSTCON, outlining Dell's mature and evolving strategy for managing open source software (OSS) dependencies. Their presentation, "Protecting Customers Through Smarter OSS Management," detailed a comprehensive approach that moves beyond basic vulnerability scanning to incorporate a multifaceted trustworthiness scoring system, proactive dependency management, and a "shift-left" security philosophy. The talk highlighted how Dell is leveraging internal platforms and methodologies to not only secure its own products but also to empower customers with greater transparency and self-service capabilities regarding software components.

The speakers emphasized the critical shift from reactive vulnerability response to a more predictive and holistic risk management framework, driven by significant industry events like Log4Shell and emerging regulations such as the EU Cyber Resilience Act (EU CRA). They shared Dell's journey in building a centralized Dependency Management Platform (DMP), developing a "Green Zone" concept for pre-approved OSS, and integrating diverse security data into a unified Project 360 product risk dashboard. This advanced methodology aims to ensure that Dell's products meet stringent security standards while navigating the complexities of an increasingly open source-reliant and AI-driven development landscape.

The core message underscored the imperative for organizations to gain deep visibility into their software components, assess the trustworthiness of open source projects and suppliers, and automate security practices throughout the entire product lifecycle. Bradley and Tarro provided invaluable insights into operationalizing these concepts within a large enterprise, demonstrating how strategic investment in dependency management can significantly enhance customer protection and maintain regulatory compliance in a rapidly evolving threat environment.

Background

▶ Watch: EU CRA's impact on supply chain accountability (3:30)

The modern software landscape is fundamentally built upon open source components, offering immense benefits in terms of innovation, speed, and cost-effectiveness. However, this reliance also introduces significant security challenges, particularly concerning the software supply chain. As Lisa Bradley noted, supply chain attacks "doubled in 2025" (referring to a statistical projection likely for a prior year, but emphasizing the trend), underscoring a pervasive fear: "can you actually trust that code that's written by others?" The speakers highlighted that the popularity of an open source package no longer equates to its inherent safety, forcing organizations to critically evaluate the trustworthiness of every dependency.

Historically, organizations often focused primarily on licensing compliance for open source components. However, transformative events like the Log4Shell vulnerability in late 2021 served as a stark catalyst, exposing the profound security implications of deeply embedded and widely used open source libraries. Patricia Tarro explained that Log4Shell forced Dell to pivot its software composition analysis (SCA) tool usage from primarily licensing to comprehensive vulnerability identification and management. This incident accelerated Dell's journey to mandate detailed software inventories (internal term) and Software Bills of Materials (SBOMs) (external/customer-facing term) across all product teams.

Beyond the immediate threat landscape, regulatory pressures are rapidly escalating. The EU Cyber Resilience Act (EU CRA) was frequently cited as a significant driver for enhanced open source security practices. Bradley explained that while open source maintainers are not directly subject to EU CRA, manufacturers selling products into the EU are 100% accountable for the security of all components within their products, including open source and third-party elements. This means manufacturers can no longer "shift off that blame" if a third-party component reaches end-of-security-support life prematurely or lacks adequate security practices. This mandate necessitates a proactive approach to vetting and managing open source dependencies, pushing manufacturers to demand higher security standards from maintainers and potentially even reconsidering the use of untrustworthy components. The problem exists because the traditional ad-hoc consumption of open source, combined with a lack of standardized security practices among maintainers and insufficient visibility within large enterprises, creates a fertile ground for vulnerabilities and supply chain risks.

Key Findings

▶ Watch: Log4Shell as catalyst for Dependency Management Platform (12:00)

Dell Technologies has made significant strides in transforming its open source security posture, driven by both internal initiatives and external pressures. The core findings and contributions presented by Bradley and Tarro revolve around a holistic and proactive dependency management framework:

1. Centralized Dependency Management Platform (DMP): Dell has established a proprietary platform that serves as the "source of truth" for all software components—proprietary, third-party supplier, and open source. This platform enables comprehensive inventory management, tracking both direct and transitive dependencies, and associating critical metadata like supplier risk information and trustworthiness scores. This centralized approach moves Dell from reactive vulnerability scanning to continuous, proactive monitoring.

1. Open Source Trustworthiness Scoring: A key innovation is Dell's adaptation of the OpenSSF Scorecard into a "Dell-atized" trustworthiness scoring system. This formulaic approach evaluates open source projects based on objective criteria such as the presence of vulnerability reporting mechanisms, defined triage processes, patching history, CVE assignment, clear vulnerability process documentation, and the maintainer's time-to-address vulnerabilities. Critically, it also considers factors like end-of-security-support life (EoL), community activity, security testing practices, and even the adoption of AI for vulnerability hunting (e.g., Linux Foundation's Mythos). This score is designed to inform product teams' decisions on component usage.

1. The "Green Zone" Concept: To "shift left" and enable developers to make secure choices upfront, Dell introduced the "Green Zone." This internal concept designates a repository of pre-vetted and assessed open source components. Developers are encouraged to source from this zone, where components have already undergone security and licensing reviews. If a component is not in the Green Zone, it undergoes an evaluation process (the "Gray Zone") before potential inclusion, ensuring that security and legal considerations are addressed before widespread adoption.

1. Customer-Facing SBOMs and Transparency: Dell has committed to providing customer-facing SBOMs for its products, driven by customer demand and contractual requirements, and accelerated by executive orders (though the focus later shifted from compliance to vulnerability management). These SBOMs are standardized through the DMP, with internal component names and NDA-protected information sanitized or redacted, while openly listing open source vulnerabilities. The development of the PIVIK tool, initially for account managers and soon for customers, aims to provide self-service vulnerability impact assessment for Dell products.

1. Holistic Product Risk View (Project 360): Dell has integrated various security metrics into a unified dashboard called Project 360. This dashboard provides a comprehensive "overall product risk viewpoint" by combining data from Vulnerability Response (VR) performance (SLOs, fix rates), Secure Development Lifecycle (SDL) compliance (control pass rates), open source trustworthiness scores, supplier trustworthiness scores, and even internal component trustworthiness. This initiative breaks down traditional silos, allowing business and product teams to prioritize the biggest risks holistically.

Technical Deep Dive

▶ Watch: The 'Green Zone' concept for pre-approving open source (23:00)

Dell's strategy for managing open source software dependencies is built upon a sophisticated technical architecture and a set of defined processes that span the entire product development lifecycle. At its heart is the Dependency Management Platform (DMP), which acts as the central repository and "source of truth" for all software components. This platform ingests inventories from various Software Composition Analysis (SSCA) tools used by product teams, capturing both direct and transitive dependencies. The DMP is designed to standardize the identification of open source components, a persistent challenge in large organizations.

The trustworthiness scoring mechanism is a critical technical component. Dell adapted the OpenSSF Scorecard and "Dell-atized" it, integrating proprietary criteria. This involves a mathematical formula that calculates a score based on:

• Vulnerability Reporting: Presence of an email or clear mechanism for reporting vulnerabilities.
• Triage and Patching: Evidence of defined triage processes and consistent patching.
• CVE Assignment: Whether the project assigns CVEs for identified vulnerabilities.
• Documentation: Clear documentation of their vulnerability handling processes.
• Response Time: Utilizing AI and intelligence to measure how long maintainers take to address vulnerabilities.
• End-of-Security-Support Life (EoL): Given the lack of a common industry standard, Dell assesses EoL by looking at community activity, update frequency, and security update releases.
• Security Testing: What kind of testing practices are in place.
• AI for Testing: Whether AI tools (e.g., Linux Foundation's Mythos preview) are being used to test the open source code.
• Community Health: General health and activity of the project community.

This score is continuously updated and integrated into product-level assessments, providing an average trustworthiness score across a product's entire open source footprint.

The "Green Zone" concept is a practical application of the trustworthiness score, designed to shift left security decisions. Developers are encouraged to pull components from this pre-vetted repository. If a component is requested outside the Green Zone (entering the "Gray Zone"), it undergoes a thorough evaluation covering its trustworthiness score, licensing implications (legal review), and general security hygiene. This metadata is then associated with the component in the repository, enabling developers to make informed choices early in the development process.

Dell's commitment to transparency is evident in its SBOM generation process. While internal inventories serve Dell's operational needs, customer-facing SBOMs (referred to as ESBOMs) are standardized through the DMP. This process involves sanitization and redaction of sensitive information, such as internal component names or details covered by NDA, while ensuring that open source components and associated vulnerabilities are clearly disclosed. Dell has also automated the publication of these SBOMs to product support pages, making them accessible to privileged customers, often under NDA.

For post-release vulnerability management, Dell developed the PIVIK tool. This internal UI allows account managers to quickly check if Dell products are impacted by publicly known vulnerabilities, leveraging the centralized inventory data. The future vision for PIVIK is to extend this capability directly to customers, enabling them to self-serve and assess their own exposure, recognizing that customers often already know which open source components Dell uses.

The Secure Development Lifecycle (SDL) at Dell incorporates specific controls for dependency management. Product teams must demonstrate that they:

1. Source components from a "safe place" (the Green Zone).
2. Maintain accurate inventory.
3. Are aware of and address vulnerabilities.
4. Ensure components are still in security support.
5. Pass self-assessments against these controls on every release.

Finally, the Project 360 dashboard represents a significant architectural integration. It pulls data from disparate systems—Vulnerability Response tracking tools (measuring SLOs), SDL compliance systems, the DMP (for open source and supplier trustworthiness), and internal component assessments. By aggregating these metrics, Project 360 provides a unified, release-level product risk view, allowing leadership to identify and prioritize the highest areas of risk (e.g., a product with poor vulnerability response, low open source trustworthiness, or failing SDL controls). The future evolution of this system aims for a "semantic network of dependencies," extending risk assessment beyond software to include hardware, crypto, and AI components, and incorporating contextual risk based on a component's function within the product (e.g., logging vs. customer data storage).

The speakers also touched upon the disruptive impact of AI on the open source landscape. They noted that AI can drastically accelerate the exploitation of vulnerabilities, making proactive and predictive security even more critical. AI tools like Mythos can analyze inventories to provide better vulnerability findings. Dell's internal CodeGuardian initiative, which focuses on secure AI-driven code development, also needs to account for the open source components AI might implicitly use or generate, ensuring these are properly inventoried and assessed for vulnerabilities.

Demo / Proof of Concept

▶ Watch: Holistic product risk viewpoint dashboard (30:00)

While no live technical demonstration was performed during the talk, Lisa Bradley and Patricia Tarro provided conceptual overviews and practical examples of tools and dashboards that function as Dell's internal "proofs of concept" for their dependency management strategy.

The PIVIK tool was presented as a key practical implementation, serving as a user interface for account managers to quickly determine the impact of publicly known vulnerabilities on Dell products. This tool, born out of the overwhelming inquiry volume during Log4Shell, demonstrates Dell's ability to leverage its centralized dependency inventory to provide rapid, transparent, and actionable information regarding product security. The future vision to make PIVIK customer-facing further underscores its role as a self-service proof of concept for vulnerability transparency.

Similarly, the Project 360 dashboard was described as a comprehensive visualization tool that integrates various security metrics—including open source and supplier trustworthiness scores, vulnerability response performance, and SDL compliance—into a single, holistic product risk view. This dashboard serves as an internal proof of concept for consolidating disparate security data, enabling leadership to make data-driven decisions about risk prioritization across Dell's vast product portfolio. These tools, though not demonstrated live, represent the tangible output and operationalization of Dell's sophisticated dependency management framework.

Defensive Implications

▶ Watch: Q&A: Strategies for untrustworthy components (Fund, Fork, Replace) (36:50)

The detailed insights shared by Dell Technologies offer several critical defensive implications for organizations grappling with open source and supply chain security:

1. Establish a Centralized Dependency Management Platform: Organizations must build or adopt a platform that serves as a single source of truth for all software components. This platform should track direct and transitive dependencies, integrate with SCA tools, and enable continuous monitoring for newly identified vulnerabilities. Without a clear inventory, securing what you use is impossible.

1. Implement a Trustworthiness Scoring System: Move beyond basic vulnerability counts. Develop a systematic approach to assess the trustworthiness of open source projects and third-party suppliers. Criteria should include vulnerability disclosure practices, patching cadence, community health, security testing, and adherence to security support timelines. Adapt existing frameworks like OpenSSF Scorecard to your organization's specific needs.

1. Shift Left with a "Green Zone" Strategy: Proactively vet and approve open source components before they are widely adopted by development teams. Create a curated repository of "Green Zone" components that meet predefined security and licensing criteria. This empowers developers to make secure choices upfront, reducing remediation costs and risks later in the development cycle.

1. Prioritize Vulnerabilities Contextually: Not all vulnerabilities carry the same risk. Implement a system that prioritizes vulnerabilities based on their context within the product—where the component is used (e.g., logging vs. critical data handling), the criticality of the product itself, and the potential impact of exploitation. This allows for smarter allocation of remediation resources.

1. Embrace and Prepare for Regulatory Accountability: Understand and prepare for emerging regulations like the EU Cyber Resilience Act (EU CRA). These regulations shift the burden of proof for software security onto manufacturers, requiring demonstrable security practices for all components, regardless of origin. This will necessitate stringent vetting of open source and supplier components, including clear definitions of end-of-security-support life.

1. Automate and Integrate Security Throughout the SDLC: Integrate security tools (SCA, SAST, DAST) and processes into the CI/CD pipeline. Automation is essential for scaling security efforts in large organizations and for ensuring that security checks are performed consistently and early. This includes programmatically opening tickets for newly identified vulnerabilities in vulnerability response tracking tools.

1. Provide Customer-Facing SBOMs and Transparency: Proactively generate and provide Software Bills of Materials (SBOMs) to customers. Standardize the format and content, ensuring sensitive internal details are appropriately redacted while maintaining transparency about open source components and known vulnerabilities. Develop self-service portals (like Dell's planned PIVIK expansion) to empower customers with information about their product's security posture.

1. Leverage AI for Enhanced Security: Recognize the dual impact of AI. While AI can accelerate exploitation, it also offers powerful capabilities for vulnerability hunting, code analysis (e.g., Mythos), and predictive security. Organizations should invest in AI-driven security tools and ensure that AI-generated code components are also subject to rigorous inventory and vulnerability assessment processes.

1. Develop a Holistic Product Risk View: Break down organizational silos between security functions (e.g., SDL, vulnerability response, open source management). Create unified dashboards (like Project 360) that provide a comprehensive, cross-domain view of product risk, enabling leadership to make informed, strategic decisions.

Key Takeaways

• You cannot secure what you do not inventory. Comprehensive and accurate inventorying of all software components (proprietary, open source, third-party) is the foundational step for any effective security program.
• Open source risk extends beyond CVEs to maintainer trustworthiness. Evaluating the security practices, responsiveness, and community health of open source projects is as crucial as scanning for known vulnerabilities.
• Automation is required to scale security efforts. Manual processes are insufficient for managing dependencies and vulnerabilities in complex, large-scale development environments.
• Regulations like the EU CRA are accelerating accountability. Manufacturers are now legally responsible for the security of all components in their products, driving a fundamental shift in how open source and supplier dependencies are managed.
• Security frameworks must continuously evolve with AI. The rapid advancement of AI technologies impacts both attack capabilities (faster exploitation) and defense strategies (AI-driven vulnerability hunting and predictive security).
• Shifting left and proactive measures are paramount. Making informed security decisions early in the development lifecycle and continuously monitoring dependencies is more effective and less costly than reactive remediation.

About the Speaker(s)

Lisa Bradley is a Product Security Leader at Dell Technologies, with approximately 13 years of experience focused on product security. Her responsibilities include overseeing Dell's Product Security Incident Response Team (PERT), the bug bounty program, and dependency management. She is also currently responsible for AI vulnerability hunting as part of Project Glasswing. Prior to joining Dell, Lisa held roles at Nvidia and IBM and has been a long-standing member of the FIRST community.

Patricia Tarro is the Open Source Security and Dependency Management Leader at Dell Technologies. Having been with Dell for nearly 13 years, originally through EMC, Patricia's journey into security focused specifically on open source management and security, which later evolved into broader dependency management. She plays a key role in developing and implementing Dell's strategies for managing the security of open source and third-party components.