The Clock is Ticking: CRA Compliance at Scale

The Clock is Ticking: CRA Compliance at Scale

Speakers: Lisa Bradley, Product Security, Dell Technologies; Sarah Evans, Distinguished Engineer, Dell

Conference: FIRSTCON

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

Overview

The digital landscape is rapidly evolving, bringing with it an intricate web of regulatory challenges that demand a fundamental shift in how companies approach product security. Lisa Bradley, Product Security at Dell Technologies, and Sarah Evans, a Distinguished Engineer at Dell, delivered a compelling talk at FIRSTCON, "The Clock is Ticking: CRA Compliance at Scale," addressing the profound impact of the European Union's Cyber Resilience Act (CRA). This legislation, set to reshape the security requirements for all digital products sold within the EU, places unprecedented accountability on manufacturers for the security of their entire product lifecycle, from design to end-of-support, including all third-party and open-source components.

This talk unpacks Dell's strategic and operational response to the CRA, highlighting the complexities of achieving compliance at the scale of a global enterprise. Bradley and Evans detail the multi-faceted workstreams Dell has established to address the CRA's stringent demands, ranging from policy re-evaluation and rapid vulnerability reporting to comprehensive third-party risk management and the critical need for industry collaboration. The discussion also weaves in the emergent "AI reality," emphasizing how the accelerated discovery of vulnerabilities by AI tools further compounds the urgency and complexity of compliance.

The significance of this talk extends beyond mere regulatory adherence; it serves as a blueprint for any organization grappling with the increasing burden of securing a complex software supply chain. By sharing Dell's journey, the speakers illuminate the critical gaps in traditional product security practices and advocate for a collaborative, industry-wide approach, particularly through initiatives like the Open Source Security Foundation (OpenSSF). Their insights underscore that the CRA is not just another compliance hurdle, but a catalyst for systemic change in software security, demanding proactive engagement with upstream components and a new paradigm for demonstrating security due diligence.

Background

▶ Watch: EU CRA: Purpose, scope, and key compliance dates (2:00)

The EU Cyber Resilience Act (CRA) is a landmark regulation designed to enhance the cybersecurity of digital products across their entire lifecycle. As detailed by Lisa Bradley, its core objective is to ensure that products sold in the EU embody "good security practices." While many organizations, including Dell, already possess mature Secure Development Lifecycle (SDL) and vulnerability response practices, the CRA introduces specific, often more stringent, requirements that necessitate a re-evaluation of existing policies and operational models.

Key aspects of the CRA include:

• Secure by Design and Secure by Default: Mandating that security is integrated from the initial design phase and that products are secure out-of-the-box.
• Rapid Vulnerability Reporting: Establishing strict timelines for reporting actively exploited vulnerabilities or incidents to ENISA. Manufacturers must notify ENISA within 24 hours of becoming aware of an actively exploited vulnerability, provide a confirmed impact assessment within 72 hours, and notify again within 14 days of remediation.
• Product Identification and Scope: Requiring manufacturers to accurately identify which of their products are sold in the EU and will be subject to the regulation by the December 11th, 2024 full compliance deadline.
• Technical Documentation and CE Marking: Manufacturers must compile comprehensive technical documentation demonstrating compliance and affix the CE marking to their products.
• Product Support and End-of-Security-Support Life: A critical, and often challenging, requirement is for manufacturers to clearly state the end-of-security-support life for a product at the point of sale, with a minimum of five years from the last day of end-of-sales, and to provide security fixes for free during this period. This contrasts with traditional support models where extended support often incurs costs.
• Third-Party Risk Management (TPRM): The CRA significantly expands the liability of manufacturers to encompass all components within their products, including those from third-party suppliers and open-source software (OSS). This means a manufacturer is responsible for fixing vulnerabilities in components, even if the original supplier or open-source maintainer declines to do so.

Prior to the CRA, Dell had established robust programs for SDL, TPRM, and open-source management, including significant efforts around Software Bill of Materials (SBOM) following the US Executive Order. However, the CRA introduces a new "regulatory part" that fundamentally shifts liability and necessitates a deeper understanding of supplier security practices and open-source trustworthiness. The challenge is compounded by the fact that the CRA's interpretation is still evolving, leading companies like Dell to adopt "smart risk approaches" in the absence of complete clarity. Furthermore, the rapid advancements in Artificial Intelligence (AI), particularly its ability to quickly discover vulnerabilities, adds another layer of urgency and complexity to adhering to these strict new security mandates.

Key Findings

▶ Watch: CRA's shift in liability for third-party components (9:00)

The talk highlights several critical findings regarding the EU Cyber Resilience Act and its broader implications for product security:

• Fundamental Shift in Accountability: The CRA fundamentally changes the accountability landscape for manufacturers of digital products. Liability for security flaws, previously sometimes shared or externalized, now squarely rests with the manufacturer for all components within their product, including those from third parties and open-source projects. This necessitates a shift from merely "doing SDL" to "demonstrating compliance" through auditable processes and documentation.
• Operational Challenges of Rapid Reporting: The strict 24/72/14-day timelines for vulnerability notifications to ENISA present significant operational challenges, particularly for identifying actively exploited vulnerabilities and conducting rapid impact assessments, especially outside of standard business hours.
• Complexity of End-of-Security-Support Life: Defining and communicating the end-of-security-support life, coupled with the requirement for free security fixes for a minimum of five years post-end-of-sales, is a complex undertaking that clashes with traditional, often tiered, support models.
• Expanded Third-Party and Open Source Liability: Manufacturers are now directly responsible for addressing vulnerabilities in third-party and open-source components, even if the original maintainers are unwilling or unable to provide fixes. This forces enterprises to develop strategies for internal remediation or even forking of open-source projects.
• The AI Reality Exacerbates Risk: The rapid evolution of AI, particularly its capability for accelerated vulnerability discovery, significantly increases the pressure on manufacturers. Known exploitable vulnerabilities, whether in proprietary, third-party, or open-source code, become more easily discoverable, making CRA compliance even more critical and challenging.
• Industry Collaboration is Imperative: No single company, regardless of its size, can secure the entire upstream open-source supply chain alone. With over 90% of the world's products built on upstream open source (according to Sonatype), shared tools, standards, and collaborative efforts through organizations like the Open Source Security Foundation (OpenSSF) are essential to uplift the security posture of the entire digital ecosystem.
• Executive Buy-in Through Financial Impact: Gaining internal executive buy-in for extensive security overhauls requires articulating the financial consequences of non-compliance, specifically highlighting the significant fines associated with CRA violations, such as a "tier two fine" for not having a complete SBOM.

Technical Deep Dive

▶ Watch: OpenSSF's role in securing upstream open source (16:00)

Dell's approach to CRA compliance involves a multi-pronged strategy, encompassing internal process re-engineering and active external collaboration. Lisa Bradley outlined Dell's internal workstreams, each designed to tackle specific aspects of the CRA:

1. Policies and Standards: Dell recognized that its existing SDL controls, while robust for product security, needed to evolve into "product security compliance controls." This involved tightening policies around secure by design and secure by default, and establishing mechanisms to capture how product teams adhere to these new, auditable requirements.
2. Notifications: To meet the aggressive 24/72/14-hour reporting deadlines, a dedicated workstream focused on establishing rapid impact assessment processes and ensuring the right people and processes are in place for quick turnaround, even for incidents occurring outside business hours.
3. Product Identification: A seemingly simple task, but one that often proves challenging in large organizations. This workstream focuses on accurately identifying all products sold in the EU and determining which will still be on the market by the December compliance deadline.
4. Remedy/Assessment: This involves developing internal assessment mechanisms for product teams to evaluate their adherence to CRA requirements, identify gaps, and work towards remediation. Due to the evolving nature of CRA interpretations, Dell is employing "smart risk approaches."
5. Technical Documentation: A workstream dedicated to compiling all required technical documentation and ensuring proper attestations and CE markings are in place for compliant products.
6. Product Support: This is a particularly challenging area. Dell is working closely with its support organization to clearly define and communicate the "end of security support life" for products, ensuring that customers understand when free security fixes will cease, in line with the CRA's five-year minimum post-end-of-sales requirement.
7. Third-Party Risk Management (TPRM): This is the core focus of the talk, driven by the CRA's expanded liability. Dell is enhancing its TPRM program to assess supplier trustworthiness. This includes:

• Contractual Updates: Ensuring contracts with suppliers include clauses for robust security practices.
• Questionnaires: Distributing detailed security questionnaires to suppliers about their SDL and vulnerability response practices.
• Risk Rating: Developing a system to assign a risk rating to suppliers based on their security posture.
• Awareness and Decision-Making: Communicating supplier trustworthiness ratings back to Business Units (BUs) to inform decisions about supplier usage, potential switching, or implementing additional safeguards within Dell's own products to mitigate supplier risks.

For open-source software (OSS), the challenge is even greater due to less control and visibility. Dell is evaluating maintainer activity, CVE assignment, and the presence of basic vulnerability reporting mechanisms. The CRA's mandate that manufacturers are liable even if an OSS maintainer won't fix a critical, publicly known vulnerability has led Dell to consider forking and internally maintaining vulnerable OSS components. Interestingly, the speakers noted that advancements in AI make this previously "overwhelming" prospect seem "less overwhelming," as AI tools could potentially assist in identifying and implementing fixes.

Sarah Evans then elaborated on Dell's contribution to and leveraging of the Open Source Security Foundation (OpenSSF) to address these challenges at an industry level. OpenSSF acts as a "community accelerator," fostering collaboration on upstream open-source security. Dell's involvement aims to bring internal learnings to the community and, conversely, to adopt shared standards and tools developed by OpenSSF.

Key OpenSSF tools and initiatives mentioned:

• SALSA (Supply chain Levels for Software Artifacts): Focuses on securing build pipelines and providing evidence of secure build processes.
• Scorecard: A tool that can be run on repositories to produce a 1-10 rating of a project's security posture, evaluating factors like vulnerability reporting, maintainer activity, and secure development practices.
• Baseline Controls: Maps control activities to compliance frameworks, helping organizations demonstrate adherence to regulations like the CRA.
• Sigstore: A capability for signing code and models (e.g., those on Hugging Face), providing attestations of integrity and origin, crucial for verifying downloaded components before integration into products.
• Vulnerability Response Modernization: Addresses the challenge of coordinating vulnerability fixes in widely used open-source components without overwhelming maintainers, promoting collaboration among large enterprises to uplift the community.

The discussion also highlighted the integration of AI into these tools and practices. OpenSSF is exploring how its tooling can be "AI aware," enabling AI agents to leverage OpenSSF knowledge bases for software development and security. The concept of MLSecOps (Machine Learning Security Operations) emerged as critical for ensuring end-to-end model life cycle provenance, validating the integrity of AI models from training to fine-tuning and deployment, akin to DevSecOps for traditional software. This includes securing the foundational models and carrying attestations through the entire ML pipeline.

Demo / Proof of Concept

▶ Watch: Practical advice: Emphasize fines and AI's impact on compliance (30:00)

The talk "The Clock is Ticking: CRA Compliance at Scale" focused primarily on strategic, organizational, and collaborative approaches to navigating the EU Cyber Resilience Act. As such, it did not include a live technical demonstration or a proof of concept of a specific tool or exploit. Instead, the speakers detailed Dell's internal workstreams, policy adaptations, and engagement with industry initiatives like OpenSSF, illustrating their practical responses to the regulatory and technical challenges posed by the CRA.

Defensive Implications

▶ Watch: Securing open AI models: End-to-end model provenance (MLSecOps) (34:00)

The EU Cyber Resilience Act, as highlighted by Dell's comprehensive response, necessitates a proactive and multi-layered defensive strategy for any organization developing or selling digital products in the EU.

For product manufacturers and developers, key defensive implications include:

• Re-engineer SDL for Compliance: Go beyond traditional security controls to embed "product security compliance controls" into the SDL. This means not just doing security activities but ensuring they are documented, auditable, and demonstrably adhered to, reflecting a secure by design and secure by default philosophy.
• Establish Rapid Incident Response Capabilities: Implement robust 24/7 incident response processes to meet the CRA's stringent 24/72/14-hour notification deadlines for actively exploited vulnerabilities. This requires clear escalation paths, quick impact assessment capabilities, and direct reporting channels to authorities like ENISA.
• Comprehensive Product Lifecycle Management: Accurately identify all products falling under CRA scope, understand their full lifecycle, and, critically, clearly define and communicate their end-of-security-support life from the point of sale. Ensure mechanisms are in place to provide free security fixes for the mandated five-year minimum.
• Strengthen Third-Party Risk Management (TPRM): Elevate TPRM to a core compliance function. This involves:
• Updating supplier contracts to include CRA-specific security requirements and liability clauses.
• Implementing detailed security questionnaires to assess supplier SDL and vulnerability response maturity.
• Establishing a system for risk-rating suppliers and integrating this into procurement and product development decisions.
• Preparing for scenarios where manufacturers may need to internally patch or fork third-party components if suppliers fail to provide timely fixes.
• Proactive Open Source Software (OSS) Security: Given the high prevalence of OSS (over 90% of products), manufacturers must:
• Rigorously evaluate the trustworthiness of upstream OSS projects, assessing maintainer activity, vulnerability reporting practices (e.g., presence of a security email, CVE assignment), and project health.
• Develop internal capabilities for identifying and remediating vulnerabilities in OSS components, including the potential for internal patching or forking if upstream fixes are not available.
• Actively contribute to upstream OSS projects to improve their security posture, rather than solely consuming them.
• Integrate AI Security Across the Board: Recognize that AI tools accelerate vulnerability discovery. This implies:
• Leveraging AI for enhanced vulnerability detection in both proprietary and third-party code.
• Adopting MLSecOps principles for AI models, ensuring end-to-end model life cycle provenance from training data to deployment, including model signing (e.g., via Sigstore) and integrity validation.
• Anticipating and preparing for faster exploitation cycles due to AI-driven threat intelligence.
• Leverage Industry Collaboration: Actively participate in and adopt standards from communities like the Open Source Security Foundation (OpenSSF). Utilizing shared tools like Scorecard for evaluating OSS security posture, SALSA for secure build pipelines, and Sigstore for supply chain integrity reduces individual burden and uplifts collective security.
• Secure Executive Buy-in: Frame compliance efforts in terms of financial risk and potential fines (e.g., a "tier two fine" for an incomplete SBOM), as well as brand reputation and customer trust, to secure necessary resources and organizational alignment.

By adopting these defensive measures, organizations can not only meet the letter of the CRA but also significantly enhance their overall cybersecurity posture in an increasingly regulated and threat-laden environment.

Key Takeaways

• Accountability Shift: The EU Cyber Resilience Act fundamentally redefines accountability for digital product manufacturers, extending liability to all components, including third-party and open-source software, and mandating demonstrable security due diligence throughout the product lifecycle.
• Supply Chain as Core Risk: The software supply chain, particularly open-source components (comprising over 90% of products), is now a direct compliance and financial risk for manufacturers, requiring proactive engagement and remediation strategies even for externally maintained code.
• Collaboration Over Isolation: Individual company efforts to secure the vast open-source ecosystem are insufficient; industry-wide collaboration through organizations like the OpenSSF is essential for developing shared tools, standards (e.g., Sigstore, Scorecard), and best practices to uplift collective security.
• AI Accelerates Urgency: The rapid advancements in AI, especially its capability for quick vulnerability discovery, heighten the urgency for CRA compliance and necessitate integrating AI-aware security practices and MLSecOps principles across the product development and deployment lifecycle.
• From Doing to Demonstrating: Compliance requires a shift from merely implementing security practices to actively documenting, reporting, and demonstrating adherence to stringent regulatory requirements, including rapid vulnerability notifications and clear communication of security support lifecycles.
• Strategic Executive Engagement: Gaining executive buy-in for CRA compliance initiatives is crucial and best achieved by articulating the significant financial penalties for non-compliance and the potential impact on customer trust and brand reputation.

About the Speaker(s)

Lisa Bradley is a seasoned professional in Product Security at Dell Technologies, boasting over 13 years of experience in the field. Her extensive background includes previous roles at Nvidia and IBM. At Dell, she is responsible for managing a bug bounty program, contributing to Third-Party Risk Management (TPRM) with a focus on direct suppliers within Dell's products, and playing a key role in the company's AI vulnerability detection efforts, including participation in Project Glasswing. Her work frequently involves navigating the complexities of emerging regulations and their impact on product security.

Sarah Evans is a Distinguished Engineer in the Office of the CTO at Dell. Her work centers on applied security research, where she investigates industry trends and emerging challenges or opportunities that impact Dell's products and internal security posture. With a varied background, including 21 years as a veteran of the military and the Air National Guard, she brings a unique perspective and strong empathy for diverse stakeholders. Sarah is deeply passionate about upstream and open-source software security and represents Dell in the Linux Foundation's Open Source Security Foundation (OpenSSF), actively contributing to industry uplift initiatives.