CRA vulnerability reporting with Daniel Thompson

The podcast discusses the implementation and implications of the Cyber Resilience Act (CRA), focusing on manufacturers' obligations to report actively exploited vulnerabilities in products with digital elements, including those long in service. Reporting must occur within 24 hours of discovery via a centralized platform, followed by interim and final reports, along with user notifications - though embargoes may be requested. The CRA's requirements center on verified exploitation rather than theoretical vulnerabilities, necessitating clear evidence such as log data, and place responsibility on the final product manufacturer, though supply chain vendors face growing pressure to provide compliance documentation like SBOMs and declarations of conformity.

Challenges include the platform's reliance on a manual 30-field web form instead of an automated API, concerns over delayed public disclosure due to embargoes, and difficulties enforcing compliance across EU member states. The definition of "exploited vulnerability" remains fluid, with potential updates through future implementing acts. Organizations are encouraged to adopt practices like VEX (Vulnerability Exploitability eXchange) to document when vulnerabilities do not affect their products, while still prioritizing fixes for active threats. Memory safety issues are highlighted as a growing industry concern, contributing to a surge in vulnerabilities, with memory-safe programming languages presented as part of the solution, though no single language is endorsed.

Long-term compliance requires free security updates for the product's lifetime, retention of documentation for up to 10 years, and preparation for evolving regulatory expectations beyond the EU, as similar rules emerge in Japan, Singapore, and India. Open-source projects are not mandated to report but may do so voluntarily, and while non-compliance carries no direct fines, it risks scrutiny. Companies are advised to prepare early, as compliance processes align with broader regulatory standards. The discussion also touches on the tension between security and performance in software design, the limitations of "security theater" practices, and the need for industry-wide adaptation to more rigorous, transparent, and accountable vulnerability management.

• What if you had to report an actively exploited vulnerability in your software within 24 hours?

  • Move: Set up a dedicated incident response workflow with automated detection (e.g., log scanning for IoCs) and a pre-filled 30-field web form template for the EDISA platform, stored in an internal dashboard accessible 24/7.
  • Why Now?: The CRA's 24-hour reporting clock starts at discovery - delays due to manual processes risk non-compliance; with the law already in effect for in-service products, solo devs must act before an incident occurs.
  • Expected Upside: Avoid regulatory penalties, maintain market access in the EU, and build user trust through rapid, compliant response - turning a legal burden into a credibility signal.

• What if your open-source dependency gets exploited, but your product doesn't use the vulnerable code path?

  • Move: Implement a VEX (Vulnerability Exploitation Statement) generator that auto-documents unaffected status using SBOM analysis (e.g., via Syft + Grype), then store signed VEX files in version control with a monthly audit reminder.
  • Why Now?: With CRA pushing supply chain accountability, downstream customers and regulators may soon demand proof you're not blindly reporting or ignoring risks - especially as definitions of "exploited" evolve post-2027.
  • Expected Upside: Prevent redundant reporting, reduce noise in compliance systems, and position your project as a responsible steward - gaining trust from enterprise users and partners.

• What if you're a solo developer selling software in the EU and must provide free security updates for life?

  • Move: Refactor your product's update mechanism to support automated, low-effort patching (e.g., modular design with isolated components), and create a public roadmap committing to 10-year update retention with archived releases on a static site.
  • Why Now?: The CRA's lifetime update requirement takes full effect by December 2027, and early preparation avoids technical debt; solo operators who design for maintainability now can turn compliance into a sustainable business model.
  • Expected Upside: Differentiate your product as secure and long-term supported, attract risk-averse customers (e.g., public sector, healthcare), and align with global trends (Japan, Singapore, U.S.) that may adopt similar rules.

• Implement a 24-hour vulnerability reporting process using the EDISA platform for actively exploited vulnerabilities, including preparation of staff and systems to meet the strict deadline.
• Develop and maintain VEX (Vulnerability Exploitation Statement) records for dependencies to document when vulnerabilities exist but do not affect your product, reducing redundant reporting and proving compliance.
• Designate an authorized representative within the EU early to control jurisdiction and ensure timely handling of legal and regulatory communications, avoiding random national enforcement assignments.
• Establish internal procedures to distinguish between exploitable vs. theoretical vulnerabilities, focusing reporting only on those with verifiable indicators of compromise to avoid over-reporting.
• Begin generating and storing Software Bill of Materials (SBOMs) for your products now, even if not yet mandatory, to prepare for future compliance and supply chain demands.