Why CRA Compliance Must Be Verified Against the Shipped Binary

· Original article ↗

Summary

The article argues that CRA compliance claims must be checked against shipped software, not paperwork alone, and recommends artifact-level evidence reports to identify gaps and support reporting and remediation.

Key points

  • The article says manufacturers have had to report actively exploited vulnerabilities and severe incidents in products on the EU market since Sept. 11, 2026; full CRA application follows Dec. 11, 2027.
  • Build-system SBOMs can miss statically linked, vendored, and repackaged components; analysis of the shipped binary can reveal components and hardening gaps.
  • The recommended evidence report classifies each requirement as supported, adverse, or not assessable from a binary, and records the exact release, version, and SHA-256 hash.
  • An anonymized appliance assessment found 12,263 components, 1,430 distinct CVEs, nine vulnerabilities listed in CISA’s KEV catalog, and 1,976 binaries without ASLR.
  • The appliance also shipped a shared cleartext private key and certificate, used cleartext FTP for its primary update endpoint, and ran an operating system that reached end of life in June 2024.
  • The release closed 351 vulnerability instances and introduced 36 compared with its prior version; the article says KEV-listed vulnerabilities warrant attention to Article 14 reporting readiness.
  • The article recommends checking reporting readiness and KEV-listed vulnerabilities now, assessing a high-risk product or supplier this quarter, and rescanning releases through 2027.

Article Details

Topic
Assessing EU Cyber Resilience Act compliance through analysis of shipped software binaries